BIP 300: Hashrate Escrows (Consensus layer)

psztorc commented at 2:33 am on February 4, 2018: contributor

This is my draft of the hashrate escrows bip, the first of two drivechain bips.

luke-jr added the label New BIP on Feb 5, 2018

luke-jr commented at 5:08 am on February 6, 2018: member

This seems to have the wrong files…?

psztorc commented at 7:05 pm on February 10, 2018: contributor

This seems to have the wrong files…?

It does, my mistake! Fixed now

psztorc commented at 10:03 pm on February 10, 2018: contributor

Ok, this one appears to have survived the transition to .mediawiki format.

jtimon commented at 2:26 am on February 18, 2018: contributor

written partially by some Blockstream co-founders.

why do the bip readers care about who wrote it?

A Hashrate Escrow resembles a 2-of-3 multisig escrow, where the 3rd party (who will arbitrate any disputes) is a decentralized group of people: the dynamic-membership set of Bitcoin Miners

This is not true for sidechains using spv 2wp. If you want to make that analogy, at most it would be with the sidechain miners, not with bitcoin miners. Remember merged mining is only an option. Sidechains could even use different proof of work than bitcoin.

jtimon commented at 2:45 am on February 18, 2018: contributor

Also, wouldn’t it be better to rebase the implementation on top of master rather than backport changes from master to it? How are we supposed to find out which commits are relevant to the implementation of this BIP?

psztorc commented at 5:52 pm on February 18, 2018: contributor

written partially by some Blockstream co-founders.

why do the bip readers care about who wrote it?

It is cursory background information. Often, the easiest way to explain something is to link it to an existing thing that the audience may already be familiar with.

A Hashrate Escrow resembles a 2-of-3 multisig escrow, where the 3rd party (who will arbitrate any disputes) is a decentralized group of people: the dynamic-membership set of Bitcoin Miners

This is not true for sidechains using spv 2wp.

Actually, it is true. Even if the sidechain uses a different PoW, since 51% mainchain hashrate can control the contents of the mainchain entirely, they can “steal” from the sidechain.

And here it is doubly true because the SPV proof here always proves mainchain work, not sidechain work.

psztorc commented at 6:04 pm on February 18, 2018: contributor

Also, wouldn’t it be better to rebase the implementation on top of master rather than backport changes from master to it? How are we supposed to find out which commits are relevant to the implementation of this BIP?

Are you talking about the BIP text? Because the code is in a branch called “mainchainBMM” as seen here https://github.com/drivechain-project/bitcoin/tree/mainchainBMM .

jtimon commented at 7:56 pm on February 18, 2018: contributor

Actually, it is true. Even if the sidechain uses a different PoW, since 51% mainchain hashrate can control the contents of the mainchain entirely, they can “steal” from the sidechain.

No, all they can do is censor the pegouts, but they cannot keep the coins for themselves without providing an spv proof with work from the sidechain. In spv 2wp, the pegin tx in the sidechain presents work from the mainchain, and the pegout tx on the mainchain presents work from the sidechain.

Are you talking about the BIP text? Because the code is in a branch called “mainchainBMM” as seen here https://github.com/drivechain-project/bitcoin/tree/mainchainBMM .

I’m talking about that branch, it seems to have commits recently backported from master apart from the necessary changes. Don’t you have a branch that contains only the changes that would be necessary (done against current master or against some other previous version of master)? That would be more convenient for review. Perhaps you can point out thecommits on that branch that are relevant for this BIP?

For example, commit https://github.com/drivechain-project/bitcoin/commit/948c29cc0d2df72b2f9717b8d33c5e29e2f9582c in your branch is clearly not relevant to the implementation of this BIP.

psztorc commented at 10:43 pm on February 18, 2018: contributor

Actually, it is true. Even if the sidechain uses a different PoW, since 51% mainchain hashrate can control the contents of the mainchain entirely, they can “steal” from the sidechain.

No, all they can do is censor the pegouts, but they cannot keep the coins for themselves without providing an spv proof with work from the sidechain. In spv 2wp, the pegin tx in the sidechain presents work from the mainchain, and the pegout tx on the mainchain presents work from the sidechain.

That is a mistake which it was very important to fix. You are 1.5 years behind on the latest sidechain theory.

Don’t you have a branch that contains only the changes that would be necessary (done against current master or against some other previous version of master)?

Do you mean this??? https://github.com/bitcoin/bitcoin/compare/master...drivechain-project:mainchainBMM

jtimon commented at 1:17 am on February 19, 2018: contributor

Do you mean this??? bitcoin/bitcoin@master…drivechain-project:mainchainBMM

Sorry, yes! I meant that. Thank you.

That is a mistake which it was very important to fix. You are 1.5 years behind on the latest sidechain theory.

I haven’t watched the video, but, ok, I guess…never too late to catch up!

Still, with spv 2wp, all bitcoin miners can do is censor the pegouts, but they cannot keep the coins for themselves without providing an spv proof with work from the sidechain.

So I think the part of the BIP that contradicts this (ie “A Hashrate Escrow resembles a 2-of-3 multisig escrow, where the 3rd party (who will arbitrate any disputes) is a decentralized group of people: the dynamic-membership set of Bitcoin Miners”) should be corrected. Another possibility - if that is a necessary part of the definition of a “Hashrate Escrow” is to exclude sidechains (or at least the spv 2wp) from its definition, since it doesn’t have the same properties.

Otherwise one could get confused thinking that “An spv 2wp resembles a 2-of-3 multisig escrow, where the 3rd party (who will arbitrate any disputes) is a decentralized group of people: the dynamic-membership set of Bitcoin Miners”, which is not true.

psztorc commented at 5:49 am on April 11, 2018: contributor

I haven’t watched the video, but, ok, I guess…never too late to catch up! Still, with spv 2wp, all bitcoin miners can do is censor the pegouts, but they cannot keep the coins for themselves without providing an spv proof with work from the sidechain.

So I think the part of the BIP that contradicts this (ie “A Hashrate Escrow resembles a 2-of-3 multisig escrow, where the 3rd party (who will arbitrate any disputes) is a decentralized group of people: the dynamic-membership set of Bitcoin Miners”) should be corrected.

The video makes the case for the set of miners being the same. Ie “spv proof with work from the sidechain” would be the same as “dynamic-membership set of Bitcoin Miners”.

So it is correct as-is.

Your other comments are just the same error repeated.

gusbjerpe commented at 7:41 am on April 11, 2018: none

May I ask why this isn’t getting assigned a BIP#?

CryptAxe commented at 0:16 am on April 28, 2018: none

@gusbjerpe I believe that Luke-jr who maintains this repository is simply a very busy man.

in bip-hashrate-escrows.mediawiki:2 in 0c186ed8e2 outdated

0@@ -0,0 +1,469 @@
1+
2+

luke-jr commented at 1:18 pm on May 30, 2018:

Please drop the empty lines here

psztorc commented at 7:19 pm on May 30, 2018:

Ok

in bip-hashrate-escrows.mediawiki:20 in 0c186ed8e2 outdated

15+    Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html
16+</pre>
17+
18+==Abstract==
19+
20+A "Hashrate Escrow" is a clearer term for the concept of "locked to an SPV Proof", which is itself a restatement of the phrase "within a sidechain" as described in [https://blockstream.com/sidechains.pdf a famous Oct 2014 paper] written partially by some Blockstream co-founders.

luke-jr commented at 1:19 pm on May 30, 2018:

The end looks like it belongs in the Credits section, rather than Abstract.

psztorc commented at 7:21 pm on May 30, 2018:

I don’t really think so

in bip-hashrate-escrows.mediawiki:67 in 0c186ed8e2 outdated

62+
63+==== On the Resource Requirements of New Databases ====
64+
65+The "new" databases are simply reinterpretations of data that are already contained elsewhere in the blockchain. Specifically, M1 M2 and M3 are all located in the block's coinbase txn, and M5 and M6 might be found in any regular txn. M4 is a special case and does not actually need to be included anywhere, so it is not. If you like, you can imagine that the M4s reside in an optional extension block.
66+
67+In other words, we just rearrange what is already there. Because of this, even though "new databases" are created and stored in memory, the existing bandwidth and storage limits are respected (although, see "M4" below).

luke-jr commented at 1:21 pm on May 30, 2018:

This does not seem to logically follow. The existing databases are not being apparently reduced in size to compensate, so it is strictly adding requirements here, no?

I think it may be appropriate to increase the block weight when these new databases are affected.

psztorc commented at 7:31 pm on May 30, 2018:

I suppose that you are right that the “storage” requirements would in some sense increase. But, as a soft fork, this would only be for users who upgrade.

This would also be true if, for example, the latest Bitcoin Core were larger in size, and so downloading and building the software required more disk space. Or it would be true for a release that required the upgrading users to track Segwit and nonSegwit outputs and sort among these (or even, CheckLocktimeVerify outputs and non-CLTV outputs). In such cases I would find it strange to decrease the block size/weight limits to offset this cost.

But nonetheless I think I could remove the “and storage” phrase from the last sentence.

luke-jr commented at 8:23 pm on May 30, 2018:

Just because old node software is not broken by a softfork does not make it any less necessary for all users to upgrade. If it were just storage, it might be no big deal - but this affects size of the state as well.

psztorc commented at 9:25 pm on May 30, 2018:

If it were just storage, it might be no big deal - but this affects size of the state as well.

Are you only focusing on M4?

Just because old node software is not broken by a softfork does not make it any less necessary for all users to upgrade.

In an opcode softfork, non-upgraded nodes don’t know if newer blocks contain invalid opcode operations. In this softfork, non-upgraded nodes won’t know if the newer blocks contain invalid sidechain operations.

This upgrade is a little strange because it has a state, but I don’t understand how it compels users to upgrade. They can still just not upgrade, and even if they do upgrade, we could theoretically add some kind of “sidechains off” option where they don’t choose to track any sidechain data.

Although that would be super crazy and open Pandora’s Box to a kind of “a la carte” consensus.

luke-jr commented at 9:32 pm on May 30, 2018:

Non-upgraded nodes is never a viable option for any softfork. Old nodes remain compatible, but nobody is supposed to actually use them.

psztorc commented at 10:34 pm on May 30, 2018:

Hmmm, ok.

So, you would like it to be such that, when there are many sidechains and many withdrawals at once, (ie, when M4 is large), then the blockweight limit decreases by this size?

So, for example, the extreme attacker case, where 256 sidechains have been added, and all of them are doing nothing but spamming full node miners all day, such that in each block a new withdrawal is attempted on each sidechain, such that there are 26300*256 withdrawals at once (this would already be comically irrational for each miner, as it would consume a ridiculous amount of regular blockchain space, that they could instead use to include txns and collect txn fees). M4 might need to be as large as 841,670 bytes. So you would want the blocksize/weight to decrease by 842 kb while the network is in such a state? Because, to you, my alternative (that users just disregard what is happening amonst miners) is not rigorous enough?

I could shrink that 842 considerably. One way would be to allow ACK counts to go negative, and then further to have some event trigger upon an ACK-count reaching -250 or so. Upon such a count we could delete all withdrawals (from that sidechain) that have a negative ACK count at that time. Then even with 256 sidechains, M4’s size would never need to be more than 8 kb or so.

luke-jr commented at 6:21 am on March 29, 2019:

Anything that adds to the burden of nodes doing FULL validation, should count as weight in some way, at least.

in bip-hashrate-escrows.mediawiki:78 in 0c186ed8e2 outdated

73+
74+==== D1 -- "Escrow_DB" ====
75+
76+The table below enumerates the new database fields, their size in bytes, and their purpose. In general, an escrow designer (for example, a sidechain-designer), is free to choose any value for these.
77+
78+Note: Fields 6 through 9 have been intentionally removed. Previously, this section allowed miners to set and commit to voting/waiting periods. However, I have since standardized the periods: withdrawals expire after 6 months (26298 blocks), and they succeed if they ever achieve an ACK score of 13140 or higher. I have removed the waiting period, because anyone who adopts a policy of ignoring all withdrawals with fewer than 400 ACKs will automatically gain all of the benefits of the waiting period. The justification for this change is that it strongly implies that an attack on any one sidechain is an attack on all of them (in a sense, this change makes the "victimhood" of each sidechain "fungible").

luke-jr commented at 1:23 pm on May 30, 2018:

Why not have optional overrides? I’m not sure it’s a good idea to hardcode these.

psztorc commented at 7:38 pm on May 30, 2018:

The justification is given: to remove ACK-count as a basis for discriminating against sidechains, and make them identical in this respect. It is also less complex (and safer). And it is slightly more byte-efficient, of course.

Ultimately the user is always in charge. But it is more convenient for the user if a design has safeguards in place to prevent errors. It is better for all sidechains if they share ACK-periods, but probably most users do not understand why.

But I suppose it could be optional.

in bip-hashrate-escrows.mediawiki:103 in 0c186ed8e2 outdated

 98+|-
 99+| 3
100+| Escrow Name/Description
101+| 120
102+| string
103+| A human-readable name and description of the sidechain. More than enough space to hold a 32 byte hash. Helps prevent destructive interference among sidechains (see below).

luke-jr commented at 1:24 pm on May 30, 2018:

A UUID or hash seems like a better option here. Human-readable stuff doesn’t really belong on-chain.

psztorc commented at 7:41 pm on May 30, 2018:

These hashes that you keep talking about inserting are the mandatory extension blocks that you dislike!

Miners and users will be looking for the underlying data. So the hash achieves nothing – it is just a waste of 32 bytes. And moving this data off chain just obfuscates it.

in bip-hashrate-escrows.mediawiki:109 in 0c186ed8e2 outdated

104+|-
105+| 4
106+| Critical Private Key
107+| 32
108+| hex
109+| This is the Double-SHA256 of the binary release of the reference software. It ties the sidechain to a specific software release, and doubles as a way of signing withdrawals (see below).

luke-jr commented at 1:25 pm on May 30, 2018:

What architecture? Compiled with what options? Why is there such a thing as reference software in the first place?

I don’t think this field makes sense…

psztorc commented at 7:57 pm on May 30, 2018:

It is helpful in cases where there is a disagreement over the definition of a sidechain. It prevents users from being misled over which software to download (if, for example, they want to run “the zcash sidechain” and someone is pretending to offer that software for download).

If a sidechain software has one “reference software”, then it inherits the institution of the soft fork. This is great for users who like soft forks. And it is great for developers who want to resist being coerced into hardforking-in bad features into their sidechains.

pennersr commented at 8:20 pm on May 30, 2018:

@psztorc You did not address the “What architecture? Compiled with what options?” part. Is it supposed to be a Linux/Mac/Windows binary…?

psztorc commented at 9:35 pm on May 30, 2018:

@pennersr I actually don’t see how it matters. The options/configuration instructions could be defined in the source code itself.

More important to me, though, is that the sidechains have a “freedom to fail” design. If so, the sidechain designers are free to make whatever crazy mistakes/choices they think their users want.

But it is important to have a reference implementation, is it not? For exactly the same reasons that Satoshi / Peter Todd are against alternative implementations of Bitcoin – if they ever disagree over a single byte, there will be consensus failure.

This was just a simple idea on how to try to prevent that.

in bip-hashrate-escrows.mediawiki:115 in 0c186ed8e2 outdated

110+|-
111+| 5
112+| Critical Address*
113+| 32
114+| string
115+| This is derived by taking f(x) = ImportPrivateKey(HexToBase58Check(x)) of field #3. It is intentionally in the human-readable format {{although it could be 25 bytes of binary}}.

luke-jr commented at 1:26 pm on May 30, 2018:

How it’s stored seems like it’s an implementation-specific detail?

Not sure what the point is of this field…

psztorc commented at 7:58 pm on May 30, 2018:

Yes, the ones with asterisks are not fundamental.

in bip-hashrate-escrows.mediawiki:148 in 0c186ed8e2 outdated

143+
144+=====Obligations Placed on Miners=====
145+
146+Miners have always upgraded their software according to criteria that are known only to them (in other words, "whenever they want").
147+
148+However, this soft fork imposes two new criteria upon them. First: miners should only upgrade their software, if any modification to the portfolio of sidechains [that are added/removed in the upgrade] can be expected to increase miner wealth. Trivially, this implies that miners should make sure that the upgrade doesn't overwrite (and destroy) an existing sidechain that they like! But, more seriously, it implies that miners should take an interest in what the sidechain is doing to the mainchain and other sidechains (see below).

luke-jr commented at 1:28 pm on May 30, 2018:

These requirements are subjective and cannot be imposed.

As it stands, I think this may be a technical unsoundness. (impediment to a BIP number assignment) :(

psztorc commented at 8:04 pm on May 30, 2018:

The first requirement was an implied part of the SegWit UASF BIP.

And both are really not that subjective – knowledge about “what will maximize profits” does exist. And even if it exists imperfectly, then that is no different from any other kind of knowledge.

And in the UASF case these “requirements” ended up being imposed, in practice.

But if you want to reject the BIP, arguing that it is technically unsound to require miners to maximize their profitability, I am fine with that.

luke-jr commented at 8:27 pm on May 30, 2018:

Profitability is subjective. For example, Evilsidechain could be offering a large bribe.

I don’t understand how you’re trying to tie this to UASFs… maybe I’m missing something?

psztorc commented at 9:41 pm on May 30, 2018:

Profitability is subjective. For example, Evilsidechain could be offering a large bribe.

Either the bribe is objectively larger than some value, or it objectively is not. So I don’t see how this is an example of subjectivity?

I don’t understand how you’re trying to tie this to UASFs

In the UASF, miners must decide whether they want to upgrade their software (surrender to the UASF) or not (in which case they fight the UASF). And they will make this decision based on their (imperfect) knowledge of the profitability of each version of the protocol.

In fact , this is true of all soft forks, not just UASFs. As someone could propose a softfork that made coinbase-txn maturity 300,000 blocks, instead of 100; and which reduced the blocksize/weight to 500 bytes. And even in the pre-UASF era, miners would have to decide whether or not to install that software.

luke-jr commented at 9:43 pm on May 30, 2018:

The bribe might not be offered to all miners equally.

It doesn’t seem like you understand UASFs… miners must choose to upgrade to remain part of the network, or failure to do so would be them launching an altcoin (whether they run the old software or make other changes). There is no pre-UASF era… the earliest softforks were all UASFs.

psztorc commented at 10:13 pm on May 30, 2018:

It doesn’t seem like you understand UASFs… miners must choose to upgrade to remain part of the network

It seems I do not. For instance, I don’t understand what happens if two mutually-exclusive UASFs are released at once, and each of these are installed by exactly half of the userbase? Then miners cannot “choose to upgrade to remain part of the network”, as you say, because there are now (or will be soon) two networks.

And my example scenario is not really that hard to imagine. For example, suppose that after the SegWit UASF was proposed, someone else proposed a soft fork banning OP returns from coinbase txns (for whatever reason). Or if two people tried to reassign the same unused opcode at the same time, via a UASF alone.

There is no pre-UASF era… the earliest softforks were all UASFs.

I refer to the modern prominence of the UASF, in contrast to a MASF. Specifically, I am using the terms “pre-UASF era” and “before Feb 25th, 2017” interchangeably.

in bip-hashrate-escrows.mediawiki:154 in 0c186ed8e2 outdated

149+
150+===== Destructive Sidechain Interference =====
151+
152+People frequently emphasize that miners should have "as little control" as possible. It is a very safe claim to make, and a very easy sentence to write. Much harder is to determine exactly what this minimum value is, and how to achieve it. Harder still is to untie the knot of who is actually controlling what, in a decentralized, interacting system.
153+
154+Certainly, miners can not have "zero control" -- for that is the same as to just remove them from the system altogether. Some rules are enforced "on miners by nodes" (such as the infamous blocksize limit); other rules are enforced by nodes but are narrowly-controlled by miners (such as the proof-of-work itself, or the block's timestamp). Thirdly, some rules are enforced by both against each other (such as the rule against including invalid txns or double-spent txns), for mutual benefit.

luke-jr commented at 1:30 pm on May 30, 2018:

The rules against invalid or double-spent txns are exactly identical to the rules against exceeding the block weight limit. I’m not sure what distinction you are implying exists here…

psztorc commented at 8:06 pm on May 30, 2018:

It is a distinction about control, as I say.

If miners had the option to remove the block weight, they probably would. But if they had the option to allow invalid txns, they probably would not.

luke-jr commented at 8:27 pm on May 30, 2018:

That seems unlikely. Miners could profit a lot if invalid transactions were allowed.

psztorc commented at 9:50 pm on May 30, 2018:

I don’t see how. It would just make Bitcoin more annoying to use for everyone, with no benefit. So BTC would be less useful, and miners are paid in BTC. So miners would be choosing to pay themselves less.

But nonetheless, this establishes the distinction you asked for. It is about which constraints are protecting whom.

In the future, I and many others believe that miners will switch to monopolist pricing, and self-impose a blocksize/weight limit on each other. So it would be wrong to say that nodes “control” the limit (because they cannot increase it). But it would be wrong to say that miners “control” the limit as it is driven by their collective need to maximize revenues.

in bip-hashrate-escrows.mediawiki:156 in 0c186ed8e2 outdated

151+
152+People frequently emphasize that miners should have "as little control" as possible. It is a very safe claim to make, and a very easy sentence to write. Much harder is to determine exactly what this minimum value is, and how to achieve it. Harder still is to untie the knot of who is actually controlling what, in a decentralized, interacting system.
153+
154+Certainly, miners can not have "zero control" -- for that is the same as to just remove them from the system altogether. Some rules are enforced "on miners by nodes" (such as the infamous blocksize limit); other rules are enforced by nodes but are narrowly-controlled by miners (such as the proof-of-work itself, or the block's timestamp). Thirdly, some rules are enforced by both against each other (such as the rule against including invalid txns or double-spent txns), for mutual benefit.
155+
156+Some pause should be given, after one considers that the sidechain design goal is literally a piece of software that can do *anything*. Anything includes a great many things, many of which I demonstrate to be undesirable. Bitcoin itself does not allow "anything" -- it allows any person to transact, but, in contrast, it does not permit any person to double-spend. This is because "allowing anyone to do anything" is not viable in a world that contains undesirable interactions (what a libertarian might call "aggression") -- in the case of money, these are theft and counterfeiting.

luke-jr commented at 1:31 pm on May 30, 2018:

I don’t think equating undesirable transactions to “aggression” makes sense here. It also seems out of place.

psztorc commented at 7:45 pm on May 30, 2018:

They are transactions that prevent other, more objectively valuable (in terms of txn fees, and consumer surplus) transactions from taking place. In that sense they really do resemble “theft” in modern society (which makes it difficult for society to produce anything worth stealing).

How would you explain it?

in bip-hashrate-escrows.mediawiki:171 in 0c186ed8e2 outdated

166+To the best of my knowledge, everyone who *has* reviewed this information as found the arguments to be acceptable. It has, also, changed a few minds (from "unacceptable" to "acceptable").
167+
168+
169+===== ISSUE: "Signing" BTC Txns =====
170+
171+Currently, we use a process which may be suboptimal. It is that we *literally sign* a txn with a globally and publicly known private key. But this is for convenience purposes -- to easily detect the sidechain's balance. The signature that is produced is not doing anything. This is probably an area of improvement.

luke-jr commented at 1:32 pm on May 30, 2018:

If it doesn’t do anything, it shouldn’t exist at all…

psztorc commented at 7:43 pm on May 30, 2018:

As I said, the process as it stands does do something – it allows tracking of the sidechain’s balance.

psztorc commented at 7:45 pm on May 30, 2018:

If you have a better way of doing that, we will change it.

luke-jr commented at 8:29 pm on May 30, 2018:

I don’t see how this allows tracking the balance any more than without it.

psztorc commented at 9:52 pm on May 30, 2018:

That could be because you know what to do and we don’t.

Currently we track the sidechain’s balance by adding a kind of “watching only” address, as I said.

But this is something we plan to revisit and remove as soon as we have more time to look into it.

jtimon commented at 1:59 pm on May 31, 2018:

You can improve the design now and leave the improvements to the implementation for later.

Why don’t you just use a new opcode like blue matt suggested in the mailing list? Note that it is orthogonal to putting it all on one output or not.

psztorc commented at 11:36 pm on June 2, 2018:

Why don’t you just use a new opcode

We will probably add this option

CryptAxe commented at 0:02 am on June 3, 2018:

We could use one of the expansion opcodes (like NOP4). It seems suboptimal to use one of them up since we do not require any interaction with the script interpreter though. Instead I think it would be best to make use of an existing opcode and some new block level validation rules. @psztorc and I had an idea for this involving OP_TRUE(?) + identifying bytes to determine which outputs will have additional restrictions and which sidechain they belong to. The additional restriction could be that all outputs marked for a particular sidechain must be spent by another transaction created by the miner in the (same?) block with the destination again being the weird OP_TRUE script leaving us with a single output after the block is processed for that sidechain. I obviously haven’t really figured it out yet! It would be less overhead once figured out though, with no ECDSA operations anymore.

in bip-hashrate-escrows.mediawiki:426 in 0c186ed8e2 outdated

421+# "Return *all* Change to Account" -- Sum of inputs must equal the sum of outputs. No traditional tx fee is possible.
422+
423+Finally, don't forget that M6 inherits the requirement (common to both M5 and M6) that the CTIP be selected as an input, and that the CTIP then be updated. In this case, we know that the critical index will be zero, so the new CTIP will be ("this TxID" (NOT blinded), 0). The TxID is NOT blinded because blinding is only for accumulating ACKs.
424+
425+As a result of these requirements, every single withdrawal-attempt will fail, unless an entry has been added to D2 and "ACKed" a sufficient number of times.
426+

luke-jr commented at 1:36 pm on May 30, 2018:

The above seems to be specifying extension blocks, not sidechains, which is a whole can of worms, and should not be considered acceptable to be done by miners at will.

psztorc commented at 7:49 pm on May 30, 2018:

In this proposal, since the sidechains are so asymmetric, a sidechain is considered to be equivalent to an optional extension block.

And since they are optional, it makes no difference if anyone does them at will.

And since one purpose of these sidechains is “permissionless innovation” (ie, to provide a way for Bitcoin to recover from errors in the dev process / BIP process), it is actually imperative that there be some way of adding new sidechains even if the BIP process doesn’t want them.

luke-jr commented at 8:29 pm on May 30, 2018:

But if a miner doesn’t do a sidechain, won’t it be interpreted as a NACK on every withdrawal?

psztorc commented at 9:57 pm on May 30, 2018:

No, a sidechain can “abstain” and take no position on the withdrawals. In that case it is neither and ACK nor a NACK.

In practice, abstaining miners may also choose to rely on much…flimsier methods, like just checking in with someone who runs a sidechain node in real life, and asking them if everything is operating normally.

(In any well-designed sidechain, the withdrawal-IDs would be right in each sidechain header, or would else be very very easy to find. And there should only be 1 or 2 withdrawls there, per 3 months. And each of these should be a mere 32-bytes of information).

psztorc commented at 10:00 pm on May 30, 2018:

Let me add that if more than 50% of the hashpower abstains completely (refusing to ACK or NACK), then no withdrawals will ever succeed. That is a function of the parameter choices of 13,150 and 26,300. We could make 26,300 longer, I suppose.

In fact, perhaps a good tradeoff to your other point would be to make this value flexible. Ie, keep the 13,150 required ACK score fixed, but allow the withdrawal period to be even longer.

in bip-hashrate-escrows.mediawiki:432 in 0c186ed8e2 outdated

427+
428+
429+==Backward compatibility==
430+
431+
432+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 the UTXO in single, infrequent bursts. However, this phenomena doesn't affect them or the validity of the money that they receive.

luke-jr commented at 1:37 pm on May 30, 2018:

Extension blocks (see above) are not softforks.

psztorc commented at 7:53 pm on May 30, 2018:

These are optional extension blocks, and the withdrawals from them will not depend on what happens “in the x-block”. The withdrawals only depend on the ACK-ing process, all of which happens on the mainchain.

So they meet the definition of a soft fork. In fact they do so much more than the SegWit proposal did.

rex4539 commented at 2:39 pm on April 3, 2019:

this phenomena -> these phenomena

psztorc commented at 11:47 pm on April 4, 2019:

thanks!

in bip-hashrate-escrows/appendix-1.txt:1 in 0c186ed8e2 outdated

0@@ -0,0 +1,20 @@
1+

luke-jr commented at 1:37 pm on May 30, 2018:

Why isn’t this in the main BIP file?

psztorc commented at 7:51 pm on May 30, 2018:

When describing anything, there is always a tradeoff between thoroughness and brevity.

luke-jr commented at 6:26 am on March 29, 2019: member

I’m unsure what the status is of this one…

in bip-hashrate-escrows.mediawiki:308 in 0c186ed8e2 outdated

303+
304+==== M4 -- "ACK Withdrawal" ====
305+
306+==== Very Little Info, Probably Calculable in Advance ====
307+
308+M4 is exceptional (in comparison to the other M's) in a few ways. First, its content is not stored anywhere, only the *hash* of its *effect* is stored (in a leaf of a merkle tree who's root is inserted into a mainchain coinbase). M4 alters the contents of D2 -- the *contents* of D2 are consensus critical, but M4 (the process by which nodes reach a new valid D2) can be anything.

rex4539 commented at 2:37 pm on April 3, 2019:

who’s -> whose

psztorc commented at 11:45 pm on April 4, 2019:

thank you

in bip-hashrate-escrows.mediawiki:312 in 0c186ed8e2 outdated

307+
308+M4 is exceptional (in comparison to the other M's) in a few ways. First, its content is not stored anywhere, only the *hash* of its *effect* is stored (in a leaf of a merkle tree who's root is inserted into a mainchain coinbase). M4 alters the contents of D2 -- the *contents* of D2 are consensus critical, but M4 (the process by which nodes reach a new valid D2) can be anything.
309+
310+In fact, M4 can also be *nothing*. In other words, it may be optional. This is precisely because, from one block to the next, we have constrained D2 such that it is only allowed to change in a few ways. Therefore, the exhaustive set of "candidate D2s" can be precomputed by full nodes in advance.
311+
312+The following sections assume a maximum of one sucessful withdrawal per sidechain at a time (see [/bip-hashrate-escrows/appendix-1.txt appendix 1]).

rex4539 commented at 2:38 pm on April 3, 2019:

Typo: “sucessful”

psztorc commented at 11:46 pm on April 4, 2019:

thanks!

rex4539 changes_requested

psztorc commented at 11:49 pm on April 4, 2019: contributor

@luke-jr the BIP was a little outdated, and the code improved away from it. But now it is much shorter, more accurate, and clearer. And it has links to working ~basically stable code. So please consider it resubmitted.

in bip-hashrate-escrows/appendix-1.txt:10 in dd6a747cb3 outdated

 5+
 6+In other words, as WT^s are proposed, only one can make progress toward the finish line. As a result, a given side-to-main transfer will always take between 3 and 6 months.
 7+
 8+However, it might be best to use a maximum of two transfers at once.
 9+
10+If there were more simulataneous withdrawals, the worst-case transfer duration would improve.

rex4539 commented at 5:08 am on April 5, 2019:

Typo: “simulataneous”

psztorc commented at 5:03 pm on April 5, 2019:

thanks

in bip-hashrate-escrows/appendix-1.txt:16 in dd6a747cb3 outdated

11+
12+See image: bip-hashrate-escrows/two-groups.png?raw=true
13+
14+The worst-case withdrawal time obeys f(n)=3+(3/n) months, where n is the number of simultaneous withdrawals.
15+
16+N=2 is the most desirable choice for several reasons. First, it delievers the greatest marginal benefit (of 1.5 months). Later choices only deliver 0.5 and 0.25 marginal months.

rex4539 commented at 5:08 am on April 5, 2019:

Typo: “delievers”

psztorc commented at 5:03 pm on April 5, 2019:

thanks

in bip-hashrate-escrows.mediawiki:217 in dd6a747cb3 outdated

212+
213+From one block to the next, "ACKs" can only change as follows:
214+
215+* The ACK-counter of any withdrawal can only change by (-1,0,+1).
216+* Within a sidechain-group, upvoting one withdrawal ("+1") requires you to downvote all other withdrawals in that group. However, the minimum ACK-value is zero (and, therefore, downvotes cannot reduce it below zero).
217+* While only one withdrawal can be upvoted at once, they can all be unchangd at once ("abstain") and they can all be downvoted at once ("alarm").

rex4539 commented at 5:10 am on April 5, 2019:

Typo: “unchangd”

psztorc commented at 5:02 pm on April 5, 2019:

thanks

in bip-hashrate-escrows.mediawiki:219 in dd6a747cb3 outdated

214+
215+* The ACK-counter of any withdrawal can only change by (-1,0,+1).
216+* Within a sidechain-group, upvoting one withdrawal ("+1") requires you to downvote all other withdrawals in that group. However, the minimum ACK-value is zero (and, therefore, downvotes cannot reduce it below zero).
217+* While only one withdrawal can be upvoted at once, they can all be unchangd at once ("abstain") and they can all be downvoted at once ("alarm").
218+
219+One option for explict transmission of M4 is:

rex4539 commented at 5:11 am on April 5, 2019:

Typo: “explict”

psztorc commented at 5:03 pm on April 5, 2019:

thanks

in bip-hashrate-escrows.mediawiki:256 in dd6a747cb3 outdated

251+
252+We come, finally, to the critical matter: where users can take their money *out* of the escrow account, and return it to the "regular" UTXO set. As previously mentioned, this txn is one which (a) spends from a CTIP and (b) reduces the quantity of BTC in an account's CTIP. Most of the work has already been done by D1, M3, M4, and D2. Furthermore, existing Bitcoin tx-rules prevent the sidechain from ever withdrawing more money than has been placed into it.
253+
254+In each block, a withdrawal in D2 is considered "approved" if its "ACKs" value meets the threshold (13,150).
255+
256+Approved withdrawals give the green light to their respective "WT^". A "WT^" is 32-bytes which aspire to represent the withdrawing transtion (the txn that actually withdraws funds from the escrow). The two cannot match exactly, beacuse "WT^" is defined at onset, and the withdrawing TxID depends on the its CTIP input (which is constantly changing).

rex4539 commented at 5:11 am on April 5, 2019:

Typo: “transtion”

rex4539 commented at 5:12 am on April 5, 2019:

Typo: “beacuse”

psztorc commented at 5:03 pm on April 5, 2019:

thanks

rex4539 changes_requested

jtimon commented at 5:49 pm on April 5, 2019: contributor

I haven’t watched the video, but, ok, I guess…never too late to catch up! Still, with spv 2wp, all bitcoin miners can do is censor the pegouts, but they cannot keep the coins for themselves without providing an spv proof with work from the sidechain.

So I think the part of the BIP that contradicts this (ie “A Hashrate Escrow resembles a 2-of-3 multisig escrow, where the 3rd party (who will arbitrate any disputes) is a decentralized group of people: the dynamic-membership set of Bitcoin Miners”) should be corrected.

The video makes the case for the set of miners being the same. Ie “spv proof with work from the sidechain” would be the same as “dynamic-membership set of Bitcoin Miners”.

That assumption is not justified. That doesn’t need to be the case for spv 2wp, merged mining is not a requirement for spv 2wp.

So it is correct as-is.

Your other comments are just the same error repeated.

…

psztorc commented at 6:15 pm on April 5, 2019: contributor

That assumption is not justified. That doesn’t need to be the case for spv 2wp, merged mining is not a requirement for spv 2wp.

This BIP does not require MM and supports 2wp that are not MM. But I personally assume that MM will be the equilibrium behavior, and the BIP focuses on that.

And even though MM is not a literal requirement (for spv 2wp), in practice some kind of ongoing majority hashrate endorsement is required. Because 51% hashrate can filter out anything they dislike from the mainchain.

rex4539 approved

jtimon commented at 7:02 pm on April 5, 2019: contributor

Your claim that drivechains are equivalent in security to to spv sidechains is based (among other things), on the false assumption that the miners of the mainchain and the sidechain are going to be the same. You said it yourself here:

makes the case for the set of miners being the same. Ie “spv proof with work from the sidechain” would be the same as “dynamic-membership set of Bitcoin Miners”.

So it is correct as-is.

No, this is not correct, as is, or in any other way.

psztorc commented at 7:08 pm on April 5, 2019: contributor

@jtimon I still don’t see the problem. Why don’t you suggest a rewording?

jtimon commented at 8:37 pm on April 5, 2019: contributor

Not sure, I think I would reword many things… perhaps “the dynamic-membership set of Sidechain Miners” instead of “the dynamic-membership set of Bitcoin Miners”? Also, not saying anything along the lines of the security assumptions of spv sidechains being the same as drivechain’s security assumptions, since they are clearly not.

psztorc commented at 9:21 pm on April 5, 2019: contributor

@jtimon Well why don’t you get back to us when you are sure

jtimon commented at 0:08 am on April 6, 2019: contributor

Well, what I’m sure about is what you have is wrong. But since you don’t seem interested in addressing my feedback and you seem more interested in simply responding to it, don’t worry, I won’t give you any more of it.

psztorc commented at 6:38 am on July 24, 2019: contributor

@luke-jr What about this one?

(I hope it is obvious that Timon’s comments are ignorant troll nonsense. And from what I heard, since making the above comments he was fired from Blockstream for technical incompetence anyway.)

jtimon commented at 10:44 am on July 27, 2019: contributor

(I hope it is obvious that Timon’s comments are ignorant troll nonsense. And from what I heard, since making the above comments he was fired from Blockstream for technical incompetence anyway.)

I think the fact that you talk about me being trolling while you say this says much more about you than it says about me. I hope you get ad much more feedback on this flawed proposal as you deserve. That is, none. I hope bobody gives you any more feedback on this. Certainly I won’t. Have a nice day…

ysangkok commented at 7:26 pm on September 5, 2019: contributor

On the “files changed” tab, I see changes to statuses of BIPs 155, 156, 178 and 197. Why are these changes part of this PR?

CryptAxe commented at 7:38 pm on September 5, 2019: none

On the “files changed” tab, I see changes to statuses of BIPs 155, 156, 178 and 197. Why are these changes part of this PR?

The changes to README.mediawiki appear to just be differences between the point the BIP repo was forked and when this PR was opened.

luke-jr renamed this:
~~new bip for hashrate escrows~~
BIP 300: Hashrate Escrows (Consensus layer)
on Sep 19, 2019

luke-jr commented at 9:51 pm on September 19, 2019: member

There’s something very broken with this branch. Let me know when it’s fixed for merging…

edit and shorten slightly dd02ff4c07

typo 3201b23119

compress

We were able to dramatically shorten the BIP, by deleting superfluous explanations/justifications. Instead it just focuses on what the messages are.

99e57b086a

typos c6da99018d

spellcheck a9b0bc593a

clarify + specific M4 example ecc00805c2

add number 300 and update README c78766c360

psztorc commented at 5:37 pm on September 20, 2019: contributor

@luke-jr OK I rebased it – everything seems to be fully updated

BIP 300: Fix preamble 34f0fe5b2a

luke-jr merged this on Sep 20, 2019

luke-jr closed this on Sep 20, 2019

BIP 300: Hashrate Escrows (Consensus layer) #642