Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-18 📝 Original message:First of all, that's an ...
📅 Original date posted:2015-12-18
📝 Original message:First of all, that's an expensive beer!
Second of all, any consensus rule change risks non-full-validating or
non-upgraded nodes seeing invalid confirmations...but assuming a large
supermajority (i.e. > 95%) of hashing power is behind the new rule, it
is extremely unlikely that very many invalid confirmations will ever be
seen by anyone. The number of confirmations you require depends on your
use case security requirements...and especially during a new rule
activation, it is probably not a good idea for non-validating nodes or
non-upgraded nodes to accept coins with low confirmation counts unless
the risk is accounted for in the use case (i.e. a web hosting provider
that can shut the user out if fraud is later detected).
Third of all, as long as the rule change activation is signaled in
blocks, even old nodes will be able to detect that something is fishy
and warn users to be more cautious (i.e. wait more confirmations or
immediately upgrade or connect to a different node that has upgraded,
etc...)
I honestly don't see an issue here - unless you're already violating
fundamental security assumptions that would make you vulnerable to
exploitation even without rule changes.
- Eric
------ Original Message ------
From: "Jonathan Toomim via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org>
To: "Pieter Wuille" <pieter.wuille at gmail.com>
Cc: "Bitcoin Dev" <bitcoin-dev at lists.linuxfoundation.org>
Sent: 12/17/2015 6:47:14 PM
Subject: Re: [bitcoin-dev] On the security of softforks
>
>On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev
><bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>1) The risk of an old full node wallet accepting a transaction that is
>>invalid to the new rules.
>>
>>The receiver wallet chooses what address/script to accept coins on.
>>They'll upgrade to the new softfork rules before creating an address
>>that depends on the softfork's features.
>>
>>So, not a problem.
>
>Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
>runs the old rules. Bob creates a p2pkh address for Mallory to use.
>Mallory takes 1 BTC, and creates an invalid SegWit transaction that Bob
>cannot properly validate and that pays into one of Mallory's wallets.
>Mallory then immediately spends the unconfirmed transaction into Bob's
>address. Bob sees what appears to be a valid transaction chain which is
>not actually valid.
>
>Clueless Carol is one of the 4.9% of miners who forgot to upgrade her
>mining node. Carol sees that Mallory included an enormous fee in his
>transactions, so Carol makes sure to include both transactions in her
>block.
>
>Mallory gets free beer.
>
>Anything I'm missing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/a519b123/attachment.html>;
📝 Original message:First of all, that's an expensive beer!
Second of all, any consensus rule change risks non-full-validating or
non-upgraded nodes seeing invalid confirmations...but assuming a large
supermajority (i.e. > 95%) of hashing power is behind the new rule, it
is extremely unlikely that very many invalid confirmations will ever be
seen by anyone. The number of confirmations you require depends on your
use case security requirements...and especially during a new rule
activation, it is probably not a good idea for non-validating nodes or
non-upgraded nodes to accept coins with low confirmation counts unless
the risk is accounted for in the use case (i.e. a web hosting provider
that can shut the user out if fraud is later detected).
Third of all, as long as the rule change activation is signaled in
blocks, even old nodes will be able to detect that something is fishy
and warn users to be more cautious (i.e. wait more confirmations or
immediately upgrade or connect to a different node that has upgraded,
etc...)
I honestly don't see an issue here - unless you're already violating
fundamental security assumptions that would make you vulnerable to
exploitation even without rule changes.
- Eric
------ Original Message ------
From: "Jonathan Toomim via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org>
To: "Pieter Wuille" <pieter.wuille at gmail.com>
Cc: "Bitcoin Dev" <bitcoin-dev at lists.linuxfoundation.org>
Sent: 12/17/2015 6:47:14 PM
Subject: Re: [bitcoin-dev] On the security of softforks
>
>On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev
><bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>1) The risk of an old full node wallet accepting a transaction that is
>>invalid to the new rules.
>>
>>The receiver wallet chooses what address/script to accept coins on.
>>They'll upgrade to the new softfork rules before creating an address
>>that depends on the softfork's features.
>>
>>So, not a problem.
>
>Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
>runs the old rules. Bob creates a p2pkh address for Mallory to use.
>Mallory takes 1 BTC, and creates an invalid SegWit transaction that Bob
>cannot properly validate and that pays into one of Mallory's wallets.
>Mallory then immediately spends the unconfirmed transaction into Bob's
>address. Bob sees what appears to be a valid transaction chain which is
>not actually valid.
>
>Clueless Carol is one of the 4.9% of miners who forgot to upgrade her
>mining node. Carol sees that Mallory included an enormous fee in his
>transactions, so Carol makes sure to include both transactions in her
>block.
>
>Mallory gets free beer.
>
>Anything I'm missing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/a519b123/attachment.html>;