📅 Original date posted:2015-10-05 📝 Original message:It will get correct ...

Clément Elbaz [ARCHIVE] /

npub164f…ec7x

2023-06-07 17:41:59

in reply to nevent1q…qe6v

📅 Original date posted:2015-10-05
📝 Original message:It will get correct results about :
- the existence every block
- the existence of every transaction

It will get incorrect results :
- about the *nature* of some transactions
- and therefore, about the balances of some wallets.

I fully agree with Mike here.

Le lun. 5 oct. 2015 à 14:04, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> a écrit :

>
> On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Well, let's agree to disagree on these two things:
> >
> > - I define "working" for a full node as verifying everything; if a node
> starts skipping bits then I'd say it's not really "working" according to
> its original design goals
>
> But assuming the hashrate majority has upgraded (and we're using 95% as
> the miner upgrade confirmation threshold to start activation, so that
> assumption seems pretty safe), a non-upgraded full node and an upgraded
> full will converge on what they see: "the most-work valid chain" will be
> the same for both. A non-upgraded full node wallet waiting for several
> confirmations (for example, 6 confirmations) will be just as safe as an
> upgraded one. In that sense, it keeps working. On top of that, nodes (of
> any kind) can use unknown block version numbers to notify the user or even
> stop working (the same notification mechanism you would use with hardforks).
>
> I agree that hardforks are necessary and we should deploy a hardfork asap
> to show the world they are indeed possible (bip99 proposes a likely
> uncontroversial one), but I still believe that is clear that softfork
> deployment is preferrable in many cases like this one.
>
> Are you going to produce a bip65 hardfork alternative to try to convince
> people of its advantages over bip65 (it is not clear to me how you include
> a new script operand via hardfork)?
> _______________________________________________
> 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/20151005/eea49466/attachment.html>;

Author Public Key

npub164fseem24m3rdpqrkq9jkx5n4d6r4wg0cthw8669gag3xszngfrsvfec7x

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 17:41:59

Kind type

1 Short Text Note

Event JSON

{ "id": "804e79de96bea6a1ccaa0558294db13e0edfa885d7f5887517ac3a5966b543ac", "pubkey": "d5530ce76aaee2368403b00b2b1a93ab743ab90fc2eee3eb4547511340534247", "created_at": 1686159719, "kind": 1, "tags": [ [ "e", "7ff2050ebdfe33f92ad46edcffb5d61f26a94f61437237faeeaedfedde460e1c", "", "root" ], [ "e", "772a4c143dbc3db056384b511025270385254dd7355cb9d7afab66269c47acba", "", "reply" ], [ "p", "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84" ] ], "content": "📅 Original date posted:2015-10-05\n📝 Original message:It will get correct results about :\n- the existence every block\n- the existence of every transaction\n\nIt will get incorrect results :\n- about the *nature* of some transactions\n- and therefore, about the balances of some wallets.\n\nI fully agree with Mike here.\n\nLe lun. 5 oct. 2015 à 14:04, Jorge Timón \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e\n\u003e On Oct 5, 2015 1:28 PM, \"Mike Hearn via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e Well, let's agree to disagree on these two things:\n\u003e \u003e\n\u003e \u003e - I define \"working\" for a full node as verifying everything; if a node\n\u003e starts skipping bits then I'd say it's not really \"working\" according to\n\u003e its original design goals\n\u003e\n\u003e But assuming the hashrate majority has upgraded (and we're using 95% as\n\u003e the miner upgrade confirmation threshold to start activation, so that\n\u003e assumption seems pretty safe), a non-upgraded full node and an upgraded\n\u003e full will converge on what they see: \"the most-work valid chain\" will be\n\u003e the same for both. A non-upgraded full node wallet waiting for several\n\u003e confirmations (for example, 6 confirmations) will be just as safe as an\n\u003e upgraded one. In that sense, it keeps working. On top of that, nodes (of\n\u003e any kind) can use unknown block version numbers to notify the user or even\n\u003e stop working (the same notification mechanism you would use with hardforks).\n\u003e\n\u003e I agree that hardforks are necessary and we should deploy a hardfork asap\n\u003e to show the world they are indeed possible (bip99 proposes a likely\n\u003e uncontroversial one), but I still believe that is clear that softfork\n\u003e deployment is preferrable in many cases like this one.\n\u003e\n\u003e Are you going to produce a bip65 hardfork alternative to try to convince\n\u003e people of its advantages over bip65 (it is not clear to me how you include\n\u003e a new script operand via hardfork)?\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/eea49466/attachment.html\u003e", "sig": "b1353eb4219ef925fe1f2c6a6a419ca974fcbff08aa87aa4fa60fb36849473edcfb65710eafcee431c4a9ab7a1308193ed5e7bd125fecde072ff70508620ad7e" }