BIP 300: Various improvements #1485

pull luke-jr wants to merge 7 commits into bitcoin:master from luke-jr:bip300_adj20230726 changing 1 files +66 −6
  1. luke-jr commented at 5:42 pm on August 16, 2023: member
  2. bip-0300: Add OP_DRIVECHAIN 2cccaf650f
  3. bip-0300: Fix upvote vector example 69d872461b
  4. bip-0300: Reorder upvote vector version numbers to leave 1/2 bytes as version 1,2 respectively 9d4ec80215
  5. bip-0300: Define endianness of upvote vector accaee0f33
  6. bip-0300: Forbid extraneous OP_DRIVECHAIN outputs in M5/M6 badaf01360
  7. bip-0300: Ensure tx fee commitment itself has zero value so sidechain coins can't get burned 796c80eb9d
  8. bip-0300: Add some guesstimate weight adjustments c2f4825550
  9. luke-jr added the label Proposed BIP modification on Aug 16, 2023
  10. in bip-0300.mediawiki:291 in c2f4825550
    286@@ -287,11 +287,15 @@ The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm"
    287 
    288 For example: if there are two sidechains, and we wish to upvote the 7th bundle on sidechain #1 plus the 4th bundle on sidechain #2, then the upvote vector would be { 07, 04 }. And M4 would be [0x6A,D77D1776,00,0006,0003].
    289 
    290-The version number allows us to shrink the upvote vector in many cases. Version 0x00 requires a full two bytes per sidechain, but it always works. Version 0x01 uses half that (one byte per sidechain), and it works while all sidechains have fewer than 255 disputed withdrawals (ie, 99.99%+ of the time). Version 0x02 uses zero bytes (ie, 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4. Version 0x03 upvotes only those withdrawals that are leading their rivals by at least 50 votes.
    291+The version number allows us to shrink the upvote vector in many cases.
    292+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.
    


    staffserg commented at 11:19 am on August 17, 2023:
    Awesome
  11. staffserg approved
  12. staffserg commented at 11:20 am on August 17, 2023: none
    Awesome
  13. psztorc commented at 5:24 pm on August 17, 2023: contributor
    These changes are good
  14. luke-jr merged this on Aug 18, 2023
  15. luke-jr closed this on Aug 18, 2023

  16. ChrisMartl commented at 4:07 pm on September 11, 2023: none

    @psztorc

    Can you please provide a statement how this proposal will affect the Nash equilibrium between the distribution of affordable archival full nodes and affordable mining devices?

    Can you please provide a statement how the concern, that equilibrium is reached by highly capitalized and centralized original node (storage + mining) entities will be mitigated?

  17. bitcoin deleted a comment on Sep 11, 2023
  18. bitcoin deleted a comment on Sep 11, 2023
  19. psztorc commented at 5:01 pm on September 11, 2023: contributor

    @psztorc

    Can you please provide a statement how this proposal will affect the Nash equilibrium between the distribution of affordable archival full nodes and affordable mining devices?

    Long term, this proposal makes it easier to run a full node, since it allows us to shrink the L1 blocksize. It also makes it easier to mine, since a higher percentage of revenue comes from low-fixed-cost activities.

    Can you please provide a statement how the concern, that equilibrium is reached by highly capitalized and centralized original node (storage + mining) entities will be mitigated?

    Node costs will never be significant (in comparison to ASIC costs or physical security) – for any sidechain, there is a group of people running nodes for free (else the network dies).

    If they end up being significant anyway, then miners will utilize blind merged mining (or a custodial version of it) to shirk the cost. If the cost is persistently high anyway, then the L2 network will die off. L1 is unaffected.

  20. ChrisMartl commented at 7:18 pm on September 11, 2023: none

    @psztorc

    Can you please provide empirical observations from other experimental projects like e.g. Ethereum Classic or Ethereum PoW, where this concept (BIP300) (or equivalent for those projects) has being applied and its short, medium and long term effects on that system as a whole in regards of the concerns being addressed above?

  21. stvnreaves cross-referenced this on Nov 30, 2023 from issue Awesome by stvnreaves

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-12-21 18:10 UTC

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