đ
Original date posted:2017-04-15
đ Original message:> 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.
UASF can be just a flag day.
On Sat, Apr 15, 2017 at 9:23 AM, Natanael via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" <
> bitcoin-dev at 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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170415/3a6b3e64/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jdâŚ3gh0m
2023-06-07 18:00:10
in reply to nevent1qâŚz22m
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-07 18:00:10Event JSON
{
"id": "8446e5ee68410ded76995139965661dbcef8204dd4e1dc4038d4ffd49dea383b",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686160810,
"kind": 1,
"tags": [
[
"e",
"5d1e64c970da07b0178aa4b0869114a6c0b54023e99bc79f83d180601afc646b",
"",
"root"
],
[
"e",
"133bf21e23713c7a1e61ed658bc7b343c8d66550ca9618b9b0ce92b6779ae91d",
"",
"reply"
],
[
"p",
"f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018"
]
],
"content": "đ
Original date posted:2017-04-15\nđ Original message:\u003e Besides that, I also just don't believe that UASF itself as a method to\nactivate softforks is a good choice. The only two reliable signals we have\nfor this purpose in Bitcoin are block height (flag day) and standard miner\nsignaling, as every other metric can be falsified or gamed.\n\nUASF can be just a flag day.\n\nOn Sat, Apr 15, 2017 at 9:23 AM, Natanael via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e\n\u003e Den 15 apr. 2017 13:51 skrev \"Chris Acheson via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e:\n\u003e\n\u003e\n\u003e Not sure if you missed my previous reply to you, but I'm curious about\n\u003e your thoughts on this particular point. I contend that for any UASF,\n\u003e orphaning non-signalling blocks on the flag date is [maybe] safer [for\n\u003e those in on the UASF fork] than just\n\u003e considering the fork active on the flag date.\n\u003e\n\u003e\n\u003e Note my additions.\n\u003e\n\u003e Enforcement by orphaning non-compliance makes it harder to reverse a buggy\n\u003e softfork, since you necessarily increase the effort needed to return enough\n\u003e mining power to the safe chain since you now have mostly unmonitored mining\n\u003e hardware fighting you actively, whose operators you might not be able to\n\u003e contact. You'd practically have to hardfork out of the situation.\n\u003e\n\u003e There's also the risk of the activation itself triggering concensus bugs\n\u003e (multiple incompatible UASF forks), if there's multiple implementations of\n\u003e it in the network (or one buggy one). We have already seen something like\n\u003e it happen. This can both happen on the miner side, client side or both\n\u003e (miner side only would lead to a ton of orphaned blocks, client side means\n\u003e netsplit).\n\u003e\n\u003e It is also not economically favorable for any individual miner to be the\n\u003e one to mine empty blocks on top of any surviving softfork-incompatible\n\u003e chain. As a miner you would only volunteer to do it if you believe the\n\u003e softfork is necessary or itself will enable greater future profit.\n\u003e\n\u003e Besides that, I also just don't believe that UASF itself as a method to\n\u003e activate softforks is a good choice. The only two reliable signals we have\n\u003e for this purpose in Bitcoin are block height (flag day) and standard miner\n\u003e signaling, as every other metric can be falsified or gamed.\n\u003e\n\u003e But there's also more problems - a big one is that we have no way right\n\u003e now for a node to tell another \"the transaction you just relayed to me is\n\u003e invalid according to an active softfork\" (or \"will become invalid\". This\n\u003e matters for several reasons.\n\u003e\n\u003e The first one that came to my mind is that we have widespread usage of\n\u003e zero-confirmation payments in the network.\n\u003e\n\u003e This was already dangerous for other reasons, but this UASF could make it\n\u003e guaranteed cost-free to exploit - because as many also know, we ALSO\n\u003e already have a lot of nodes that do not enforce the non-default rejection\n\u003e policies (otherwise we'd never see such transactions on blocks), including\n\u003e many alternative Bitcoin clients.\n\u003e\n\u003e The combination of these factors means that you can present an UASF\n\u003e invalid transaction to a non-updated client that is supposedly protected by\n\u003e the deliberate orphaning effort, and have it accept this as a payment. To\n\u003e never see it get confirmed, or to eventually see it doublespent by an\n\u003e UASF-valid transaction.\n\u003e\n\u003e I would not at all be surprised if it turned out that many\n\u003e zero-confirmation accepting services do not reject non-default\n\u003e transactions, or if they aren't all UASF-segwit aware.\n\u003e\n\u003e This is why a flag day or similar is more effective - it can't be ignored\n\u003e unlike \"just another one of those UASF proposals\" that you might not have\n\u003e evaluated or not expect to activate.\n\u003e\n\u003e This is by the way also a reason that I believe that all nodes and\n\u003e services should publish all concensus critical policies that they enforce.\n\u003e This would make it far easier to alert somebody that they NEED TO prepare\n\u003e for whatever proposal that might conflict with their active policies.\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170415/3a6b3e64/attachment.html\u003e",
"sig": "7d8ca8cb1f791ee2a5a1fe58b4b7a248a7f2e64d53d59c92db0473879890d99c101992cb9b2c450868a209f47807a6bc734930afc8e2de75273bd69a0f825f2c"
}