📅 Original date posted:2017-03-15
📝 Original message:Sorry, this is not the case.
Your slides gloss over the simple fact that compact fraud proofs in
Bitcoin aren't possible, and that the "SPV" implemented today bears
absolutely no resemblance in security properties to the version
described in the Bitcoin white paper. In the white paper SPV clients
have the same security as fully validating nodes, in the implementation
of BIP37 they have absolutely no security except the vague hope that
they are not being lied to, and that the chain with the most work they
are seeing is actually valid, both are very weak assumptions.
The suggested solution in no way precludes unconfirmed transactions from
being used with a commitment scheme, my comments and others are just
recognising that they are an almost useless indicator for people who
aren't validating.
During the validationless mining failure around the BIP66 activation
miners produced 6 invalid blocks in a chain, and many more invalid
blocks in isolated bursts for a period lasting several months. Due to
the instability of the network you are completely unreasonable to accept
anything except multiple confirmations, the true number for safety is
probably more like 60 or 120, not 6, or 3, or 1 as some Bitcoin
exchanges use today.
0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99.bin
bad-version(0x00000002)
0000000000000000032527aa796d3672e32e5f85a452d3a584a28fc7efbcd5d0.bin
bad-version(0x00000002)
000000000000000003ae1223f4926ec86100885cfe1484dc52fd67e042a19b12.bin
bad-version(0x00000002)
0000000000000000083cbdbb25c1607527c8f3fdb16f0d048c4439a73b501cb6.bin
bad-version(0x00000002)
00000000000000000954ed93eda1e79e8261137548fa9ccf4d516bb384a3660b.bin
bad-version(0x00000002)
00000000000000000afc9fbe7cfe8a6b50502d509ba626beb2e2d6c15d1d3ee3.bin
bad-version(0x00000002)
00000000000000000b6adf92bc192b3c21210f456ab21b5e46951665c74cfab2.bin
bad-version(0x00000002)
00000000000000000c9bb4a508fff34f5450d9c62ef2cb833e53909a4c549de5.bin
bad-version(0x00000002)
0000000000000000116322b5f25826787b01f7a70fb322837b68dff8216cefc4.bin
bad-version(0x00000002)
000000000000000012aac0664cd8b6cbc3ea485921a05f2c4340f928b0226d3c.bin
bad-version(0x00000002)
"SPV" like you're describing can exist, or validationless mining can
exist, both can not simultaneously.
On 2017-03-16 09:36, Tom Harding via bitcoin-dev wrote:
> Agreed.
>
> In contrast, BIP37 as used today is totally decentralized, and can me
> made much more secure, private, and scalable -- without giving up the
> utility of unconfirmed transactions.
>
> Please don't read into this statement a belief that all the coffees
> should go on the chain, or that the security or privacy of BIP37
> compare favorably to any other particular thing.
>
> https://docs.google.com/presentation/d/13MzUo2iIH9JBW29TgtPMoaMXxeEdanWDfi6SlfO-LlA
>
>
>
> On 1/5/2017 6:04 PM, bfd--- via bitcoin-dev wrote:
>> You might as well replace Bitcoin with a system where these parties
>> sign transactions and skip mining altogether, it would have the same
>> properties and be significantly more effient.
>>
>>
>> On 2017-01-04 23:06, Chris Priest 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. If more people mined, this method will not work as well
>>> because it would require you to call the API of hundreds of different
>>> potential block creators.
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
bfd at cock.lu [ARCHIVE] /
npub1md…gy6y7
2023-06-07 17:57:18
in reply to nevent1q…0jaz
Author Public Key
npub1mdmqmt0prpddcexkljfzd40uf7nvrc56c7gsg2spn3lgcjghguxqwgy6y7Published at
2023-06-07 17:57:18Event JSON
{
"id": "fb350ba1c8707012f7dc0113002f599ebe81f82b0b75abd92f5e770b3e8be257",
"pubkey": "db760dade1185adc64d6fc9226d5fc4fa6c1e29ac791042a019c7e8c4917470c",
"created_at": 1686160638,
"kind": 1,
"tags": [
[
"e",
"4b1752cfa8e322a52901f8a73403b24006853bdfbdcea90aaa66fa8a2818d2e6",
"",
"root"
],
[
"e",
"05427ec29ea913df496c18b2d529592ade51d498184df435c9126e3f70641d0e",
"",
"reply"
],
[
"p",
"dc329a02c970aabf03b87185ef51c86afe4586fe3a148508af898af3fabc56a3"
]
],
"content": "📅 Original date posted:2017-03-15\n📝 Original message:Sorry, this is not the case.\n\nYour slides gloss over the simple fact that compact fraud proofs in \nBitcoin aren't possible, and that the \"SPV\" implemented today bears \nabsolutely no resemblance in security properties to the version \ndescribed in the Bitcoin white paper. In the white paper SPV clients \nhave the same security as fully validating nodes, in the implementation \nof BIP37 they have absolutely no security except the vague hope that \nthey are not being lied to, and that the chain with the most work they \nare seeing is actually valid, both are very weak assumptions.\n\nThe suggested solution in no way precludes unconfirmed transactions from \nbeing used with a commitment scheme, my comments and others are just \nrecognising that they are an almost useless indicator for people who \naren't validating.\n\nDuring the validationless mining failure around the BIP66 activation \nminers produced 6 invalid blocks in a chain, and many more invalid \nblocks in isolated bursts for a period lasting several months. Due to \nthe instability of the network you are completely unreasonable to accept \nanything except multiple confirmations, the true number for safety is \nprobably more like 60 or 120, not 6, or 3, or 1 as some Bitcoin \nexchanges use today.\n\n\n0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99.bin \nbad-version(0x00000002)\n0000000000000000032527aa796d3672e32e5f85a452d3a584a28fc7efbcd5d0.bin \nbad-version(0x00000002)\n000000000000000003ae1223f4926ec86100885cfe1484dc52fd67e042a19b12.bin \nbad-version(0x00000002)\n0000000000000000083cbdbb25c1607527c8f3fdb16f0d048c4439a73b501cb6.bin \nbad-version(0x00000002)\n00000000000000000954ed93eda1e79e8261137548fa9ccf4d516bb384a3660b.bin \nbad-version(0x00000002)\n00000000000000000afc9fbe7cfe8a6b50502d509ba626beb2e2d6c15d1d3ee3.bin \nbad-version(0x00000002)\n00000000000000000b6adf92bc192b3c21210f456ab21b5e46951665c74cfab2.bin \nbad-version(0x00000002)\n00000000000000000c9bb4a508fff34f5450d9c62ef2cb833e53909a4c549de5.bin \nbad-version(0x00000002)\n0000000000000000116322b5f25826787b01f7a70fb322837b68dff8216cefc4.bin \nbad-version(0x00000002)\n000000000000000012aac0664cd8b6cbc3ea485921a05f2c4340f928b0226d3c.bin \nbad-version(0x00000002)\n\n\"SPV\" like you're describing can exist, or validationless mining can \nexist, both can not simultaneously.\n\n\n\nOn 2017-03-16 09:36, Tom Harding via bitcoin-dev wrote:\n\u003e Agreed.\n\u003e \n\u003e In contrast, BIP37 as used today is totally decentralized, and can me\n\u003e made much more secure, private, and scalable -- without giving up the\n\u003e utility of unconfirmed transactions.\n\u003e \n\u003e Please don't read into this statement a belief that all the coffees\n\u003e should go on the chain, or that the security or privacy of BIP37\n\u003e compare favorably to any other particular thing.\n\u003e \n\u003e https://docs.google.com/presentation/d/13MzUo2iIH9JBW29TgtPMoaMXxeEdanWDfi6SlfO-LlA\n\u003e \n\u003e \n\u003e \n\u003e On 1/5/2017 6:04 PM, bfd--- via bitcoin-dev wrote:\n\u003e\u003e You might as well replace Bitcoin with a system where these parties\n\u003e\u003e sign transactions and skip mining altogether, it would have the same\n\u003e\u003e properties and be significantly more effient.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e On 2017-01-04 23:06, Chris Priest 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\u003e\u003e\u003e full-node\n\u003e\u003e\u003e\u003e as a merchant (trivial), maybe co-use a wallet-service with \n\u003e\u003e\u003e\u003e 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 \n\u003e\u003e\u003e 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 \n\u003e\u003e\u003e of\n\u003e\u003e\u003e zero confirm. If more people mined, this method will not work as well\n\u003e\u003e\u003e because it would require you to call the API of hundreds of different\n\u003e\u003e\u003e potential block creators.\n\u003e\u003e \n\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",
"sig": "9b586626d96413428d44e111398f15952d288043e7a2e4d83a47864aa6a2a0e09357d689fc04152e0dc518be8ecfc0f636e435b246073d3c912cc506edebdbc7"
}