BIP 300/301: Link to latest code – also shorter/better explanations #1666

pull psztorc wants to merge 17 commits into bitcoin:master from psztorc:patch-2 changing 6 files +112 −175
  1. psztorc commented at 9:44 pm on September 22, 2024: contributor

    I’ve developed a much cleaner/safer/better way of doing BIP-300/301, and updated the BIP accordingly.

    While doing that, I have updated the BIP text to (hopefully) clarify a number of points/questions that were raised over the last 12 months.

  2. Update to CUSF activation client +shorter +clearer 33a3031fd5
  3. remove superfluous images 8477d1918d
  4. link to CUSF client, shorter and clearer BIP text f856ebe890
  5. typo 881c6de925
  6. in bip-0300.mediawiki:20 in 881c6de925 outdated
    14@@ -15,31 +15,28 @@
    15 
    16 ==Abstract==
    17 
    18-In Bip300, txns are not signed via cryptographic key. Instead, they are "signed" by hashpower, over time. Like a big multisig, 13150-of-26300, where each block is a new "signature".
    19+BIP-300 enables a new type of L2, where "withdrawals" (the L2-to-L1 txns) are governed by proof-of-work -- (instead of a federation or fixed set of pubkeys).
    20 
    21-Bip300 emphasizes slow, transparent, auditable transactions which are easy for honest users to get right and very hard for dishonest users to abuse. The chief design goal for Bip300 is ''partitioning'' -- users may safely ignore Bip300 txns if they want to (or Bip300 entirely).
    22+BIP-300 emphasizes slow, transparent, and auditable withdrawals -- easy for honest users to get right and hard for dishonest miners to abuse. The main design goal for BIP-300 is ''partitioning'' -- users can ignore BIP-300 txns if they wish, it makes no difference to L1 if the user validates all, some, or none of them. The second design goal is ''security'' -- users of the L2 should feel confident that, [https://www.drivechain.info/blog/fees/ if the L2 network is paying a lot of fees], then miners will want to keep it around, and the withdrawals will therefore be processed accurately.
    


    jonatack commented at 5:12 pm on September 23, 2024:
    0BIP-300 emphasizes slow, transparent, and auditable withdrawals that are easy for honest users to get right and hard for dishonest miners to abuse. The main design goal for BIP-300 is ''partitioning'' -- users can ignore BIP-300 txns if they wish; it makes no difference to L1 if the user validates all, some, or none of them. The second design goal is ''security'' -- users of the L2 should feel confident that, [https://www.drivechain.info/blog/fees/ if the L2 network is paying a lot of fees], then miners will want to keep it around, and the withdrawals will therefore be processed accurately.
    

    psztorc commented at 6:33 pm on September 23, 2024:
    I like it
  7. in bip-0300.mediawiki:18 in 881c6de925 outdated
    14@@ -15,31 +15,28 @@
    15 
    16 ==Abstract==
    17 
    18-In Bip300, txns are not signed via cryptographic key. Instead, they are "signed" by hashpower, over time. Like a big multisig, 13150-of-26300, where each block is a new "signature".
    19+BIP-300 enables a new type of L2, where "withdrawals" (the L2-to-L1 txns) are governed by proof-of-work -- (instead of a federation or fixed set of pubkeys).
    


    jonatack commented at 5:16 pm on September 23, 2024:

    Suggest either the long dash or the parentheses, but not both. Or a comma-space.

    0BIP-300 enables a new type of L2, where "withdrawals" (the L2-to-L1 txns) are governed by proof-of-work -- instead of a federation or fixed set of pubkeys.
    
  8. in bip-0300.mediawiki:27 in 881c6de925 outdated
    25+Once BIP-300 has established a "bridge" between L1 and these L2s, users can swap coins in and out instantly, only using BIP-300 for final settlement. This setup allows Bitcoin to process all the transactions in the world, of any shape or size, regardless of blocksize, node software, tech stack, or decentralization level -- all without altering L1 at all.
    26 
    27 
    28 ==Motivation==
    29 
    30+BIP-300 allows us to achieve [https://www.truthcoin.info/blog/zside-meltcast/ strong privacy], [https://www.truthcoin.info/blog/thunder/ planetary scale], and [https://www.truthcoin.info/blog/all-world-txns/ hundreds of billions of dollars in annual mining revenues], all a [https://www.drivechain.info/blog/fees/ security model] that is [https://x.com/Truthcoin/status/1701959339508965405 much stronger than] that of the [https://www.truthcoin.info/blog/ln-blackpill/ doomed Lightning Network].
    


    jonatack commented at 5:19 pm on September 23, 2024:

    missing “with”?

    Is it really necessary to describe the LN as “doomed” here.

    0BIP-300 allows us to achieve [https://www.truthcoin.info/blog/zside-meltcast/ strong privacy], [https://www.truthcoin.info/blog/thunder/ planetary scale], and [https://www.truthcoin.info/blog/all-world-txns/ hundreds of billions of dollars in annual mining revenues], all with a [https://www.drivechain.info/blog/fees/ security model] that is [https://x.com/Truthcoin/status/1701959339508965405 much stronger than] that of the [https://www.truthcoin.info/blog/ln-blackpill/ Lightning Network].
    

    psztorc commented at 6:37 pm on September 23, 2024:
    No, it is not “necessary”. But it truthfully is a motivation. And it is not necessary to simp for / cover for the LN either.

    psztorc commented at 6:37 pm on September 23, 2024:
    But whatever
  9. in bip-0300.mediawiki:93 in 881c6de925 outdated
    90 |- style="vertical-align:middle;"
    91 | 6
    92 | Hash2 - git commit hash
    93 | uint160
    94-| Intended as the git commit hash of the canonical sidechain node software. (This is not enforced anywhere by Bip300, and is for human purposes only.)
    95+| Intended as the git commit hash of the canonical sidechain node software. (This is not enforced anywhere by BIP-300, and is for human purposes only.)
    


    jonatack commented at 5:21 pm on September 23, 2024:
    nit here and line 88 above, both instances of “anywhere” seem superfluous
  10. in bip-0300.mediawiki:213 in 881c6de925 outdated
    208@@ -219,40 +209,26 @@ Otherwise:
    209 
    210 A sidechain fails to activate if:
    211 
    212-* If the slot is unused: during the next 2016 blocks, it accumulates 201 fails. (Ie, 90% threshold).
    213-* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails. (Ie, 50% threshold).
    214+* If the slot is unused: during the next 2016 blocks, it accumulates 1008 fails. (Ie, 50% hashrate threshold).
    215+* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails. (Ie, 50% hashrate threshold).
    


    jonatack commented at 5:37 pm on September 23, 2024:
    nit here and throughout, s/ie,/i.e.,/

    psztorc commented at 6:44 pm on September 23, 2024:
    will fix
  11. in bip-0300.mediawiki:215 in 881c6de925 outdated
    213-* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails. (Ie, 50% threshold).
    214+* If the slot is unused: during the next 2016 blocks, it accumulates 1008 fails. (Ie, 50% hashrate threshold).
    215+* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails. (Ie, 50% hashrate threshold).
    216 
    217-( Thus we can overwrite a used sidechain slot. Bip300 sidechains are already vulnerable to one catastrophe per 13150 blocks (the invalid withdrawal) so this slot-overwrite option does not change the security assumptions. )
    218+( Thus we can overwrite a used sidechain slot. BIP-300 sidechains are already vulnerable to one catastrophe per 13150 blocks (the invalid withdrawal) so this slot-overwrite option does not change the security assumptions. )
    


    jonatack commented at 5:42 pm on September 23, 2024:
    0(Thus we can overwrite a used sidechain slot. BIP-300 sidechains are already vulnerable to one catastrophe per 13150 blocks (the invalid withdrawal), so this slot-overwrite option does not change the security assumptions.)
    
  12. in bip-0300.mediawiki:224 in 881c6de925 outdated
    235 Sidechain withdrawals take the form of "Bundles" -- named because they "bundle up" many individual withdrawal-requests into a single rare layer1 transaction.
    236 
    237-Sidechain full nodes aggregate the withdrawal-requests into a big set. The sidechain calculates what M6 would have to look like, to pay all of these withdrawal-requests out. Finally, the sidechain calculates what the hash of this M6 would be. This 32-byte hash identifies the Bundle.
    238-
    239-This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course).
    240+On the L2 side, individual withdrawal requests are periodically combined into a single CoinJoin-like withdrawal bundle. This bundle is hashed [https://github.com/LayerTwo-Labs/bip300301_messages/blob/master/src/lib.rs#L374C1-L419C2 in a particular way] (on both L2 and L1) -- this "blinded hash" commits to its own L1 fee, but (notably) it does not commit to its first tx-input (in that way, it is like AnyPrevOut, BIP-118).
    


    jonatack commented at 5:44 pm on September 23, 2024:
    0On the L2 side, individual withdrawal requests are periodically combined into a single CoinJoin-like withdrawal bundle. This bundle is hashed [https://github.com/LayerTwo-Labs/bip300301_messages/blob/master/src/lib.rs#L374C1-L419C2 in a particular way] (on both L2 and L1) -- this "blinded hash" commits to its own L1 fee, but (notably) it does not commit to its first tx-input (in that way, it is like SIGHASH_ANYPREVOUT, BIP-118).
    

    Suggest linking to BIP118 (and perhaps drop the naming of it, so that if its name changes, then no need to update here).


    psztorc commented at 6:46 pm on September 23, 2024:
    will do
  13. in bip-0300.mediawiki:228 in 881c6de925 outdated
    241 
    242-A bundle either pays all its withdrawals out (via M6), or else it fails (and pays nothing out).
    243+This hash is what L1 miners will slowly ACK over 3-6 months, not the M6 itself (nor any sidechain data, of course).
    244 
    245-===== Bundle Hash = Blinded TxID of M6 =====
    246+A bundle will either: pay all its withdrawals out (via M6), or else it fails (and pays nothing out for anyone).
    


    jonatack commented at 5:49 pm on September 23, 2024:
    0A bundle will either pay all its withdrawals out (via M6), or fail (and pay nothing out for anyone).
    
  14. in bip-0300.mediawiki:119 in 881c6de925 outdated
    115@@ -118,11 +116,11 @@ D1 is a list of active sidechains. D1 is updated via M1 and M2.
    116 
    117 ==== D2 (The Withdrawal List) ====
    118 
    119-D2 lists withdrawal-attempts. If these attempts succeed, they will pay coins "from" a Bip300-locked UTXO, to new UTXOs controlled by the withdrawing-user. Each attempt pays out many users, so we call these withdrawal-attempts "Bundles".
    120+Withdrawals are transactions that remove coins "from" L2 (ie, from the BIP-300 locked UTXO), and place them back on L1. Each BIP-300 withdrawal can pay out up to 6,000 withdrawals, and only one withdrawal can succeed at a time (per L2). Therefore, since all L2 users share the same large withdrawal-event, on L1 we call these withdrawals "bundles".
    


    jonatack commented at 5:52 pm on September 23, 2024:

    As you are defining the term “Bundle” here, perhaps mention it in the section title.

    It looks like you are writing bundles (and other terms) as proper nouns (“Bundle”) in much of the rest of the document – though not consistently. Consider perhaps aligning them.


    psztorc commented at 6:49 pm on September 23, 2024:
    will make them all lowercase
  15. in bip-0300.mediawiki:359 in 881c6de925 outdated
    355+
    356+==== Saving Space ====
    357+
    358+The version number allows us to shrink the upvote vector in many cases.
    359+Version 0x00 omits the upvote vector entirely (ie, 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4.
    360+Version 0x01 uses one byte per sidechain, and can be used while all ACKed withdrawals have an index under 256 (ie, 99.99%+ of the time).
    


    jonatack commented at 5:59 pm on September 23, 2024:

    maybe clearer not to write out some numbers but not others

    “under” is similar to “number”

    0Version 0x01 uses 1 byte per sidechain, and can be used while all ACKed withdrawals have an index less than 256 (ie, 99.99%+ of the time).
    
  16. in bip-0300.mediawiki:360 in 881c6de925 outdated
    356+==== Saving Space ====
    357+
    358+The version number allows us to shrink the upvote vector in many cases.
    359+Version 0x00 omits the upvote vector entirely (ie, 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4.
    360+Version 0x01 uses one byte per sidechain, and can be used while all ACKed withdrawals have an index under 256 (ie, 99.99%+ of the time).
    361+Version 0x02 uses a full two bytes per sidechain (each encoded in little endian), but it always works no matter how many withdrawal proposals exist.
    


    jonatack commented at 6:01 pm on September 23, 2024:
    0Version 0x02 uses a full 2 bytes per sidechain (each encoded in little endian), but it always works no matter how many withdrawal proposals exist.
    

    psztorc commented at 6:53 pm on September 23, 2024:
    will change this
  17. in bip-0301.mediawiki:35 in 881c6de925 outdated
    31@@ -32,9 +32,9 @@ However, traditional MM has two drawbacks:
    32 
    33 ==Notation and Example==
    34 
    35-Note: We use notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to sort the mainchain version from its sidechain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
    36+We use notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to sort the mainchain version from its sidechain/alt-chain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
    


    jonatack commented at 6:06 pm on September 23, 2024:
    0We use notation side:\* and main:\* in front of otherwise ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain/alt-chain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
    

    psztorc commented at 6:53 pm on September 23, 2024:
    Ok
  18. in bip-0301.mediawiki:37 in 881c6de925 outdated
    31@@ -32,9 +32,9 @@ However, traditional MM has two drawbacks:
    32 
    33 ==Notation and Example==
    34 
    35-Note: We use notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to sort the mainchain version from its sidechain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
    36+We use notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to sort the mainchain version from its sidechain/alt-chain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
    37 
    38-Example: imagine that a sidechain block contains 20,000 txns, each paying a $0.10 fee; therefore, the block is worth $2000 of fee-revenue. As usual: the sidechain's coinbase txn will pay this $2000 to someone (in this case, "Simon"). Under Bip301, Simon does no hashing, but instead makes one layer1 txn paying $1999 to the layer1 miners ("Mary").
    39+Furthermore, here is an example of BIP-301 in use. Imagine that a side:block contains 20,000 txns, each paying a $0.10 fee; therefore, the side:block is worth $2000 of fee-revenue. In BIP-301 sidechain's coinbase txn will pay this $2000 to "Simon". Simon does no hashing, but instead makes one layer1 txn paying $1999 to the layer1 miners ("Mary"). Thus, Mary ends up with all of the fee-revenue, even though she didn't do anything on the sidechain.
    


    jonatack commented at 6:07 pm on September 23, 2024:
    0Furthermore, here is an example of BIP-301 in use. Imagine that a side:block contains 20,000 txns, each paying a $0.10 fee; therefore, the side:block is worth $2000 of fee revenue. In BIP-301, the sidechain's coinbase transaction will pay this $2000 to "Simon". Simon does no hashing, but instead makes one L1 transaction paying $1999 to the L1 miners ("Mary"). Thus, Mary ends up with all of the fee revenue, even though she didn't do anything on the sidechain.
    

    psztorc commented at 6:56 pm on September 23, 2024:
    I think I will keep “txn” here, since next to the term “coinbase” it will not confuse anyone and is shorter. But I will take the rest of the suggestions.
  19. in bip-0301.mediawiki:82 in 881c6de925 outdated
    79 ==Specification==
    80 
    81+Each candidate for next side:block is defined by its unique side:blockhash "h*". (Even if the entire rest of the L2 block is identical, different Simons will have different side:coinbases and therefore different h*.)
    82 
    83-Bip301 consists of two messages: "BMM Accept" and "BMM Request". These govern something called "h*".
    84+Bip301 consists of two messages: "BMM Accept" and "BMM Request".
    


    jonatack commented at 6:08 pm on September 23, 2024:
    0BIP-301 consists of two messages: "BMM Accept" and "BMM Request".
    

    psztorc commented at 6:57 pm on September 23, 2024:
    I missed this one!
  20. in bip-0301.mediawiki:128 in 881c6de925 outdated
    161 This txn is invalid if it fails any of the following checks:
    162 
    163 # Each "BMM Request", must match one corresponding "BMM Accept" (previous section).
    164-# Only one BMM Request is allowed in each main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner singles out one BMM Request to include.
    165-# The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about).
    166+# Only one BMM Request is allowed in each main:block, per nSidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must singles out one BMM_Request_4 to include in this L1 block.
    


    jonatack commented at 6:09 pm on September 23, 2024:
    0# Only one BMM Request is allowed in each main:block, per nSidechain. In other words, if 700 users broadcast BMM Requests for sidechain [#4](/bitcoin-bips/4/), then the main:miner must single out one BMM_Request_4 to include in this L1 block.
    

    psztorc commented at 6:58 pm on September 23, 2024:
    Right
  21. in bip-0301.mediawiki:129 in 881c6de925 outdated
    162 
    163 # Each "BMM Request", must match one corresponding "BMM Accept" (previous section).
    164-# Only one BMM Request is allowed in each main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner singles out one BMM Request to include.
    165-# The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about).
    166+# Only one BMM Request is allowed in each main:block, per nSidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must singles out one BMM_Request_4 to include in this L1 block.
    167+# The 32-bytes of prevMainBlock must match the previous main:blockhash. Thus, Simon's txns are only valid for the current block, in the block history that he knows about.
    


    jonatack commented at 6:10 pm on September 23, 2024:
    0# The 32 bytes of prevMainBlock must match the previous main:blockhash. Thus, Simon's transactions are only valid for the current block, in the block history that he knows about.
    

    psztorc commented at 6:59 pm on September 23, 2024:
    I think I will not change this one, since the idea is that the reader would pattern-match to the “32-bytes” in the box above.
  22. in bip-0301.mediawiki:132 in 881c6de925 outdated
    166+# Only one BMM Request is allowed in each main:block, per nSidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must singles out one BMM_Request_4 to include in this L1 block.
    167+# The 32-bytes of prevMainBlock must match the previous main:blockhash. Thus, Simon's txns are only valid for the current block, in the block history that he knows about.
    168 
    169 
    170-Most BMM Request txns will never make it into a block. Simon will make many BMM Requests, but only one will be accepted. Since only one BMM Request can become a bona fide transaction, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from, and can choose the one which pays her the most.
    171+Most BMM Request txns will never make it into a block. Simon will make many BMM Requests, but only one will be accepted. Since only one BMM Request can enter the L1 block, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from, and can choose the one which pays her the most.
    


    jonatack commented at 6:11 pm on September 23, 2024:
    0Most BMM Request txns will never make it into a block. Simon will make many BMM Requests, but only one will be accepted. Since only one BMM Request can enter the L1 block, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from and can choose the one that pays her the most.
    

    psztorc commented at 7:01 pm on September 23, 2024:
    Ok
  23. jonatack commented at 6:13 pm on September 23, 2024: member

    The changes appear globally good. Didn’t do a technical review but rather a first editor pass.

    In general, it may be nice to write “transaction” in lieu of “txn”, and possibly define the L1 and L2 abbreviations near the top of each BIP to clarify if they refer to their usual meaning or a different one in this context.

  24. no dash
    Co-authored-by: Jon Atack <jon@atack.com>
    598baf2772
  25. remove ( )
    Co-authored-by: Jon Atack <jon@atack.com>
    f8138bd106
  26. Update bip-0300.mediawiki
    Co-authored-by: Jon Atack <jon@atack.com>
    507a5dd18a
  27. other typos and requested edits 2fc2cd85b3
  28. other typos f0293d97e5
  29. psztorc commented at 7:08 pm on September 23, 2024: contributor
    Thanks, I added all of those changes, except for one (the “32-bytes” one) , and the “one byte” –> “1 byte” area I accepted the change and then changed it slightly more.
  30. jonatack added the label Proposed BIP modification on Sep 23, 2024
  31. in bip-0300.mediawiki:125 in f0293d97e5 outdated
    123 
    124-# The Bundles have a canonical order (first come first serve).
    125+# The database has a canonical order (first come first serve).
    126 # From one block to the next, every "Blocks Remaining" field decreases by 1.
    127-# When "Blocks Remaining" reaches zero the Bundle is removed.
    128+# When "Blocks Remaining" reaches zero the bundle is removed.
    


    jonatack commented at 8:21 pm on September 23, 2024:

    like the other steps in this list

    0# When "Blocks Remaining" reaches zero, the bundle is removed.
    
  32. in bip-0301.mediawiki:37 in f0293d97e5 outdated
    31@@ -32,9 +32,9 @@ However, traditional MM has two drawbacks:
    32 
    33 ==Notation and Example==
    34 
    35-Note: We use notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to sort the mainchain version from its sidechain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
    36+We use notation side:\* and main:\* in front of otherwise ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain/alt-chain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
    37 
    38-Example: imagine that a sidechain block contains 20,000 txns, each paying a $0.10 fee; therefore, the block is worth $2000 of fee-revenue. As usual: the sidechain's coinbase txn will pay this $2000 to someone (in this case, "Simon"). Under Bip301, Simon does no hashing, but instead makes one layer1 txn paying $1999 to the layer1 miners ("Mary").
    39+Furthermore, here is an example of BIP-301 in use. Imagine that a side:block contains 20,000 txns, each paying a $0.10 fee; therefore, the side:block is worth $2000 of fee revenue. In BIP-301, the sidechain's coinbase txn will pay this $2000 to "Simon". Simon does no hashing, but instead makes one L1 txn paying $1999 to the L1 miners ("Mary"). Thus, Mary ends up with all of the fee-revenue, even though she didn't do anything on the sidechain.
    


    jonatack commented at 8:21 pm on September 23, 2024:
    0Furthermore, here is an example of BIP-301 in use. Imagine that a side:block contains 20,000 txns, each paying a $0.10 fee; therefore, the side:block is worth $2000 of fee revenue. In BIP-301, the sidechain's coinbase txn will pay this $2000 to "Simon". Simon does no hashing, but instead makes one L1 txn paying $1999 to the L1 miners ("Mary"). Thus, Mary ends up with all of the fee revenue, even though she didn't do anything on the sidechain.
    
  33. in bip-0300.mediawiki:222 in f0293d97e5 outdated
    235 
    236-Sidechain full nodes aggregate the withdrawal-requests into a big set. The sidechain calculates what M6 would have to look like, to pay all of these withdrawal-requests out. Finally, the sidechain calculates what the hash of this M6 would be. This 32-byte hash identifies the Bundle.
    237+=== Withdrawing in Bundles ===
    238 
    239-This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course).
    240+Sidechain withdrawals take the form of "bundles" -- named because they "bundle up" many individual withdrawal-requests into a single rare layer1 transaction.
    


    jonatack commented at 8:23 pm on September 23, 2024:

    maybe for consistency

    0Sidechain withdrawals take the form of "bundles" -- named because they "bundle up" many individual withdrawal-requests into a single rare L1 transaction.
    
  34. in bip-0300.mediawiki:224 in f0293d97e5 outdated
    238 
    239-This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course).
    240+Sidechain withdrawals take the form of "bundles" -- named because they "bundle up" many individual withdrawal-requests into a single rare layer1 transaction.
    241 
    242-A bundle either pays all its withdrawals out (via M6), or else it fails (and pays nothing out).
    243+On the L2 side, individual withdrawal requests are periodically combined into a single CoinJoin-like withdrawal bundle. This bundle is hashed [https://github.com/LayerTwo-Labs/bip300301_messages/blob/master/src/lib.rs#L374C1-L419C2 in a particular way] (on both L2 and L1) -- this "blinded hash" commits to its own L1 fee, but (notably) it does not commit to its first tx-input (in that way, it is like [https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_ANYPREVOUT]).
    


    jonatack commented at 8:24 pm on September 23, 2024:

    (maybe use a name that won’t potentially change, feel free to ignore)

    0On the L2 side, individual withdrawal requests are periodically combined into a single CoinJoin-like withdrawal bundle. This bundle is hashed [https://github.com/LayerTwo-Labs/bip300301_messages/blob/master/src/lib.rs#L374C1-L419C2 in a particular way] (on both L2 and L1) -- this "blinded hash" commits to its own L1 fee, but (notably) it does not commit to its first tx-input (in that way, it is like [https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki BIP-118]).
    
  35. in bip-0301.mediawiki:18 in f0293d97e5 outdated
    14@@ -15,9 +15,9 @@
    15 
    16 ==Abstract==
    17 
    18-Blind Merged Mining (BMM) allows miners to mine a Sidechain/Altcoin, without running its node software (ie, without "looking" at it, hence "blind").
    19+Blind Merged Mining (BMM) allows SHA-256d miners to collect transaction fee revenue from other blockchains, without running any new software (ie, without "looking" at those alt-chains, hence "blind").
    


    jonatack commented at 8:28 pm on September 23, 2024:
    0Blind Merged Mining (BMM) allows SHA-256d miners to collect transaction fee revenue from other blockchains, without running any new software (i.e., without "looking" at those alt-chains, hence "blind").
    
  36. in bip-0301.mediawiki:20 in f0293d97e5 outdated
    14@@ -15,9 +15,9 @@
    15 
    16 ==Abstract==
    17 
    18-Blind Merged Mining (BMM) allows miners to mine a Sidechain/Altcoin, without running its node software (ie, without "looking" at it, hence "blind").
    19+Blind Merged Mining (BMM) allows SHA-256d miners to collect transaction fee revenue from other blockchains, without running any new software (ie, without "looking" at those alt-chains, hence "blind").
    20 
    21-Instead, a separate sidechain user runs their node and constructs the block, paying himself the transaction fees. He then uses an equivalent amount of money to "buy" the right to find this block, from the conventional layer1 Sha256d miners.
    22+Instead, this block-assembly work is done by alt-chain users. They choose the alt-chain block, and what txns go in it, the fees etc. Simultaneously, these users "bid" on L1, to win the right to be the sole creator of the alt-chain block. BIP-301 ensures that L1 miners only accept one bid (per 10 minutes, per L2 category), instead of taking all of them (which is what they would ordinarily do).
    


    jonatack commented at 8:29 pm on September 23, 2024:
    0Instead, this block-assembly work is done by alt-chain users. They choose the alt-chain block, and what txns go in it, the fees etc. Simultaneously, these users "bid" on L1 to win the right to be the sole creator of the alt-chain block. BIP-301 ensures that L1 miners only accept one bid (per 10 minutes, per L2 category), instead of taking all of them (which is what they would ordinarily do).
    
  37. in bip-0300.mediawiki:213 in f0293d97e5 outdated
    208@@ -219,46 +209,32 @@ Otherwise:
    209 
    210 A sidechain fails to activate if:
    211 
    212-* If the slot is unused: during the next 2016 blocks, it accumulates 201 fails. (Ie, 90% threshold).
    213-* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails. (Ie, 50% threshold).
    214+* If the slot is unused: during the next 2016 blocks, it accumulates 1008 fails. (i.e., 50% hashrate threshold).
    215+* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails. (i.e., 50% hashrate threshold).
    


    jonatack commented at 8:32 pm on September 23, 2024:
    0* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails (i.e., 50% hashrate threshold).
    
  38. in bip-0300.mediawiki:212 in f0293d97e5 outdated
    208@@ -219,46 +209,32 @@ Otherwise:
    209 
    210 A sidechain fails to activate if:
    211 
    212-* If the slot is unused: during the next 2016 blocks, it accumulates 201 fails. (Ie, 90% threshold).
    213-* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails. (Ie, 50% threshold).
    214+* If the slot is unused: during the next 2016 blocks, it accumulates 1008 fails. (i.e., 50% hashrate threshold).
    


    jonatack commented at 8:32 pm on September 23, 2024:
    0* If the slot is unused: during the next 2016 blocks, it accumulates 1008 fails (i.e., 50% hashrate threshold).
    
  39. jonatack commented at 8:34 pm on September 23, 2024: member
    Thanks for updating. As you’re draft author, let me know if you’d like to have this merged as-is or update to take any of the new suggestions.
  40. comma
    Co-authored-by: Jon Atack <jon@atack.com>
    90b67cb81e
  41. no dash
    Co-authored-by: Jon Atack <jon@atack.com>
    f886644bb5
  42. "L1"
    Co-authored-by: Jon Atack <jon@atack.com>
    5dc2d5942a
  43. avoid APO name
    Co-authored-by: Jon Atack <jon@atack.com>
    8955ce51db
  44. "i.e."
    Co-authored-by: Jon Atack <jon@atack.com>
    88087487f7
  45. ","
    Co-authored-by: Jon Atack <jon@atack.com>
    0f7557ef56
  46. "."
    Co-authored-by: Jon Atack <jon@atack.com>
    ad984edcae
  47. "."
    Co-authored-by: Jon Atack <jon@atack.com>
    7526317f04
  48. psztorc commented at 10:51 pm on September 23, 2024: contributor

    Ok those were also good changes

    let me know if you’d like to have this merged as-is

    I think merge it, whenever is convenient for you

  49. jonatack commented at 11:00 pm on September 23, 2024: member
    ACK, thanks.
  50. jonatack merged this on Sep 23, 2024
  51. jonatack closed this on Sep 23, 2024

  52. jonatack renamed this:
    Link to latest code -- also shorter/better explanations
    BIP 300/301: Link to latest code -- also shorter/better explanations
    on Sep 23, 2024

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-08 18:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me