On the security of softforks

On the security of softforks
2015-12-18  2:47 ` Jonathan Toomim
  
From: Pieter Wuille @ 2015-12-18  2:30 UTC (permalink / raw)
  To: Bitcoin Dev

Hello all,

For a long time, I was personally of the opinion that soft forks
constituted a mild security reduction for old full nodes, albeit one
that was preferable to hard forks due to being far less risky, easier,
and less forceful to deploy.

After thinking more about this, I'm not convinced that it is even that anymore.

Let's analyze all failure modes (and feel free to let me know whether
I've missed any specific ones):

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.

2) The risk of an old full node wallet accepting a transaction whose
coins passed through a script that depends on the softforked rules.

It is reasonable that the receiver of a transaction places some trust
in the sender, and on the basis of that, decides to reduce the number
of confirmations before acceptance. In case the transaction indirectly
depends on a low-confirmation transaction using softforked rules, it
may be treated as an anyone-can-spend transaction. Obviously, no trust
can be placed in such a transactions not being reorged out and
replaced with an incompatible one.

However, this problem is common for all anyonecanspend transactions,
which are perfectly legal today in the blockchain. So, if this is a
worry, we can solve it by marking incoming transactions as "uncertain
history" in the wallet if they have an anyonecanspend transaction with
less than 6 confirmations in its history. In fact, the same problem to
a lesser extent exists if coins pass through a 1-of-N multisig or so,
because you're not only trusting the (indirect) senders, but also
their potential cosigners.

3) The risk of an SPV node wallet accepting an unconfirmed transaction
which is invalid to new nodes.

Defrauding an SPV wallet with an invalid unconfirmed transaction
doesn't change with the introduction of new consensus rules, as they
don't validate them anyway.

In the case the client trusts the full node peer(s) it is connected to
to do validation before relay, nodes can either indicate (service bit
or new p2p message) which softforks are accepted (as it only matters
to SPV wallets that wish to accept transactions using new style script
anyway), or wallets can rely on the new rules being non-standard even
to old full nodes (which is typically aimed for in softforks).

4) The risk of an SPV node wallet accepting a confirmed transaction
which is invalid to new nodes

Miners can of course construct an invalid block purely for defrauding
SPV nodes, without intending to get that block accepted by full nodes.
That is expensive (no subsidy/fee income for those blocks) and more
importantly it isn't in any way affected by softforks.

So the only place where this matters is where miners create a block
chain that violates the new rules, and still get it accepted. This
requires a hash rate majority, and sufficiently few economically
important full nodes that forking them off is a viable approach.

It's interesting that even though it requires forking off full nodes
(who will notice, there will be an invalid majority hash rate chain to
them), the attack only allows defrauding SPV nodes. It can't be used
to bypass any of the economic properties of the system (as subsidy and
other resource limits are still enforced by old nodes, and invalid
scripts will either not be accepted by old full nodes wallets, or are
as vulnerable as unrelated anyonecanspends).

Furthermore, it's easily preventable by not using the feature in SPV
wallets until a sufficient amount of economically relevant full nodes
are known to have upgraded, or by just waiting for enough
confirmations.



So, we'd of course prefer to have all full nodes enforce all rules,
but the security reduction is not large. On the other hand, there are
also security advantages that softforks offer:

A) Softforks do not require the pervasive consensus that hardforks
need. Soft forks can be deployed without knowing when all full nodes
will adopt the rule, or even whether they will ever adopt it at all.

B) Keeping up with hard forking changes puts load on full node
operators, who may choose to instead switch to delegating full
validation to third parties, which is worse than just validating the
old rules.

C) Hardfork coordination has a centralizing effect on development. As
hardforks can only be deployed with sufficient node deployment, they
can't just be triggered by miner votes. This requires central
coordination to determine flag times, which is incompatible with
having multiple independent consensus changes being proposed. For
softforks, something like BIP9 supports having multiple independent
softforks in flight, that nodes can individually chose to accept or
not, only requiring coordination to not choose clashing bit numbers.
For hardforks, there is effectively no choice but having every
codebase deployed at a particular point in time to support every
possible hard forks (there can still be an additional hashpower based
trigger conditions for hardforks, but all nodes need to support the
fork at the earliest time it can happen, or risk being forked off).

D) If you are concerned about the security degradation a soft fork
might bring, you can always configure your node to treat a (signalled)
softfork as a hardfork, and stop processing blocks if a sortfork
condition is detected. The other direction is not possible.

-- 
Pieter


 permalink raw reply	[|nested]
2015-12-18  2:30 [bitcoin-dev] On the security of softforks Pieter Wuille

  2015-12-18  3:02   ` Eric Lombrozo
                     ` (5 more replies)
  
From: Jonathan Toomim @ 2015-12-18  2:47 UTC (permalink / raw)
  To: Pieter Wuille;  Bitcoin Dev


[-- Attachment #1.1: Type: text/plain, Size: 1150 bytes --]


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?

[-- Attachment #1.2: Type: text/html, Size: 6047 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

 permalink raw reply	[|nested]
2015-12-18  2:30 [bitcoin-dev] On the security of softforks Pieter Wuille

  2015-12-18  3:02   ` 
                     ` 
  
From: Jonathan Toomim @ 2015-12-18  2:47 UTC (permalink / raw)
  To: Pieter Wuille;  Bitcoin Dev


[-- Attachment #1.1: Type: text/plain, Size: 1150 bytes --]


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?

[-- Attachment #1.2: Type: text/html, Size: 6047 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

 permalink raw reply	[|nested]
* 
  2015-12-18  2:47 ` Jonathan Toomim

  2015-12-18 12:18     ` Peter Todd
  2015-12-18  3:10   ` 
                     ` 
  5 siblings, 1 reply; 12+ messages in thread
From: Eric Lombrozo @ 2015-12-18  3:02 UTC (permalink / raw)
  To: Jonathan Toomim, Pieter Wuille;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2738 bytes --]

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.wuille@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?

[-- Attachment #2: Type: text/html, Size: 6750 bytes --]

^ permalink raw reply	[|nested] 12+ messages in thread
2015-12-18  3:10   ` jl2012

  
From: Jorge Timón @ 2015-12-18  5:32 UTC (permalink / raw)
  To: jl2012;  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
<bitcoin-dev@lists•linuxfoundation.org> 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


 permalink raw reply	[|nested]
* 
  2015-12-18  2:47 ` Jonathan Toomim
  2015-12-18  3:02   ` Eric Lombrozo

  2015-12-18  5:32     ` Jorge Timón
  2015-12-18  6:12   ` 
                     ` 
  5 siblings, 1 reply; 12+ messages in thread
From: jl2012 @ 2015-12-18  3:10 UTC (permalink / raw)
  To: Jonathan Toomim;  Bitcoin Dev

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.


^ permalink raw reply	[|nested] 12+ messages in thread
2015-12-18  3:02   ` Eric Lombrozo

  2015-12-19 15:48       ` Bryan Bishop
  
From: Peter Todd @ 2015-12-18 12:18 UTC (permalink / raw)
  To: Eric Lombrozo;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

On Fri, Dec 18, 2015 at 03:02:36AM +0000, Eric Lombrozo via bitcoin-dev wrote:
> 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

To clarify, because the 95% of upgraded hashing power is creating valid
blocks from the point of view of the remaining 5%, that 95% majority
will continually reorg the 5% non-upgrading chain. This ensures that the
invalid chain remains short, and thus the # of invalid confirmations
possible remains small. For instance, the chance of getting one invalid
confirmation is 0.05^1 = 5%, two invalid confirmations 0.05^2 = 0.25%, three
0.05^3 = 0.01% etc.

Whereas with a hard fork, the 5% of miners will continue mining on their
own chain. While that chain's length will increase more slowly than
normal, the # of confirmations that non-upgraded clients will see on it
are unbounded.


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.

-- 
'peter'[:-1]@petertodd.org
000000000000000001bd68962863e6fa34e9776df361d4926912f52fc5f4b618

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

 permalink raw reply	[|nested]
* 
  2015-12-18  2:47 ` Jonathan Toomim
  2015-12-18  3:02   ` Eric Lombrozo
  2015-12-18  3:10   ` jl2012

  2015-12-19  1:36   ` 
                     ` 
  5 siblings, 0 replies; 12+ messages in thread
From: Anthony Towns @ 2015-12-18  6:12 UTC (permalink / raw)
  To: bitcoin-dev

On Fri, Dec 18, 2015 at 10:47:14AM +0800, Jonathan Toomim via bitcoin-dev wrote:
> 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. [...]
> 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.

For it to be a "safe" soft fork, the "invalid segwit transaction" should
look non-standard to Carol, and as such she should refuse to mine it.

I think the attack has to go like this:

 * segwit activates; 5% of miners fail to upgrade however

 * Mallory creates a transaction paying to a segwit script
   (ie scriptPubKey is just a 33 byte push) [0]

 * non-upgraded nodes and miners will refuse to forward or mine
   this transaction (a non-p2sh scriptPubKey that just pushes data is
   non-standard) but the upgraded nodes and miners will forward and mine
   it. it will be included in the blockchain by upgraded miners fairly
   soon, and will then be in the UTXO set of non-upgraded miners and
   nodes too.

 * Mallory creates a segwit-invalid spend back to himself (or directly
   to Bob for the 1BTC), ie provides empty scriptSig, but no
   witness data. Upgraded miners and nodes reject the transaction,
   but non-upgraded nodes will relay and mine it afaics.

I *think* that transaction will fail the AreInputsStandard() test on
non-upgraded nodes, and thus still won't be accepted to the mempool
or mined by non-upgraded nodes, and thus no one will see it, or any
descendent transactions. (Upgraded nodes will reject it because it's
segwit invalid, of course)

If it is accepted by some old nodes, that transaction won't ever get many
confirmations -- if Carol mines it, her block will be orphaned by the
upgraded mining majority after the next two or three blocks are found.
With only 5% of hashpower, it will take around three hours for Carol
and friends to find a block in general.

Also, the fact that segwit outputs are "anyone can spend" maybe mitigates
this further -- you could have a vigilante node that creates invalid
segwit txns for every segwit output that just spends the entire thing
to fees. Even if the vigilante's transactions get rejected by nodes who
see Mallory's attempt first, that should still be enough to trigger any
sort of double-spend alerts I can think of, at least if anyone at all
is altruistic enough to run a vigilante node like that in the first place.

> Mallory gets free beer.
> Anything I'm missing?

So I think the only way Mallory gets free beer from you with segwit
soft-fork is if:

 - you're running out of date software and you're ignoring warnings to
   upgrade (block versions have bumped)
 - you've turned off standardness checks
 - you're accepting low-confirmation transactions
 - you're not using any double-spend detection service

If you're not accepting zero-confirmation transactions straight from
the mempool, (ie you require 1 or 2 confirmations) you also need:

 - some non-upgraded miners who have turned off standardness checks
 - your business is setup that an attacker can happily wait hours for
   the transaction to be included in a block before trying to get beer
   from you

In general (IMO), just leaving standardness checks turned on (and waiting
for 6 confirmations before accepting any non-standard transaction) should
be enough to keep you safe from any attack a soft-fork might enable.

Upgrading your software regularly should also be enough to keep you safe
for any soft-fork, and also for any hard-fork, obviously.

Cheers,
aj

[0] Actually, for this attack Mallory could use *any* segwit payment, it
    doesn't have to be his bitcoins to start with, he just has to make
    it look like they finish up with him, which is trivial if segwit
    looks like anyone can spend. Having it be his segwit payment in the
    first place makes it a little easier to ensure his payment is seen
    as the original and not the doublespend though.



^ permalink raw reply	[|nested] 12+ messages in thread
2015-12-18 12:18     ` Peter Todd

  
From: Bryan Bishop @ 2015-12-19 15:48 UTC (permalink / raw)
  To: Peter Todd, Bryan Bishop;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 861 bytes --]

 permalink raw reply	[|nested]
2015-12-18  2:47 ` Jonathan Toomim
                     ` (3 preceding siblings ...)
  2015-12-19  1:36   ` Chris

  2015-12-20  4:14   ` Rusty Russell
  
From: Andrew @ 2015-12-19 17:46 UTC (permalink / raw)
  To: Jonathan Toomim;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]

On Fri, Dec 18, 2015 at 2:47 AM, Jonathan Toomim via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

>
> 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.
>
> What do you mean a valid transaction chain? If Bob is fully validating
(even with old software), he should see that Mallory's signature is not on
a transaction with his address.

Do you mean Mallory creates a regular transaction as well as an
Anyone-can-spend segwit transaction that results in double spending in the
same block?

Sorry not sure what I'm missing...


> 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
>
>


-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647

[-- Attachment #2: Type: text/html, Size: 6291 bytes --]

 permalink raw reply	[|nested]
2015-12-18  2:47 ` Jonathan Toomim
                     ` (4 preceding siblings ...)
  2015-12-19 17:46   ` Andrew

  2015-12-20 19:16     ` jl2012
  
From: Rusty Russell @ 2015-12-20  4:14 UTC (permalink / raw)
  To: Jonathan Toomim, Pieter Wuille;  Bitcoin Dev

Jonathan Toomim via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
writes:
> 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.

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

Cheers,
Rusty.


 permalink raw reply	[|nested]
2015-12-20  4:14   ` Rusty Russell

  
From: jl2012 @ 2015-12-20 19:16 UTC ( / )
  To: Rusty Russell;  Bitcoin Dev

Rusty Russell via bitcoin-dev 於 2015-12-19 23:14 寫到:
> Jonathan Toomim via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
> writes:
>> 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.
> 
> Pretty sure Bob's wallet will be looking for "OP_DUP OP_HASH160
> <pubKeyHash> 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.