From: Mike Hearn <hearn@vinumeris•com>
To: "Jorge Timón" <jtimon@jtimon•cc>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Mon, 5 Oct 2015 18:46:28 +0200 [thread overview]
Message-ID: <CA+w+GKRjURkV40iG=6RLhFyQ-t2G_YAinKk7Os_8zK4+hyYJaw@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDpgpRg9U5ToNM98pQgz8VRwT8o817zrpJgOj06PwySk_Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3313 bytes --]
>
> As Greg explained to you repeatedly, a softfork won't cause a
> non-upgraded full node to start accepting blocks that create more
> subsidy than is valid.
>
It was an example. Adam Back's extension blocks proposal would, in fact,
allow for a soft forking change that creates more subsidy than is valid (or
does anything else) by hiding one block inside another.
Anyway, I think you got my point.
> That's very different security from an SPV node, and as Greg
> also explained, SPV nodes could be much more secure than bitcoinj
> nodes (they could, for example, validate the coinbase transaction of
> every block).
>
I'm pretty sure Gregory did not use such an example because it's dead
wrong. You cannot verify the size of a coinbase without being a fully
verifying node because you need to know the fees in the block, and
calculating that requires access to the entire UTXO set.
This sort of thing is why I get annoyed when people lecture me about SPV
wallets and the things they "should" do. None of you guys has built one. I
keep seeing wild statements about theoretical unicorn wallets that nobody
has even designed, and how all existing wallets are crappy and insecure
because they don't meet your ever shifting goal posts.
To everyone making such statements I say: go away and build an SPV wallet
of your own from scratch. Then you will understand the engineering
tradeoffs involved much better, and be in a much better position to debate
what they should or should not be doing.
And bear in mind if it weren't for the work myself and a few others did on
SPV wallets, everyone would be using web wallets instead. Then you'd all
just complain about that instead.
> Can you give an example of an attack in which a non-upgraded full node
> wallet is defrauded with BIP65 but could not with the hardfork
> alternative (that nobody seems to be willing to implement)?
>
Making it a hard fork instead is changing one line of code (ignoring the
code to set up the flag day, which can be based on the code for BIP101). If
it comes down to it, then I'll do the work to change that one line. But
obviously I'd need to see agreement from the maintainers that such a pull
req would be merged first.
The example is this: find someone that accepts 1-block confirmed
transactions in return for something valuable. There are plenty of them out
there. Once the soft fork starts, send a P2SH transaction that defines a
new output controlled by OP_CLTV. It will be incorporated into the UTXO set
by all miners because it's opaque (p2sh).
Now send a transaction that pays the merchant, and make it spend your
OP_CLTV output with an invalid script. New nodes will reject it as a rule
violator. Old nodes won't. So at some point an old miner will create a
block containing your invalid transaction, the merchant will think they got
paid, they'll give you the stuff and the fraud is done.
> Please, don't assume 0 confirmation transactions or similar
> unreasonable assumptions (ie see section 11 "Calculations" of the
> Bitcoin whitepaper).
>
This is just embarrassing - do any of you guys at Blockstream actually use
Bitcoin in the real world? Virtually all payments that aren't moving money
into/out of exchange wallets are 0-confirm in reality. I described a
1-confirm attack above, but really ... come on.
[-- Attachment #2: Type: text/html, Size: 4485 bytes --]
next prev parent reply other threads:[~2015-10-05 16:46 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 1:57 NotMike Hearn
2015-10-02 2:12 ` GC
2015-10-05 10:59 ` Mike Hearn
2015-10-05 11:23 ` Jeff Garzik
2015-10-05 11:28 ` Mike Hearn
2015-10-05 12:04 ` Jorge Timón
2015-10-05 12:08 ` Clément Elbaz
2015-10-05 12:16 ` Jorge Timón
2015-10-05 12:29 ` Clément Elbaz
2015-10-05 15:42 ` Jorge Timón
2015-10-05 12:10 ` Mike Hearn
2015-10-05 15:33 ` Jorge Timón
2015-10-05 16:46 ` Mike Hearn [this message]
2015-10-06 6:20 ` Anthony Towns
2015-10-07 6:13 ` Micha Bailey
2015-10-05 13:29 ` Jorge Timón
2015-10-05 13:24 ` Jorge Timón
-- strict thread matches above, loose matches on Subject: below --
2015-09-27 18:50 Peter Todd
2015-09-27 20:26 ` jl2012
2015-09-27 20:27 ` Peter Todd
2015-09-27 20:27 ` Mark Friedenbach
2015-09-27 20:41 ` Btc Drak
2015-09-28 10:10 ` s7r
2015-09-28 10:48 ` Mike Hearn
2015-09-28 11:00 ` Adam Back
2015-09-28 11:40 ` Mike Hearn
2015-09-28 12:20 ` Eric Lombrozo
2015-09-28 12:26 ` Mike Hearn
2015-09-28 12:44 ` Eric Lombrozo
2015-09-28 12:54 ` Mike Hearn
2015-09-29 6:17 ` Eric Lombrozo
2015-09-29 12:02 ` Mike Hearn
2015-09-28 14:05 ` Btc Drak
2015-09-28 14:17 ` Mike Hearn
2015-09-28 21:12 ` odinn
2015-09-28 22:16 ` Dave Scotese
2015-09-28 11:04 ` Eric Lombrozo
2015-09-28 12:47 ` Tier Nolan
2015-09-28 13:01 ` Gavin Andresen
2015-09-28 13:28 ` Peter Todd
2015-09-28 13:43 ` Gavin Andresen
2015-09-28 14:14 ` Peter Todd
2015-09-28 13:21 ` Peter Todd
2015-09-28 13:41 ` Mike Hearn
2015-09-28 14:29 ` Peter Todd
2015-09-28 14:33 ` Mike Hearn
2015-09-28 14:43 ` Peter Todd
2015-09-28 14:51 ` Mike Hearn
2015-09-28 15:05 ` Peter Todd
2015-09-28 15:38 ` Mike Hearn
2015-09-28 16:52 ` jl2012
2015-09-28 17:14 ` Mike Hearn
2015-09-28 23:17 ` Jorge Timón
2015-09-29 12:07 ` Mike Hearn
2015-09-29 13:30 ` Jonathan Toomim (Toomim Bros)
2015-09-29 15:59 ` jl2012
2015-09-29 19:54 ` odinn
2015-09-29 18:31 ` Gregory Maxwell
2015-09-30 17:11 ` Mike Hearn
2015-09-30 17:58 ` Jorge Timón
2015-10-01 14:23 ` Tom Harding
2015-09-30 18:15 ` Adam Back
2015-09-30 19:26 ` Jeff Garzik
2015-09-30 19:56 ` Mike Hearn
2015-09-30 20:37 ` Jorge Timón
2015-09-30 21:06 ` Mike Hearn
2015-09-30 22:14 ` Jorge Timón
2015-10-01 0:11 ` Jorge Timón
2015-09-30 22:17 ` Jeff Garzik
2015-09-30 23:25 ` Gregory Maxwell
2015-09-30 20:15 ` Gregory Maxwell
2015-09-30 21:01 ` Mike Hearn
2015-09-30 22:59 ` Gregory Maxwell
2015-10-07 15:00 ` Anthony Towns
2015-10-07 15:46 ` Jonathan Toomim (Toomim Bros)
2015-10-07 16:02 ` Eric Lombrozo
2015-10-07 16:25 ` Eric Lombrozo
2015-10-07 16:26 ` Jonathan Toomim (Toomim Bros)
2015-10-07 16:38 ` Anthony Towns
2015-10-10 7:23 ` Anthony Towns
2015-10-12 7:02 ` digitsu
2015-10-12 16:33 ` Anthony Towns
2015-10-12 17:06 ` Anthony Towns
2015-10-13 0:08 ` digitsu
2015-09-29 20:03 ` Wladimir J. van der Laan
2015-09-30 4:05 ` Rusty Russell
2015-09-30 6:19 ` Adam Back
2015-09-30 12:30 ` Mike Hearn
2015-09-30 15:55 ` Jorge Timón
2015-09-30 19:17 ` John Winslow
2015-10-01 0:06 ` Rusty Russell
2015-09-30 17:14 ` Adam Back
2015-10-01 0:04 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+w+GKRjURkV40iG=6RLhFyQ-t2G_YAinKk7Os_8zK4+hyYJaw@mail.gmail.com' \
--to=hearn@vinumeris$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox