Re: [bitcoin-dev] On the security of softforks

[Rusty Russell via bitcoin-dev]

Jonathan Toomim via bitcoin-dev 
writes:
> On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev 
>  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.

Pretty sure Bob's wallet will be looking for "OP_DUP OP_HASH160
 OP_EQUALVERIFY OP_CHECKSIG" scriptSig.  The SegWit-usable
outputs will (have to) look different, won't they?

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the security of softforks

[jl2012 via bitcoin-dev]

Rusty Russell via bitcoin-dev 於 2015-12-19 23:14 寫到:

Jonathan Toomim via bitcoin-dev 
writes:
On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev 
 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.


Pretty sure Bob's wallet will be looking for "OP_DUP OP_HASH160
 OP_EQUALVERIFY OP_CHECKSIG" scriptSig.  The SegWit-usable
outputs will (have to) look different, won't they?

Cheers,
Rusty.


I think he means Mallory is paying with an invalid Segwit input, not 
output (there is no "invalid output" anyway). However, this is not a 
issue if Bob waits for a few confirmations.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the security of softforks

[Bryan Bishop via bitcoin-dev]

On Fri, Dec 18, 2015 at 6:18 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Anyway, we should write this up as a BIP - there's been a tremendous
> amount of misinformation, even flat out lies, floating around on this
> subject.
>

Er, this sounds like something that should go into bip99. Right?

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the security of softforks

[Jorge Timón via bitcoin-dev]

To me it's getting clearer and clearer that th frintier between
softforks and hardforks it's softer than we thought.
Aoftforks should start having a minimum median time deplayment day (be
it height or median time, I don't care, just not header.nTime).
TYDGFHdfthfg64565$%^$

On Fri, Dec 18, 2015 at 4:10 AM, jl2012 via bitcoin-dev
 wrote:
> Jonathan Toomim via bitcoin-dev 於 2015-12-17 21:47 寫到:
>>
>> 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?
>
>
> You miss the fact that 0-conf is not safe, neither 1-conf. What you are
> suggesting is just a variation of Finney attack.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the security of softforks

[Eric Lombrozo via bitcoin-dev]

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@lists.linuxfoundation.org>

To: "Pieter Wuille" <pieter.wui...@gmail.com>
Cc: "Bitcoin Dev" <bitcoin-dev@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@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?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the security of softforks

[Jonathan Toomim via bitcoin-dev]

On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev 
 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?


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev