ð
Original date posted:2018-06-09
ð Original message:Here is our internal report, if you want more details on the problem.
(our reported attack complexity may slightly differ from what Peter has
provided, but the attack complexity depends on the funds the attacker is
willing to lock).
regards,
Sergio.
On Sat, Jun 9, 2018 at 2:21 PM Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
> Also it must be noted that an attacker having only 1.3M USD that can
> brute-force 72 bits (4 days of hashing on capable ASICs) can perform the
> same attack, so the attack is entirely feasible and no person should accept
> more than 1M USD using a SPV wallet.
>
> Also the attack can be repeated: once you create the "extension point"
> block, you can attack more and more parties without any additional
> computation.
>
>
> On Sat, Jun 9, 2018 at 1:03 PM Sergio Demian Lerner <
> sergio.d.lerner at gmail.com> wrote:
>
>> Hi Peter,
>> We reported this as CVE-2017-12842, although it may have been known by
>> developers before us.
>> There are hundreds of SPV wallets out there, without even considering
>> other more sensitive systems relying on SPV proofs.
>> As I said we, at RSK, discovered this problem in 2017. For RSK it's very
>> important this is fixed because our SPV bridge uses SPV proofs.
>> I urge all people participating in this mailing list and the rest of the
>> Bitcoin community to work on this issue for the security and clean-design
>> of Bitcoin.
>>
>> My suggestion is to use in the version bits 4 bits indicating the tree
>> depth (-1), as a soft-fork, so
>> 00=1 depth,
>> 0F = 16 depth (maximum 64K transactions). Very clean.
>>
>> The other option is to ban transaction with size lower or equal to 64.
>>
>> Best regards,
>> Sergio.
>>
>> On Sat, Jun 9, 2018 at 5:31 AM Bram Cohen via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> So are you saying that if fully validating nodes wish to prune they can
>>> maintain the ability to validate old transactions by cacheing the number of
>>> transactions in each previous block?
>>>
>>> On Thu, Jun 7, 2018 at 3:20 PM, Peter Todd <pete at petertodd.org> wrote:
>>>
>>>> On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote:
>>>> > Are you proposing a soft fork to include the number of transactions
>>>> in a
>>>> > block in the block headers to compensate for the broken Merkle
>>>> format? That
>>>> > sounds like a good idea.
>>>> >
>>>> > On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev <
>>>> > bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> >
>>>> > > It's well known that the Bitcoin merkle tree algorithm fails to
>>>> distinguish
>>>> > > between inner nodes and 64 byte transactions, as both txs and inner
>>>> nodes
>>>> > > are
>>>> > > hashed the same way. This potentially poses a problem for tx
>>>> inclusion
>>>> > > proofs,
>>>> > > as a miner could (with ~60 bits of brute forcing) create a
>>>> transaction that
>>>> > > committed to a transaction that was not in fact in the blockchain.
>>>> > >
>>>> > > Since odd-numbered inner/leaf nodes are concatenated with
>>>> themselves and
>>>> > > hashed
>>>> > > twice, the depth of all leaves (txs) in the tree is fixed.
>>>> > >
>>>> > > It occured to me that if the depth of the merkle tree is known, this
>>>> > > vulnerability can be trivially avoided by simply comparing the
>>>> length of
>>>> > > the
>>>> > > merkle path to that known depth. For pruned nodes, if the depth is
>>>> saved
>>>> > > prior
>>>> > > to pruning the block contents itself, this would allow for
>>>> completely safe
>>>> > > verification of tx inclusion proofs, without a soft-fork; storing
>>>> this
>>>> ^^^^^^^^^^^^^^^^^^^
>>>>
>>>> Re-read my post: I specifically said you do not need a soft-fork to
>>>> implement
>>>> this. In fact, I think you can argue that this is an accidental
>>>> feature, not a
>>>> bug, as it further encourages the use of safe full verifiaction rather
>>>> than
>>>> unsafe lite clients.
>>>>
>>>> --
>>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>>
>>>
>>> _______________________________________________
>>> 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/20180609/9f4f5b1f/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Vulnerability in Bitcoin Merkle Tree Design.pdf
Type: application/pdf
Size: 402454 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/9f4f5b1f/attachment-0001.pdf>;
Sergio Demian Lerner [ARCHIVE] /
npub1fvâŠ3vq7f
2023-06-07 18:12:58
in reply to nevent1qâŠ2wa9
Author Public Key
npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fPublished at
2023-06-07 18:12:58Event JSON
{
"id": "d502d50d3d9952f81884a01a1259c6c4bea7cc7561cc6cb2b7b6436c47830014",
"pubkey": "4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee",
"created_at": 1686161578,
"kind": 1,
"tags": [
[
"e",
"7a6928115f0482ae6ba69f7494f1e58497a12608fbde58f7bb3fa58e19c8ae03",
"",
"root"
],
[
"e",
"1a3db667ac79300c6d93881c44837a05830aeeeacf8b9bb4c5c5fa41e3113a54",
"",
"reply"
],
[
"p",
"4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee"
]
],
"content": "ð
Original date posted:2018-06-09\nð Original message:Here is our internal report, if you want more details on the problem.\n (our reported attack complexity may slightly differ from what Peter has\nprovided, but the attack complexity depends on the funds the attacker is\nwilling to lock).\n\nregards,\n Sergio.\n\nOn Sat, Jun 9, 2018 at 2:21 PM Sergio Demian Lerner \u003c\nsergio.d.lerner at gmail.com\u003e wrote:\n\n\u003e Also it must be noted that an attacker having only 1.3M USD that can\n\u003e brute-force 72 bits (4 days of hashing on capable ASICs) can perform the\n\u003e same attack, so the attack is entirely feasible and no person should accept\n\u003e more than 1M USD using a SPV wallet.\n\u003e\n\u003e Also the attack can be repeated: once you create the \"extension point\"\n\u003e block, you can attack more and more parties without any additional\n\u003e computation.\n\u003e\n\u003e\n\u003e On Sat, Jun 9, 2018 at 1:03 PM Sergio Demian Lerner \u003c\n\u003e sergio.d.lerner at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e Hi Peter,\n\u003e\u003e We reported this as CVE-2017-12842, although it may have been known by\n\u003e\u003e developers before us.\n\u003e\u003e There are hundreds of SPV wallets out there, without even considering\n\u003e\u003e other more sensitive systems relying on SPV proofs.\n\u003e\u003e As I said we, at RSK, discovered this problem in 2017. For RSK it's very\n\u003e\u003e important this is fixed because our SPV bridge uses SPV proofs.\n\u003e\u003e I urge all people participating in this mailing list and the rest of the\n\u003e\u003e Bitcoin community to work on this issue for the security and clean-design\n\u003e\u003e of Bitcoin.\n\u003e\u003e\n\u003e\u003e My suggestion is to use in the version bits 4 bits indicating the tree\n\u003e\u003e depth (-1), as a soft-fork, so\n\u003e\u003e 00=1 depth,\n\u003e\u003e 0F = 16 depth (maximum 64K transactions). Very clean.\n\u003e\u003e\n\u003e\u003e The other option is to ban transaction with size lower or equal to 64.\n\u003e\u003e\n\u003e\u003e Best regards,\n\u003e\u003e Sergio.\n\u003e\u003e\n\u003e\u003e On Sat, Jun 9, 2018 at 5:31 AM Bram Cohen via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e So are you saying that if fully validating nodes wish to prune they can\n\u003e\u003e\u003e maintain the ability to validate old transactions by cacheing the number of\n\u003e\u003e\u003e transactions in each previous block?\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Thu, Jun 7, 2018 at 3:20 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote:\n\u003e\u003e\u003e\u003e \u003e Are you proposing a soft fork to include the number of transactions\n\u003e\u003e\u003e\u003e in a\n\u003e\u003e\u003e\u003e \u003e block in the block headers to compensate for the broken Merkle\n\u003e\u003e\u003e\u003e format? That\n\u003e\u003e\u003e\u003e \u003e sounds like a good idea.\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev \u003c\n\u003e\u003e\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e \u003e It's well known that the Bitcoin merkle tree algorithm fails to\n\u003e\u003e\u003e\u003e distinguish\n\u003e\u003e\u003e\u003e \u003e \u003e between inner nodes and 64 byte transactions, as both txs and inner\n\u003e\u003e\u003e\u003e nodes\n\u003e\u003e\u003e\u003e \u003e \u003e are\n\u003e\u003e\u003e\u003e \u003e \u003e hashed the same way. This potentially poses a problem for tx\n\u003e\u003e\u003e\u003e inclusion\n\u003e\u003e\u003e\u003e \u003e \u003e proofs,\n\u003e\u003e\u003e\u003e \u003e \u003e as a miner could (with ~60 bits of brute forcing) create a\n\u003e\u003e\u003e\u003e transaction that\n\u003e\u003e\u003e\u003e \u003e \u003e committed to a transaction that was not in fact in the blockchain.\n\u003e\u003e\u003e\u003e \u003e \u003e\n\u003e\u003e\u003e\u003e \u003e \u003e Since odd-numbered inner/leaf nodes are concatenated with\n\u003e\u003e\u003e\u003e themselves and\n\u003e\u003e\u003e\u003e \u003e \u003e hashed\n\u003e\u003e\u003e\u003e \u003e \u003e twice, the depth of all leaves (txs) in the tree is fixed.\n\u003e\u003e\u003e\u003e \u003e \u003e\n\u003e\u003e\u003e\u003e \u003e \u003e It occured to me that if the depth of the merkle tree is known, this\n\u003e\u003e\u003e\u003e \u003e \u003e vulnerability can be trivially avoided by simply comparing the\n\u003e\u003e\u003e\u003e length of\n\u003e\u003e\u003e\u003e \u003e \u003e the\n\u003e\u003e\u003e\u003e \u003e \u003e merkle path to that known depth. For pruned nodes, if the depth is\n\u003e\u003e\u003e\u003e saved\n\u003e\u003e\u003e\u003e \u003e \u003e prior\n\u003e\u003e\u003e\u003e \u003e \u003e to pruning the block contents itself, this would allow for\n\u003e\u003e\u003e\u003e completely safe\n\u003e\u003e\u003e\u003e \u003e \u003e verification of tx inclusion proofs, without a soft-fork; storing\n\u003e\u003e\u003e\u003e this\n\u003e\u003e\u003e\u003e ^^^^^^^^^^^^^^^^^^^\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Re-read my post: I specifically said you do not need a soft-fork to\n\u003e\u003e\u003e\u003e implement\n\u003e\u003e\u003e\u003e this. In fact, I think you can argue that this is an accidental\n\u003e\u003e\u003e\u003e feature, not a\n\u003e\u003e\u003e\u003e bug, as it further encourages the use of safe full verifiaction rather\n\u003e\u003e\u003e\u003e than\n\u003e\u003e\u003e\u003e unsafe lite clients.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e --\n\u003e\u003e\u003e\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/9f4f5b1f/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Vulnerability in Bitcoin Merkle Tree Design.pdf\nType: application/pdf\nSize: 402454 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/9f4f5b1f/attachment-0001.pdf\u003e",
"sig": "819490d66bbd800754bd784c0f062dd1eacb858037028aeb8bcf1e8de46d7b7714a2aaf00b1a72b69413cca1547cac6b1dd4572e12802c97888be56f607d9d83"
}