From 2cccaf650fc3f8bfbd0c8429ee52245cb2db311f Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 26 Jul 2023 19:45:51 +0000 Subject: [PATCH 1/7] bip-0300: Add OP_DRIVECHAIN --- bip-0300.mediawiki | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki index 6ee07600..20c55846 100644 --- a/bip-0300.mediawiki +++ b/bip-0300.mediawiki @@ -226,7 +226,7 @@ A sidechain fails to activate if: Otherwise, the sidechain activates (Active is set to TRUE). -In the block in which the sidechain activates, the coinbase MUST include at least one 0-valued OP_TRUE. This output becomes the initial CTIP for the sidechain. +In the block in which the sidechain activates, the coinbase MUST include at least one 0-valued OP_DRIVECHAIN output. This output becomes the initial CTIP for the sidechain. @@ -394,7 +394,7 @@ Every time a deposit/withdrawal is made, the old CTIP is spent and a new one is Every M5 is valid, as long as: -* It has at least one OP_TRUE output -- this becomes the new CTIP. +* It has at least one OP_DRIVECHAIN output -- this becomes the new CTIP. * The new CTIP has '''more''' coins in it, than before. @@ -405,7 +405,7 @@ We come, finally, to the critical matter: where users can take their money *out* M6 is invalid if: * The blinded hash of M6 does NOT match one of the approved Bundle-hashes. (In other words: M6 must first be approved by 13,150 upvotes.) -* The first output of M6 is NOT an OP_TRUE. (This OP_TRUE becomes the new CTIP. In other words: all non-withdrawn coins are paid back to the sidechain.) +* The first output of M6 is NOT an OP_DRIVECHAIN. (This OP_DRIVECHAIN becomes the new CTIP. In other words: all non-withdrawn coins are paid back to the sidechain.) * The second output is NOT an OP_RETURN script of exactly 10 bytes, of which 8 bytes are a serialized Bitcoin amount. * The txn fee of M6 is NOT exactly equal to the amount of the previous bullet point. @@ -413,8 +413,16 @@ Else, M6 is valid. (The point of the latter two bullet points, is to allow the bundle hash to cover the L1 transaction fee.) +===OP_DRIVECHAIN=== +This proposal adds a single new opcode, OP_DRIVECHAIN, which has strict semantics for usage. +OP_NOP5 (0xb4) is redefined as OP_DRIVECHAIN if and only if the entire script is OP_DRIVECHAIN followed by a single-byte push and OP_TRUE (exactly 4 bytes). +The single-byte push contains the sidechain number. +Note that this is not a "script number", and cannot be OP_1..OP_16 or any other kind of push; it is also unsigned, and must not be padded even if over sidechain number 127. +The final OP_TRUE is to ensure this change remains a softfork: +without it, sidechain numbers 0 and 128 would cause the legacy script interpreter to fail. +If an OP_DRIVECHAIN input is spent, the additional rules for M5 or M6 (see above) must be enforced. ==Backward compatibility== From 69d872461b239059d134c195347267289e19535d Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 26 Jul 2023 19:53:36 +0000 Subject: [PATCH 2/7] bip-0300: Fix upvote vector example --- bip-0300.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki index 20c55846..5a09935f 100644 --- a/bip-0300.mediawiki +++ b/bip-0300.mediawiki @@ -291,7 +291,7 @@ The version number allows us to shrink the upvote vector in many cases. Version If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed. -For example, an upvote vector of { 2 , N/A, 1 } would be represented as [0x6A,D77D1776,01,00,00]. It means: "upvote the first bundle in sidechain #1; and the first bundle in sidechain #3" (iff sidechains #2 has no bundles proposed). +For example, an upvote vector of { 2 , N/A, 1 } would be represented as [0x6A,D77D1776,01,01,00]. It means: "upvote the second bundle in sidechain #1; and the first bundle in sidechain #3" (iff sidechains #2 has no bundles proposed). An upvote vector of { N/A, N/A, 4 } would be [0x6A,D77D1776,01,03]. From 9d4ec80215727779142862d023c5d253ed3a997b Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 26 Jul 2023 19:54:18 +0000 Subject: [PATCH 3/7] bip-0300: Reorder upvote vector version numbers to leave 1/2 bytes as version 1,2 respectively --- bip-0300.mediawiki | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki index 5a09935f..0f2ef6e9 100644 --- a/bip-0300.mediawiki +++ b/bip-0300.mediawiki @@ -287,7 +287,11 @@ The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm" 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]. -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. +The version number allows us to shrink the upvote vector in many cases. +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. +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). +Version 0x02 uses a full two bytes per sidechain, but it always works no matter how many withdrawl proposals exist. +Version 0x03 omits the upvote vector, and instead upvotes only those withdrawals that are leading their rivals by at least 50 votes. If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed. From accaee0f33c9f8cb80dd74f8c024f01fd4c02de5 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 26 Jul 2023 19:59:11 +0000 Subject: [PATCH 4/7] bip-0300: Define endianness of upvote vector --- bip-0300.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki index 0f2ef6e9..a2653745 100644 --- a/bip-0300.mediawiki +++ b/bip-0300.mediawiki @@ -290,7 +290,7 @@ For example: if there are two sidechains, and we wish to upvote the 7th bundle o The version number allows us to shrink the upvote vector in many cases. 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. 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). -Version 0x02 uses a full two bytes per sidechain, but it always works no matter how many withdrawl proposals exist. +Version 0x02 uses a full two bytes per sidechain (each encoded in little endian), but it always works no matter how many withdrawl proposals exist. Version 0x03 omits the upvote vector, and instead upvotes only those withdrawals that are leading their rivals by at least 50 votes. If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed. From badaf01360374ed9c95ed70042761d5bca99af20 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 26 Jul 2023 19:59:59 +0000 Subject: [PATCH 5/7] bip-0300: Forbid extraneous OP_DRIVECHAIN outputs in M5/M6 --- bip-0300.mediawiki | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki index a2653745..6f8a13c2 100644 --- a/bip-0300.mediawiki +++ b/bip-0300.mediawiki @@ -398,7 +398,7 @@ Every time a deposit/withdrawal is made, the old CTIP is spent and a new one is Every M5 is valid, as long as: -* It has at least one OP_DRIVECHAIN output -- this becomes the new CTIP. +* It has exactly one OP_DRIVECHAIN output -- this becomes the new CTIP. * The new CTIP has '''more''' coins in it, than before. @@ -412,6 +412,7 @@ M6 is invalid if: * The first output of M6 is NOT an OP_DRIVECHAIN. (This OP_DRIVECHAIN becomes the new CTIP. In other words: all non-withdrawn coins are paid back to the sidechain.) * The second output is NOT an OP_RETURN script of exactly 10 bytes, of which 8 bytes are a serialized Bitcoin amount. * The txn fee of M6 is NOT exactly equal to the amount of the previous bullet point. +* There are additional OP_DRIVECHAIN outputs after the first one. Else, M6 is valid. From 796c80eb9d78ba5bf64505fab11896c24030e9cf Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 26 Jul 2023 20:07:54 +0000 Subject: [PATCH 6/7] bip-0300: Ensure tx fee commitment itself has zero value so sidechain coins can't get burned --- bip-0300.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki index 6f8a13c2..0a7315ba 100644 --- a/bip-0300.mediawiki +++ b/bip-0300.mediawiki @@ -410,7 +410,7 @@ M6 is invalid if: * The blinded hash of M6 does NOT match one of the approved Bundle-hashes. (In other words: M6 must first be approved by 13,150 upvotes.) * The first output of M6 is NOT an OP_DRIVECHAIN. (This OP_DRIVECHAIN becomes the new CTIP. In other words: all non-withdrawn coins are paid back to the sidechain.) -* The second output is NOT an OP_RETURN script of exactly 10 bytes, of which 8 bytes are a serialized Bitcoin amount. +* The second output is NOT a zero-value OP_RETURN script of exactly 10 bytes, of which 8 bytes are a serialized Bitcoin amount. * The txn fee of M6 is NOT exactly equal to the amount of the previous bullet point. * There are additional OP_DRIVECHAIN outputs after the first one. From c2f4825550b5e13df0c8db650610808e1869cefd Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 26 Jul 2023 20:39:45 +0000 Subject: [PATCH 7/7] bip-0300: Add some guesstimate weight adjustments --- bip-0300.mediawiki | 47 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki index 0a7315ba..ab81c322 100644 --- a/bip-0300.mediawiki +++ b/bip-0300.mediawiki @@ -429,6 +429,53 @@ without it, sidechain numbers 0 and 128 would cause the legacy script interprete If an OP_DRIVECHAIN input is spent, the additional rules for M5 or M6 (see above) must be enforced. +====Weight adjustments==== + +To account for the additional drivechain checks, each message adds to the block's weight: + +{|class="wikitable" +! Message !! Additional weight +|- +| M1 || 840 +|- +| M2 || 336 +|- +| M3 || 848 +|- +| M4 || ? +|- +| M5 || 340 +|- +| M6 || 352 +|} + + + + ==Backward compatibility== As a soft fork, older software will continue to operate without modification. Non-upgraded nodes will see a number of phenomena that they don't understand -- coinbase txns with non-txn data, value accumulating in anyone-can-spend UTXOs for months at a time, and then random amounts leaving these UTXOs in single, infrequent bursts. However, these phenomena don't affect them, or the validity of the money that they receive.