📅 Original date posted:2017-01-06
📝 Original message:It's my opinion that the purpose of this list and bitcoin protocol
development in general is to build the base functionality that other
companies and individuals require to provide usability to the end-user. The
0-conf debate is a UX issue. If end users shouldn't rely on 0-conf, it is
up to wallet developers to hide 0-conf transactions or mark them
appropriately. Instead of using this list to debate what wallet designers
should or shouldn't do, we should just provide the tools and "let the
market sort it out". If wallet developers start getting inundated with
complaints that 0-conf transactions are causing confusion and loss, they
will find a solution. If the tools they require for the solution don't
exist, they will come to this list to request action.
Am I wrong?
On Fri, Jan 6, 2017 at 12:16 PM Chris Priest via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Its a method for determining the probability that a valid tx will be
> mined in a block before that tx actually gets mined, which is useful
> when accepting payments in situations when you can't wait for the full
> confirmation. No one is saying all tx validation should be performed
> by querying miners mempools, that's ridiculous. Obviously once the tx
> gets it's first confirmation, you go back to determining validity the
> way you always have. There is no "security catastrophe".
>
> Even if you're running a full node, you can't know for certain that
> any given tx will make it into a future block. You can't be certain
> the future miner who finally does mine that tx will mine your TXID or
> another TXID that spends the same inputs to another address (a double
> spend). The only way to actually know for certain is to query every
> single large hashpower mempool.
>
> On 1/4/17, Eric Voskuil <eric at voskuil.org> wrote:
> > On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:
> >> On 1/3/17, Jonas Schnelli via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> There are plenty, more sane options. If you can't run your own
> full-node
> >>> as a merchant (trivial), maybe co-use a wallet-service with centralized
> >>> verification (maybe use two of them), I guess Copay would be one of
> >>> those wallets (as an example). Use them in watch-only mode.
> >>
> >> The best way is to connect to the mempool of each miner and check to
> >> see if they have your txid in their mempool.
> >>
> >> https://www.antpool.com/api/is_in_mempool?txid=334847bb...
> >> https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
> >> https://bw.com/api/is_in_mempool?txid=334847bb...
> >> https://bitfury.com/api/is_in_mempool?txid=334847bb...
> >> https://btcc.com/api/is_in_mempool?txid=334847bb...
> >>
> >> If each of these services return "True", and you know those services
> >> so not engage in RBF, then you can assume with great confidence that
> >> your transaction will be in the next block, or in a block very soon.
> >> If any one of those services return "False", then you must assume that
> >> it is possible that there is a double spend floating around, and that
> >> you should wait to see if that tx gets confirmed. The problem is that
> >> not every pool runs such a service to check the contents of their
> >> mempool...
> >>
> >> This is an example of mining centralization increasing the security of
> >> zero confirm.
> >
> > A world connected up to a few web services to determine payment validity
> > is an example of a bitcoin security catastrophe.
> >
> > e
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170106/55cde129/attachment.html>;
James MacWhyte [ARCHIVE] /
npub12t…pye9h
2023-06-07 17:55:11
in reply to nevent1q…wu6p
Author Public Key
npub12tjaqer27049ejmvf0f3yd7kq6p93gg6ecavgrczge4rlzf59y5q2pye9hPublished at
2023-06-07 17:55:11Event JSON
{
"id": "f7d062266e3d2453b5e4abb7c1db142e627baffdf166c6317bc02d6d6adf11ad",
"pubkey": "52e5d0646af3ea5ccb6c4bd31237d6068258a11ace3ac40f02466a3f89342928",
"created_at": 1686160511,
"kind": 1,
"tags": [
[
"e",
"12de089a3e4ccbe31128a134586c26b5a984bf25231ca8b54e0116dac53ecb14",
"",
"root"
],
[
"e",
"3d638732e28ddb8dd22f2094e668774117e960a86475c27cd03dccc0d156b30a",
"",
"reply"
],
[
"p",
"3b5311200328974edeaa105b1a8f60d243e653cc63b6bb29f61dc696e04189ed"
]
],
"content": "📅 Original date posted:2017-01-06\n📝 Original message:It's my opinion that the purpose of this list and bitcoin protocol\ndevelopment in general is to build the base functionality that other\ncompanies and individuals require to provide usability to the end-user. The\n0-conf debate is a UX issue. If end users shouldn't rely on 0-conf, it is\nup to wallet developers to hide 0-conf transactions or mark them\nappropriately. Instead of using this list to debate what wallet designers\nshould or shouldn't do, we should just provide the tools and \"let the\nmarket sort it out\". If wallet developers start getting inundated with\ncomplaints that 0-conf transactions are causing confusion and loss, they\nwill find a solution. If the tools they require for the solution don't\nexist, they will come to this list to request action.\n\nAm I wrong?\n\nOn Fri, Jan 6, 2017 at 12:16 PM Chris Priest via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Its a method for determining the probability that a valid tx will be\n\u003e mined in a block before that tx actually gets mined, which is useful\n\u003e when accepting payments in situations when you can't wait for the full\n\u003e confirmation. No one is saying all tx validation should be performed\n\u003e by querying miners mempools, that's ridiculous. Obviously once the tx\n\u003e gets it's first confirmation, you go back to determining validity the\n\u003e way you always have. There is no \"security catastrophe\".\n\u003e\n\u003e Even if you're running a full node, you can't know for certain that\n\u003e any given tx will make it into a future block. You can't be certain\n\u003e the future miner who finally does mine that tx will mine your TXID or\n\u003e another TXID that spends the same inputs to another address (a double\n\u003e spend). The only way to actually know for certain is to query every\n\u003e single large hashpower mempool.\n\u003e\n\u003e On 1/4/17, Eric Voskuil \u003ceric at voskuil.org\u003e wrote:\n\u003e \u003e On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:\n\u003e \u003e\u003e On 1/3/17, Jonas Schnelli via bitcoin-dev\n\u003e \u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e There are plenty, more sane options. If you can't run your own\n\u003e full-node\n\u003e \u003e\u003e\u003e as a merchant (trivial), maybe co-use a wallet-service with centralized\n\u003e \u003e\u003e\u003e verification (maybe use two of them), I guess Copay would be one of\n\u003e \u003e\u003e\u003e those wallets (as an example). Use them in watch-only mode.\n\u003e \u003e\u003e\n\u003e \u003e\u003e The best way is to connect to the mempool of each miner and check to\n\u003e \u003e\u003e see if they have your txid in their mempool.\n\u003e \u003e\u003e\n\u003e \u003e\u003e https://www.antpool.com/api/is_in_mempool?txid=334847bb...\n\u003e \u003e\u003e https://www.f2pool.com/api/is_in_mempool?txid=334847bb...\n\u003e \u003e\u003e https://bw.com/api/is_in_mempool?txid=334847bb...\n\u003e \u003e\u003e https://bitfury.com/api/is_in_mempool?txid=334847bb...\n\u003e \u003e\u003e https://btcc.com/api/is_in_mempool?txid=334847bb...\n\u003e \u003e\u003e\n\u003e \u003e\u003e If each of these services return \"True\", and you know those services\n\u003e \u003e\u003e so not engage in RBF, then you can assume with great confidence that\n\u003e \u003e\u003e your transaction will be in the next block, or in a block very soon.\n\u003e \u003e\u003e If any one of those services return \"False\", then you must assume that\n\u003e \u003e\u003e it is possible that there is a double spend floating around, and that\n\u003e \u003e\u003e you should wait to see if that tx gets confirmed. The problem is that\n\u003e \u003e\u003e not every pool runs such a service to check the contents of their\n\u003e \u003e\u003e mempool...\n\u003e \u003e\u003e\n\u003e \u003e\u003e This is an example of mining centralization increasing the security of\n\u003e \u003e\u003e zero confirm.\n\u003e \u003e\n\u003e \u003e A world connected up to a few web services to determine payment validity\n\u003e \u003e is an example of a bitcoin security catastrophe.\n\u003e \u003e\n\u003e \u003e e\n\u003e \u003e\n\u003e \u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170106/55cde129/attachment.html\u003e",
"sig": "0077dc9b1c61b83f60d9c501000cf7e991c9257d355194617656e7c4c77238059984cf5f61698f4177aa898286dc5d825f42f25bbe407045914912aa7bf1ec1a"
}