š
Original date posted:2015-12-30
š Original message:I guess the same could be said about the softfork flavoured SW
implementation. In any case, the strategy pattern helps with code structure
in situations like this.
2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> As a first impression, I think this proposal is intellectually
> interesting, but crufty and hackish and should never actually be deployed.
> Writing code for Bitcoin in a future in which we have deployed a few
> generalized softforks this way sounds terrifying.
>
> Instead of this:
>
> CTransaction GetTransaction(CBlock block, unsigned int index) {
> return block->vtx[index];
> }
>
> We might have this:
>
> CTransaction GetTransaction(CBlock block, unsigned int index) {
> if (!IsBIP102sBlock(block)) {
> return block->vtx[index];
> } else {
> if (!IsOtherGeneralizedSoftforkBlock(block)) {
> // hooray! only one generalized softfork level to deal
> with!
> return
> LookupBlock(GetGSHashFromCoinbase(block->vtx[0].vin[0].scriptSig))->vtx[index];
> } else {
> throw NotImplementedError; // I'm too lazy to write
> pseudocode this complicated just to argue a point
> }
> }
>
> It might be possible to make that a bit simpler with recursion, or by
> doing subsequent generalized softforks in a way that doesn't have
> multi-levels-deep block-within-a-block-within-a-block stuff. Still: ugh.
>
>
>
>
> On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Below is a proof-of-concept implementation of BIP102 as a softfork:
> >
> > https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize
> >
> https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split&name=2015_2mb_blocksize
> >
> > BIP102 is normally a hardfork. The softfork version (unofficial
> > codename BIP102s) uses the idea described here:
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html
> >
> > The basic idea is that post-fork blocks are constructed in such a way
> > they can be mapped to valid blocks under the pre-fork rules. BIP102s
> > is a softfork in the sense that post-fork miners are still creating a
> > valid chain under the old rules, albeit indirectly.
> >
> > From the POV of non-upgraded clients, BIP102s circumvents the
> > block-size limit by moving transaction validation data "outside" of
> > the block. This is a similar trick used by Segregated Witness and
> > Extension Blocks (both softfork proposals).
> >
> > From the POV of upgraded clients, the block layout is unchanged,
> > except:
> > - A larger 2MB block-size limit (=BIP102);
> > - The header Merkle root has a new (backwards compatible)
> > interpretation;
> > - The coinbase encodes the Merkle root of the remaining txs.
> > Aside from this, blocks maintain their original format, i.e. a block
> > header followed by a vector of transactions. This keeps the
> > implementation simple, and is distinct from SW and EB.
> >
> > Since BIP102s is a softfork it means that:
> > - A miner majority (e.g. 75%, 95%) force miner consensus (100%). This
> > is not true for a hardfork.
> > - Fraud risk is significantly reduced (6-conf unlikely depending on
> > activation threshold).
> > This should address some of the concerns with deploying a block-size
> > increase using a hardfork.
> >
> > Notes:
> >
> > - The same basic idea could be adapted to any of the other proposals
> > (BIP101, 2-4-8, BIP202, etc.).
> > - I used Jeff Garzik's BIP102 implementation which is incomplete (?).
> > The activation logic is left unchanged.
> > - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my
> > code :-(
> >
> > --joe
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> 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/20151230/5c2838ea/attachment.html>;
Marcel Jamin [ARCHIVE] /
npub14jā¦vk3rk
2023-06-07 17:47:24
in reply to nevent1qā¦d3v5
Author Public Key
npub14jegtpz2t9nfnefqqr0q4te9353e4k4x5y2528qf235ruluzsaes8vk3rkPublished at
2023-06-07 17:47:24Event JSON
{
"id": "04de7219ef86270341504c5e0060c4b6d204e7bca9d227b39f59f9cdfb81cf13",
"pubkey": "acb285844a596699e52000de0aaf258d239adaa6a115451c0954683e7f828773",
"created_at": 1686160044,
"kind": 1,
"tags": [
[
"e",
"410a15ecaf9eb209e9831774c35dbf549a77975bb49e6a60c2dbf869774cfd1f",
"",
"root"
],
[
"e",
"742554ec82fdf1e05af5b1394af639a07c2f45858f1a92937d01181b6d8e12d5",
"",
"reply"
],
[
"p",
"0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569"
]
],
"content": "š
Original date posted:2015-12-30\nš Original message:I guess the same could be said about the softfork flavoured SW\nimplementation. In any case, the strategy pattern helps with code structure\nin situations like this.\n\n2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e As a first impression, I think this proposal is intellectually\n\u003e interesting, but crufty and hackish and should never actually be deployed.\n\u003e Writing code for Bitcoin in a future in which we have deployed a few\n\u003e generalized softforks this way sounds terrifying.\n\u003e\n\u003e Instead of this:\n\u003e\n\u003e CTransaction GetTransaction(CBlock block, unsigned int index) {\n\u003e return block-\u003evtx[index];\n\u003e }\n\u003e\n\u003e We might have this:\n\u003e\n\u003e CTransaction GetTransaction(CBlock block, unsigned int index) {\n\u003e if (!IsBIP102sBlock(block)) {\n\u003e return block-\u003evtx[index];\n\u003e } else {\n\u003e if (!IsOtherGeneralizedSoftforkBlock(block)) {\n\u003e // hooray! only one generalized softfork level to deal\n\u003e with!\n\u003e return\n\u003e LookupBlock(GetGSHashFromCoinbase(block-\u003evtx[0].vin[0].scriptSig))-\u003evtx[index];\n\u003e } else {\n\u003e throw NotImplementedError; // I'm too lazy to write\n\u003e pseudocode this complicated just to argue a point\n\u003e }\n\u003e }\n\u003e\n\u003e It might be possible to make that a bit simpler with recursion, or by\n\u003e doing subsequent generalized softforks in a way that doesn't have\n\u003e multi-levels-deep block-within-a-block-within-a-block stuff. Still: ugh.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e \u003e Below is a proof-of-concept implementation of BIP102 as a softfork:\n\u003e \u003e\n\u003e \u003e https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize\n\u003e \u003e\n\u003e https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split\u0026name=2015_2mb_blocksize\n\u003e \u003e\n\u003e \u003e BIP102 is normally a hardfork. The softfork version (unofficial\n\u003e \u003e codename BIP102s) uses the idea described here:\n\u003e \u003e\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html\n\u003e \u003e\n\u003e \u003e The basic idea is that post-fork blocks are constructed in such a way\n\u003e \u003e they can be mapped to valid blocks under the pre-fork rules. BIP102s\n\u003e \u003e is a softfork in the sense that post-fork miners are still creating a\n\u003e \u003e valid chain under the old rules, albeit indirectly.\n\u003e \u003e\n\u003e \u003e From the POV of non-upgraded clients, BIP102s circumvents the\n\u003e \u003e block-size limit by moving transaction validation data \"outside\" of\n\u003e \u003e the block. This is a similar trick used by Segregated Witness and\n\u003e \u003e Extension Blocks (both softfork proposals).\n\u003e \u003e\n\u003e \u003e From the POV of upgraded clients, the block layout is unchanged,\n\u003e \u003e except:\n\u003e \u003e - A larger 2MB block-size limit (=BIP102);\n\u003e \u003e - The header Merkle root has a new (backwards compatible)\n\u003e \u003e interpretation;\n\u003e \u003e - The coinbase encodes the Merkle root of the remaining txs.\n\u003e \u003e Aside from this, blocks maintain their original format, i.e. a block\n\u003e \u003e header followed by a vector of transactions. This keeps the\n\u003e \u003e implementation simple, and is distinct from SW and EB.\n\u003e \u003e\n\u003e \u003e Since BIP102s is a softfork it means that:\n\u003e \u003e - A miner majority (e.g. 75%, 95%) force miner consensus (100%). This\n\u003e \u003e is not true for a hardfork.\n\u003e \u003e - Fraud risk is significantly reduced (6-conf unlikely depending on\n\u003e \u003e activation threshold).\n\u003e \u003e This should address some of the concerns with deploying a block-size\n\u003e \u003e increase using a hardfork.\n\u003e \u003e\n\u003e \u003e Notes:\n\u003e \u003e\n\u003e \u003e - The same basic idea could be adapted to any of the other proposals\n\u003e \u003e (BIP101, 2-4-8, BIP202, etc.).\n\u003e \u003e - I used Jeff Garzik's BIP102 implementation which is incomplete (?).\n\u003e \u003e The activation logic is left unchanged.\n\u003e \u003e - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my\n\u003e \u003e code :-(\n\u003e \u003e\n\u003e \u003e --joe\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\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/20151230/5c2838ea/attachment.html\u003e",
"sig": "ca415606779a3b9b9dfe8e066eb2799e9cb6a152dbf6f85b5b90379dc340010ad64dce43f5d7891660265fecc0d14e396102c20329980da83f24651ac3a16508"
}