📅 Original date posted:2015-12-30
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/fd516c4a/attachment.sig>;
Jonathan Toomim [ARCHIVE] /
npub1pl…yj0hj
2023-06-07 17:47:23
in reply to nevent1q…j8jq
Author Public Key
npub1pl6kcz00s7wgn6syh73dta0qm9sqpmtw4adv8rnm2w9fmynkw45sayj0hjPublished at
2023-06-07 17:47:23Event JSON
{
"id": "742554ec82fdf1e05af5b1394af639a07c2f45858f1a92937d01181b6d8e12d5",
"pubkey": "0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569",
"created_at": 1686160043,
"kind": 1,
"tags": [
[
"e",
"410a15ecaf9eb209e9831774c35dbf549a77975bb49e6a60c2dbf869774cfd1f",
"",
"root"
],
[
"e",
"4c84dc8cc1a1e4c362d8bf6e72e16fbab006b66070f5a1f002634dfff4f07513",
"",
"reply"
],
[
"p",
"43b7b510fe55636e529592954f52b81d7edf0b64a73b26d83b434b89b3b927b1"
]
],
"content": "📅 Original date posted:2015-12-30\n📝 Original message: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.\n\nInstead of this:\n\n CTransaction GetTransaction(CBlock block, unsigned int index) {\n return block-\u003evtx[index];\n }\n\nWe might have this:\n\n CTransaction GetTransaction(CBlock block, unsigned int index) {\n if (!IsBIP102sBlock(block)) {\n return block-\u003evtx[index];\n } else {\n if (!IsOtherGeneralizedSoftforkBlock(block)) {\n // hooray! only one generalized softfork level to deal with!\n return LookupBlock(GetGSHashFromCoinbase(block-\u003evtx[0].vin[0].scriptSig))-\u003evtx[index];\n } else {\n throw NotImplementedError; // I'm too lazy to write pseudocode this complicated just to argue a point\n }\n }\n\nIt 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.\n\n\n\n\nOn Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Below is a proof-of-concept implementation of BIP102 as a softfork:\n\u003e \n\u003e https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize\n\u003e https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split\u0026name=2015_2mb_blocksize\n\u003e \n\u003e BIP102 is normally a hardfork. The softfork version (unofficial\n\u003e codename BIP102s) uses the idea described here:\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html\n\u003e \n\u003e The basic idea is that post-fork blocks are constructed in such a way\n\u003e they can be mapped to valid blocks under the pre-fork rules. BIP102s\n\u003e is a softfork in the sense that post-fork miners are still creating a\n\u003e valid chain under the old rules, albeit indirectly.\n\u003e \n\u003e From the POV of non-upgraded clients, BIP102s circumvents the\n\u003e block-size limit by moving transaction validation data \"outside\" of\n\u003e the block. This is a similar trick used by Segregated Witness and\n\u003e Extension Blocks (both softfork proposals).\n\u003e \n\u003e From the POV of upgraded clients, the block layout is unchanged,\n\u003e except:\n\u003e - A larger 2MB block-size limit (=BIP102);\n\u003e - The header Merkle root has a new (backwards compatible)\n\u003e interpretation;\n\u003e - The coinbase encodes the Merkle root of the remaining txs.\n\u003e Aside from this, blocks maintain their original format, i.e. a block\n\u003e header followed by a vector of transactions. This keeps the\n\u003e implementation simple, and is distinct from SW and EB.\n\u003e \n\u003e Since BIP102s is a softfork it means that:\n\u003e - A miner majority (e.g. 75%, 95%) force miner consensus (100%). This\n\u003e is not true for a hardfork.\n\u003e - Fraud risk is significantly reduced (6-conf unlikely depending on\n\u003e activation threshold).\n\u003e This should address some of the concerns with deploying a block-size\n\u003e increase using a hardfork.\n\u003e \n\u003e Notes:\n\u003e \n\u003e - The same basic idea could be adapted to any of the other proposals\n\u003e (BIP101, 2-4-8, BIP202, etc.).\n\u003e - I used Jeff Garzik's BIP102 implementation which is incomplete (?).\n\u003e The activation logic is left unchanged.\n\u003e - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my\n\u003e code :-(\n\u003e \n\u003e --joe\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\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/fd516c4a/attachment.sig\u003e",
"sig": "41d43d3ce40649880cc70fca7b844a009697ee734826e9bc2a12ae890321d626cea9233b0ac0f7dfbfa3b142a12f3b6b51c5ef9973199ae5f32090d066d3cc4e"
}