bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

typos

Browse Source
This commit is contained in:
Paul Sztorc 2018-02-10 17:31:01 -05:00
parent 70f0ed6c39
commit 5418516065
1 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
bip-blind-merged-mining.mediawiki
View File

@ -194,12 +194,13 @@ M8_V1 does not require the Lightning network but does have new requirements for
A M8_V1 TxOut is expected to contain: A M8_V1 TxOut is expected to contain:
<pre>
1-byte - OP_RETURN (0x6a) 1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24) 1-byte - Push the following 36 bytes (0x24)
4-byte - Message header (0xD1617368) 4-byte - Message header (0xD1617368)
32-bytes - h* side:block hash 32-bytes - h* side:block hash
5~7-bytes - BMM request identifying bytes (0x00bf00) + prevBlockRef & ChainIndex (sidechain mini-header) 5~7-bytes - BMM request identifying bytes (0x00bf00) + prevBlockRef & ChainIndex (sidechain mini-header)
</pre>
In the first version of M8, we need to introduce the concept of Immediate Expiration (see above). In other words, we need a way for Simon to construct many payments to multiple Marys, such that only one of these is ever included; and only then if Simon's txn is expected to coincide with the finding of Simon's side:block. In the first version of M8, we need to introduce the concept of Immediate Expiration (see above). In other words, we need a way for Simon to construct many payments to multiple Marys, such that only one of these is ever included; and only then if Simon's txn is expected to coincide with the finding of Simon's side:block.
@ -225,16 +226,18 @@ Interestingly, these payments (M8) will *always* be directed to miners from non-
===== M8_V2 With Lightning ===== ===== M8_V2 With Lightning =====
M8_V2 requires having a LN-channel open with a miner. This may not always be practical (or even possible), especially today. M8_V2 requires having a LN-channel pathway open with a miner. This may not always be practical (or even possible), especially today.
A M8_V1 TxOut is expected to contain: A M8_V1 TxOut is expected to contain:
<pre>
1-byte - OP_RETURN (0x6a) 1-byte - OP_RETURN (0x6a)
1-byte - Push the following 68 bytes (0x44) 1-byte - Push the following 68 bytes (0x44)
4-byte - Message header (0xD0520C6E) 4-byte - Message header (0xD0520C6E)
32-bytes - h* side:block hash 32-bytes - h* side:block hash
32-bytes - prevSideBlockHash 32-bytes - prevSideBlockHash
5~7-bytes - BMM request identifying bytes (0x00bf00) + prevBlockRef & ChainIndex (sidechain mini-header) 5~7-bytes - BMM request identifying bytes (0x00bf00) + prevBlockRef & ChainIndex (sidechain mini-header)
</pre>
Notice that, in M8_V1, Simon could reuse the same h\* all he wanted, because only one M8_V1 could be included per main:block per sidechain. However, on the LN no such rule can be enforced, as the goal is to push everything off-chain and include *zero* M8s. So, we will never know what the M8s were or how many had an effect on anything. Notice that, in M8_V1, Simon could reuse the same h\* all he wanted, because only one M8_V1 could be included per main:block per sidechain. However, on the LN no such rule can be enforced, as the goal is to push everything off-chain and include *zero* M8s. So, we will never know what the M8s were or how many had an effect on anything.