public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Natanael <natanael.l@gmail.com>
To: Chris Acheson <mail@chrisacheson.net>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
Date: Sat, 15 Apr 2017 15:23:35 +0200	[thread overview]
Message-ID: <CAAt2M19-R83VS2PB6ppjqSH4cSXT--5M=QxUFLpYDr8iMnpGpQ@mail.gmail.com> (raw)
In-Reply-To: <2941cf86-422f-6a88-fb44-9ac01c5e996a@chrisacheson.net>

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

Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:


Not sure if you missed my previous reply to you, but I'm curious about
your thoughts on this particular point. I contend that for any UASF,
orphaning non-signalling blocks on the flag date is [maybe] safer [for
those in on the UASF fork] than just
considering the fork active on the flag date.


Note my additions.

Enforcement by orphaning non-compliance makes it harder to reverse a buggy
softfork, since you necessarily increase the effort needed to return enough
mining power to the safe chain since you now have mostly unmonitored mining
hardware fighting you actively, whose operators you might not be able to
contact. You'd practically have to hardfork out of the situation.

There's also the risk of the activation itself triggering concensus bugs
(multiple incompatible UASF forks), if there's multiple implementations of
it in the network (or one buggy one). We have already seen something like
it happen. This can both happen on the miner side, client side or both
(miner side only would lead to a ton of orphaned blocks, client side means
netsplit).

It is also not economically favorable for any individual miner to be the
one to mine empty blocks on top of any surviving softfork-incompatible
chain. As a miner you would only volunteer to do it if you believe the
softfork is necessary or itself will enable greater future profit.

Besides that, I also just don't believe that UASF itself as a method to
activate softforks is a good choice. The only two reliable signals we have
for this purpose in Bitcoin are block height (flag day) and standard miner
signaling, as every other metric can be falsified or gamed.

But there's also more problems - a big one is that we have no way right now
for a node to tell another "the transaction you just relayed to me is
invalid according to an active softfork" (or "will become invalid". This
matters for several reasons.

The first one that came to my mind is that we have widespread usage of
zero-confirmation payments in the network.

This was already dangerous for other reasons, but this UASF could make it
guaranteed cost-free to exploit - because as many also know, we ALSO
already have a lot of nodes that do not enforce the non-default rejection
policies (otherwise we'd never see such transactions on blocks), including
many alternative Bitcoin clients.

The combination of these factors means that you can present an UASF invalid
transaction to a non-updated client that is supposedly protected by the
deliberate orphaning effort, and have it accept this as a payment. To never
see it get confirmed, or to eventually see it doublespent by an UASF-valid
transaction.

I would not at all be surprised if it turned out that many
zero-confirmation accepting services do not reject non-default
transactions, or if they aren't all UASF-segwit aware.

This is why a flag day or similar is more effective - it can't be ignored
unlike "just another one of those UASF proposals" that you might not have
evaluated or not expect to activate.

This is by the way also a reason that I believe that all nodes and services
should publish all concensus critical policies that they enforce. This
would make it far easier to alert somebody that they NEED TO prepare for
whatever proposal that might conflict with their active policies.

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

  reply	other threads:[~2017-04-15 13:23 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-14  7:56 [bitcoin-dev] I do not support the BIP 148 UASF Gregory Maxwell
2017-04-14 16:50 ` praxeology_guy
2017-04-14 17:36   ` Chris Stewart
2017-04-14 18:33     ` praxeology_guy
2017-04-14 19:12   ` Tom Zander
2017-04-14 19:20 ` Tom Zander
2017-04-14 19:33   ` James Hilliard
2017-04-14 20:34     ` Tom Zander
2017-04-14 20:51       ` James Hilliard
2017-04-14 20:58         ` Tom Zander
2017-04-14 21:10           ` James Hilliard
2017-04-14 21:12             ` Gregory Maxwell
2017-04-14 20:59       ` Gregory Maxwell
2017-04-15  2:01 ` Steven Pine
2017-04-15  3:05   ` Chris Stewart
2017-04-15  3:29   ` Gregory Maxwell
2017-04-15  4:10     ` Steven Pine
2017-04-15  4:47       ` Gregory Maxwell
2017-04-15  6:28 ` Cameron Garnham
2017-04-15  7:04   ` Gregory Maxwell
2017-04-15  7:46     ` Chris Acheson
2017-04-15 13:23       ` Natanael [this message]
2017-04-15 13:54         ` Greg Sanders
2017-04-15  8:05     ` Cameron Garnham
2017-04-20 18:39 ` shaolinfry
2017-04-25 18:28   ` Gregory Maxwell
2017-04-25 18:46     ` Luke Dashjr
2017-05-02 16:54       ` Erik Aronesty
2017-05-22 19:23 ` Suhas Daftuar
2017-05-23  4:03   ` Steven Pine
2017-05-23  6:30     ` Karl Johan Alm
2017-05-23 12:55       ` Luke Dashjr
2017-05-23 13:20         ` Jorge Timón
2017-05-23  9:47     ` Hampus Sjöberg
2017-04-14 10:52 Chris Acheson
2017-04-15 13:42 Mark Friedenbach
2017-04-15 14:54 ` Ryan Grant
2017-04-15 18:50 ` Gregory Maxwell
2017-04-19 16:17   ` Erik Aronesty
2017-04-20 14:23     ` Alphonse Pace
2017-04-20 15:48       ` Erik Aronesty

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='CAAt2M19-R83VS2PB6ppjqSH4cSXT--5M=QxUFLpYDr8iMnpGpQ@mail.gmail.com' \
    --to=natanael.l@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mail@chrisacheson.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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