Paul Sztorc [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-23 📝 Original message:On 5/22/2017 8:13 PM, ...
📅 Original date posted:2017-05-23
📝 Original message:On 5/22/2017 8:13 PM, ZmnSCPxj wrote:
> Good morning,
>
>
>
>>What you read is only an introduction of BMM. You may also consult the
> notes (at the bottom of the BMM post) or the code, although this is time
> consuming of course.
>
> Looking over the code, I have a question: Is OP_BRIBE supposed to be
> softforked in, or hardforked?
Softforked, of course.
From my understanding, the code as
> published in your linked github cannot be softforked in, since it is not
> a softfork-compatible replacement for OP_NOP: it replaces the stack top
> value with a 0/1 value. Both CLTV and CSV do not touch the stack, only
> flag an error if they fail.
Your understanding may exceed my own. I don't understand the principle
of your distinction, as it seems to me that one could add a new protocol
rule which says that the block is invalid unless the OP Code does
results in arbitrary-item-x. The intent is to mimic CLTV or CSV
behavior, by causing something that would otherwise succeed, to fail, if
arbitrary new conditions are met.
>
> (What happens if the h* to be put in the coinbase, by chance - even very
> unlikely chance - is 0? Then <h*> OP_NOP4 is not the same as <h*>
> OP_BRIBE scripts in result - the former will be rejected by old nodes,
> the latter will be accepted by new nodes)
That would indeed be a bug, if it happened as you described. I will
check when I get the chance, thanks.
>
> Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?
Yes. Sorry if that was confusing.
>
> How is OP_BRIBE superior to just using a <h*> OP_RETURN script? Cannot
> a sidechain scan the block for OP_RETURN attesting that the block hash
> is present in the block?
The sidechain software can indeed, but the mainchain software cannot
(without making validation of both chains part of the mainchain, which
defeats the original purpose of sidechains).
The purpose of OP_BRIBE is to allow "Sam" (on the sidechain) and "Mary"
(a mainchain miner) to work together. Sam would pay X BTC to Mary, if
Mary could provide Sam with some guarantee that Sam's sidechain block
[defined by h*] would make it into the largest chain.
So, as I see it, this needs to be a mainchain consensus rule, but one
which enforces the bare minimum criteria.
>
>>The literal answer to your question is that mainchain Bitcoin will
> notice that, for the second withdrawal, the sum of the inputs is less
> than the sum of the outputs and they the transaction is therefore invalid.
>
> You misunderstand. The first withdrawal was done by double-spending,
> and exchanging your sidechain funds for mainchain funds using some
> off-chain method. The second withdrawal is done on-chain.
If A, B, and C are transacting, and each has an account on both chains.
Then your example would be something like:
1. main:A sends 100 to side:A, then transfers 100 to side:B in exchange
for B's good or service (provided on the sidechain)
2. side:B attempts to move side-to-main with the 100 BTC, using the
lightning network. He swaps 100 side:BTC for 100 of C's main:BTC.
3. C attempts to move side-to-main, using the slow, settlement method.
4. C's side-to-main sidechain tx (wt) is bundled with others and becomes
a withdrawal attempt (WT^)
5. The WT^ attempt is initiated on the mainchain.
6. After a waiting period, the WT^ begins to accumulate ACKs or NACKs
(upvotes / downvotes), on the mainchain.
7. The transaction either succeeds or fails.
I'm not sure, but your question seems to concern B, who exploits a reorg
that happens just after step 2. After the reorg, the sidechain chain
history will have a different side-to-main withdrawal in part 3. The
time between each of these step is very long, on the order of weeks
(summing to a length of time totaling months), for exactly this reason
(as well as to encourage people to avoid using this 'formal' method, in
favor of the cooperative LN and Atomic Swaps).
I think that this principle of scale (ie, very VERY slow withdrawals) is
important and actually makes the security categorically different.
For extraordinary DAO-like situations, disinterested mainchain miners
merely need a single bit of information (per sidechain), which is
"distress=true", and indicates to them to temporarily stop ACKing
withdrawals from the sidechain. This alone is enough to give the reorg
an unlimited amount of time to work itself out.
>
> That said, I confused OP_h_is_in_coinbase as your method of getting out
> of the sidechain into the mainchain. It seems, OP_h_is_in_coinbase is
> only for blind mining?
Correct
>
>
>
>>I feel that my proposal is more secure, as it can operate healthily and
> quickly while using spv proofs which are much slower and much much
> easier to audit.
>
> I don't quite understand how Drivechain handles sidechain reorgs, while
> keeping Bitcoin miners blinded. It seems sidechains need to be known
> ("seen") by the miner, so I don't see what is being blinded by blinded
> merge mining.
Mainchain miners do need to maintain some data about the sidechains, but
this is very minimal, and certainly does not include the transaction
data (or arbitrary messages) of the sidechain.
>
>
>>>seems to me that your OP_is_h_in_coinbase should scan a series of
> sidechain block headers backed by mainchain (meaning at the minimum that
> sidechains should have some common header format prefix), rather than
> just mainchain depth as your article seems to imply.
>>
>>How would security be improved as a result? In either case, 51% of
> hashrate can cause a reorg. The sidechain software itself does scan
> block headers, of course.
>
> I misunderstand the purpose of your OP_is_h_in_coinbase, sorry.
>
No problem.
>
>>>Blind merged mining seems strictly inferior ... a rich attacker can
> simply reorg the sidechain outright without playing such games.
>>
>>In the future, when there is no block subsidy, a rich attacker can also
> do that in mainchain Bitcoin.
>
> I see. However, block subsidies will drop far in the future, do you
> mean to say, that sidechains will be used only in the far future?
In one sense, I mean "you have already endorsed this 'fees only will
work' premise, by endorsing Bitcoin".
In another sense I mean "isn't it great that you will get a tiny
preview, today, of future-Bitcoin's behavior?".
>
>>>How does your proposal handle multiple side block creators on the same
> sidechain, with the possibility that chain splits occur?
>>
>>The side block is only "mined" if it is committed to in a mainchain
> Bitcoin blog, and each mainchain block can only contain one block per
> sidechain. In this way, drivechain sidechains are different from
> classical Namecoin merged mining (where one _could_ run the entire
> system, mining included, without interfacing with Bitcoin at all).
>
> I assume you mean "mainchain Bitcoin block" here.
>
> What mechanism ensures only one mainchain block can contain only one
> sidechain block? It seems, this isn't implemented by OP_BRIBE yet. Can
> you elaborate on this mechanism?
That mechanism is enforced by drivechain itself, not OP_BRIBE. (OP Bribe
is itself only ~half of BMM. I admit it is getting a little confusing.)
Drivechain requires a soft fork to add each new sidechain. It requires
this literally for a few good reasons...but the best is: there is an
implicit requirement that the miners not steal from the sidechain
anyway. In this way drivechain knows how to keep track of what it should
expect.
>
>
>>>Regarding your dig about people who dislike data centers, the main
> issue with miners blindly accepting sidechain commitments is that it
> violates "Don't trust, verify", not that allows datacenters to be
> slightly smaller by not including side:nodes.
>>
>>As I explain early on, in earlier rounds of peer review, the focus was
> on harms the sidechain technology might do to mainchain Bitcoin, and the
> "datacenter point" was specifically the chief objection raised. So I am
> afraid you are entirely incorrect.
>
> I see. It seems, the main problem, is that sidechains can be used to
> sneak in block size increases. Of course, the advantage of sidechains,
> is that when it increases block size irresponsibly, only those who
> participated in the sidechain will suffer.
Precisely.
>
>>In point of fact, the transactions *are* validated...by sidechain full
> nodes, same as Bitcoin proper.
>
> But from blind merge mining by itself, how would the blinded merge miner
> know that there exists an actual sidechain full node that actually did
> validation?
>
> It seems, that the "blinding" in merge mining does not seem to be at all
> useful without the miner actually seeing the sidechain. If you want
> miners to upgrade to side:fullnode as well, what would then be the point
> of blinding? Why not just ordinary merge mining?
>
> Perhaps the datacenter point is simply that your proposal suggests to
> reduce the size of the datacenter by removing surge suppressors and
> UPS's, to avoid some definition of "datacenter is a room with >$XXX of
> equipment".
I hope that my replies above already help with these. If not, let me know.
Thanks for your attention,
Paul
Published at
2023-06-07 18:01:33Event JSON
{
"id": "5d47c94aa60071cca8492aa7e40ba4f6dfd456fee34de3f5570b6566285fb984",
"pubkey": "7ac0bd39b854f24cbf067103758f3a9d398c23832d6d75824d190ae35c6c23be",
"created_at": 1686160893,
"kind": 1,
"tags": [
[
"e",
"13aad30f7ecbcd37c38d151da19b0bb97f1dbccd9f86dce3131cc3b52530ea2a",
"",
"root"
],
[
"e",
"a59560480d40086bd722b5fb1f829663ce0ab1c1015b1bce6b6de9cf9fb358a1",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2017-05-23\n📝 Original message:On 5/22/2017 8:13 PM, ZmnSCPxj wrote:\n\u003e Good morning,\n\u003e \n\u003e \n\u003e \n\u003e\u003eWhat you read is only an introduction of BMM. You may also consult the\n\u003e notes (at the bottom of the BMM post) or the code, although this is time\n\u003e consuming of course.\n\u003e \n\u003e Looking over the code, I have a question: Is OP_BRIBE supposed to be\n\u003e softforked in, or hardforked?\n\nSoftforked, of course.\n\n From my understanding, the code as\n\u003e published in your linked github cannot be softforked in, since it is not\n\u003e a softfork-compatible replacement for OP_NOP: it replaces the stack top\n\u003e value with a 0/1 value. Both CLTV and CSV do not touch the stack, only\n\u003e flag an error if they fail.\n\nYour understanding may exceed my own. I don't understand the principle\nof your distinction, as it seems to me that one could add a new protocol\nrule which says that the block is invalid unless the OP Code does\nresults in arbitrary-item-x. The intent is to mimic CLTV or CSV\nbehavior, by causing something that would otherwise succeed, to fail, if\narbitrary new conditions are met.\n\n\u003e \n\u003e (What happens if the h* to be put in the coinbase, by chance - even very\n\u003e unlikely chance - is 0? Then \u003ch*\u003e OP_NOP4 is not the same as \u003ch*\u003e\n\u003e OP_BRIBE scripts in result - the former will be rejected by old nodes,\n\u003e the latter will be accepted by new nodes)\n\nThat would indeed be a bug, if it happened as you described. I will\ncheck when I get the chance, thanks.\n\n\u003e \n\u003e Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?\n\nYes. Sorry if that was confusing.\n\n\u003e \n\u003e How is OP_BRIBE superior to just using a \u003ch*\u003e OP_RETURN script? Cannot\n\u003e a sidechain scan the block for OP_RETURN attesting that the block hash\n\u003e is present in the block?\n\nThe sidechain software can indeed, but the mainchain software cannot\n(without making validation of both chains part of the mainchain, which\ndefeats the original purpose of sidechains).\n\nThe purpose of OP_BRIBE is to allow \"Sam\" (on the sidechain) and \"Mary\"\n(a mainchain miner) to work together. Sam would pay X BTC to Mary, if\nMary could provide Sam with some guarantee that Sam's sidechain block\n[defined by h*] would make it into the largest chain.\n\nSo, as I see it, this needs to be a mainchain consensus rule, but one\nwhich enforces the bare minimum criteria.\n\n\n\u003e \n\u003e\u003eThe literal answer to your question is that mainchain Bitcoin will\n\u003e notice that, for the second withdrawal, the sum of the inputs is less\n\u003e than the sum of the outputs and they the transaction is therefore invalid.\n\u003e \n\u003e You misunderstand. The first withdrawal was done by double-spending,\n\u003e and exchanging your sidechain funds for mainchain funds using some\n\u003e off-chain method. The second withdrawal is done on-chain.\n\nIf A, B, and C are transacting, and each has an account on both chains.\nThen your example would be something like:\n\n1. main:A sends 100 to side:A, then transfers 100 to side:B in exchange\nfor B's good or service (provided on the sidechain)\n2. side:B attempts to move side-to-main with the 100 BTC, using the\nlightning network. He swaps 100 side:BTC for 100 of C's main:BTC.\n3. C attempts to move side-to-main, using the slow, settlement method.\n4. C's side-to-main sidechain tx (wt) is bundled with others and becomes\na withdrawal attempt (WT^)\n5. The WT^ attempt is initiated on the mainchain.\n6. After a waiting period, the WT^ begins to accumulate ACKs or NACKs\n(upvotes / downvotes), on the mainchain.\n7. The transaction either succeeds or fails.\n\nI'm not sure, but your question seems to concern B, who exploits a reorg\nthat happens just after step 2. After the reorg, the sidechain chain\nhistory will have a different side-to-main withdrawal in part 3. The\ntime between each of these step is very long, on the order of weeks\n(summing to a length of time totaling months), for exactly this reason\n(as well as to encourage people to avoid using this 'formal' method, in\nfavor of the cooperative LN and Atomic Swaps).\n\nI think that this principle of scale (ie, very VERY slow withdrawals) is\nimportant and actually makes the security categorically different.\n\nFor extraordinary DAO-like situations, disinterested mainchain miners\nmerely need a single bit of information (per sidechain), which is\n\"distress=true\", and indicates to them to temporarily stop ACKing\nwithdrawals from the sidechain. This alone is enough to give the reorg\nan unlimited amount of time to work itself out.\n\n\n\u003e \n\u003e That said, I confused OP_h_is_in_coinbase as your method of getting out\n\u003e of the sidechain into the mainchain. It seems, OP_h_is_in_coinbase is\n\u003e only for blind mining?\n\nCorrect\n\n\u003e \n\u003e \n\u003e \n\u003e\u003eI feel that my proposal is more secure, as it can operate healthily and\n\u003e quickly while using spv proofs which are much slower and much much\n\u003e easier to audit.\n\u003e \n\u003e I don't quite understand how Drivechain handles sidechain reorgs, while\n\u003e keeping Bitcoin miners blinded. It seems sidechains need to be known\n\u003e (\"seen\") by the miner, so I don't see what is being blinded by blinded\n\u003e merge mining.\n\nMainchain miners do need to maintain some data about the sidechains, but\nthis is very minimal, and certainly does not include the transaction\ndata (or arbitrary messages) of the sidechain.\n\u003e \n\u003e \n\u003e\u003e\u003eseems to me that your OP_is_h_in_coinbase should scan a series of\n\u003e sidechain block headers backed by mainchain (meaning at the minimum that\n\u003e sidechains should have some common header format prefix), rather than\n\u003e just mainchain depth as your article seems to imply.\n\u003e\u003e\n\u003e\u003eHow would security be improved as a result? In either case, 51% of\n\u003e hashrate can cause a reorg. The sidechain software itself does scan\n\u003e block headers, of course. \n\u003e \n\u003e I misunderstand the purpose of your OP_is_h_in_coinbase, sorry.\n\u003e \n\nNo problem.\n\n\u003e \n\u003e\u003e\u003eBlind merged mining seems strictly inferior ... a rich attacker can\n\u003e simply reorg the sidechain outright without playing such games.\n\u003e\u003e\n\u003e\u003eIn the future, when there is no block subsidy, a rich attacker can also\n\u003e do that in mainchain Bitcoin.\n\u003e \n\u003e I see. However, block subsidies will drop far in the future, do you\n\u003e mean to say, that sidechains will be used only in the far future?\n\nIn one sense, I mean \"you have already endorsed this 'fees only will\nwork' premise, by endorsing Bitcoin\".\n\nIn another sense I mean \"isn't it great that you will get a tiny\npreview, today, of future-Bitcoin's behavior?\".\n\n\u003e \n\u003e\u003e\u003eHow does your proposal handle multiple side block creators on the same\n\u003e sidechain, with the possibility that chain splits occur?\n\u003e\u003e\n\u003e\u003eThe side block is only \"mined\" if it is committed to in a mainchain\n\u003e Bitcoin blog, and each mainchain block can only contain one block per\n\u003e sidechain. In this way, drivechain sidechains are different from\n\u003e classical Namecoin merged mining (where one _could_ run the entire\n\u003e system, mining included, without interfacing with Bitcoin at all).\n\u003e \n\u003e I assume you mean \"mainchain Bitcoin block\" here.\n\u003e \n\u003e What mechanism ensures only one mainchain block can contain only one\n\u003e sidechain block? It seems, this isn't implemented by OP_BRIBE yet. Can\n\u003e you elaborate on this mechanism?\n\nThat mechanism is enforced by drivechain itself, not OP_BRIBE. (OP Bribe\nis itself only ~half of BMM. I admit it is getting a little confusing.)\n\nDrivechain requires a soft fork to add each new sidechain. It requires\nthis literally for a few good reasons...but the best is: there is an\nimplicit requirement that the miners not steal from the sidechain\nanyway. In this way drivechain knows how to keep track of what it should\nexpect.\n\n\u003e \n\u003e \n\u003e\u003e\u003eRegarding your dig about people who dislike data centers, the main\n\u003e issue with miners blindly accepting sidechain commitments is that it\n\u003e violates \"Don't trust, verify\", not that allows datacenters to be\n\u003e slightly smaller by not including side:nodes.\n\u003e\u003e\n\u003e\u003eAs I explain early on, in earlier rounds of peer review, the focus was\n\u003e on harms the sidechain technology might do to mainchain Bitcoin, and the\n\u003e \"datacenter point\" was specifically the chief objection raised. So I am\n\u003e afraid you are entirely incorrect.\n\u003e \n\u003e I see. It seems, the main problem, is that sidechains can be used to\n\u003e sneak in block size increases. Of course, the advantage of sidechains,\n\u003e is that when it increases block size irresponsibly, only those who\n\u003e participated in the sidechain will suffer.\n\nPrecisely.\n\n\u003e \n\u003e\u003eIn point of fact, the transactions *are* validated...by sidechain full\n\u003e nodes, same as Bitcoin proper.\n\u003e \n\u003e But from blind merge mining by itself, how would the blinded merge miner\n\u003e know that there exists an actual sidechain full node that actually did\n\u003e validation?\n\u003e \n\u003e It seems, that the \"blinding\" in merge mining does not seem to be at all\n\u003e useful without the miner actually seeing the sidechain. If you want\n\u003e miners to upgrade to side:fullnode as well, what would then be the point\n\u003e of blinding? Why not just ordinary merge mining?\n\u003e \n\u003e Perhaps the datacenter point is simply that your proposal suggests to\n\u003e reduce the size of the datacenter by removing surge suppressors and\n\u003e UPS's, to avoid some definition of \"datacenter is a room with \u003e$XXX of\n\u003e equipment\".\n\nI hope that my replies above already help with these. If not, let me know.\n\nThanks for your attention,\nPaul",
"sig": "92d03f34d2b149f59a3f4165fae8a2ed1a7790f788f08cd8204c42a2e607159dd1b4a8391442c3a5f7aa115c3abbdeb64891ccc9cdf23220fcbd04fc9ae8e2ef"
}