New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new bip for hashrate escrows #642

Open
wants to merge 11 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@psztorc

psztorc commented Feb 4, 2018

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

psztorc added some commits Feb 4, 2018

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

@luke-jr

This comment has been minimized.

Member

luke-jr commented Feb 6, 2018

This seems to have the wrong files...?

re-reverse the bips
this is what I originally intended, but I forked this branch at the wrong time
@psztorc

This comment has been minimized.

psztorc commented Feb 10, 2018

This seems to have the wrong files...?

It does, my mistake! Fixed now

@psztorc

This comment has been minimized.

psztorc commented Feb 10, 2018

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

@jtimon

This comment has been minimized.

Member

jtimon commented Feb 18, 2018

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

This comment has been minimized.

Member

jtimon commented Feb 18, 2018

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

This comment has been minimized.

psztorc commented Feb 18, 2018

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

This comment has been minimized.

psztorc commented Feb 18, 2018

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

This comment has been minimized.

Member

jtimon commented Feb 18, 2018

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 drivechain-project/bitcoin@948c29c in your branch is clearly not relevant to the implementation of this BIP.

@psztorc

This comment has been minimized.

psztorc commented Feb 18, 2018

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??? bitcoin/bitcoin@master...drivechain-project:mainchainBMM

@jtimon

This comment has been minimized.

Member

jtimon commented Feb 19, 2018

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

This comment has been minimized.

psztorc commented Apr 11, 2018

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

This comment has been minimized.

gusbjerpe commented Apr 11, 2018

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

@CryptAxe

This comment has been minimized.

CryptAxe commented Apr 28, 2018

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

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

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

Please drop the empty lines here

This comment has been minimized.

@psztorc
==Abstract==
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.

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

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

This comment has been minimized.

@psztorc

psztorc May 30, 2018

I don't really think so

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.
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).

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

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.

This comment has been minimized.

@psztorc

psztorc 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.

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

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.

This comment has been minimized.

@psztorc

psztorc 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.

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

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

This comment has been minimized.

@psztorc

psztorc 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.

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.
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").

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

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

This comment has been minimized.

@psztorc

psztorc 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.

| Escrow Name/Description
| 120
| string
| 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).

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

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

This comment has been minimized.

@psztorc

psztorc 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.

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.
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.

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

I don't think equating undesirable transactions to "aggression" makes sense here. It also seems out of place.

This comment has been minimized.

@psztorc

psztorc 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?

===== ISSUE: "Signing" BTC Txns =====
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.

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

If it doesn't do anything, it shouldn't exist at all...

This comment has been minimized.

@psztorc

psztorc May 30, 2018

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

This comment has been minimized.

@psztorc

psztorc May 30, 2018

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

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

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

This comment has been minimized.

@psztorc

psztorc 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.

This comment has been minimized.

@jtimon

jtimon May 31, 2018

Member

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.

This comment has been minimized.

@psztorc

psztorc Jun 2, 2018

Why don't you just use a new opcode

We will probably add this option

This comment has been minimized.

@CryptAxe

CryptAxe Jun 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.

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.
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.

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

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.

This comment has been minimized.

@psztorc

psztorc 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.

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

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

This comment has been minimized.

@psztorc

psztorc 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).

This comment has been minimized.

@psztorc

psztorc 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.

==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 the UTXO in single, infrequent bursts. However, this phenomena doesn't affect them or the validity of the money that they receive.

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

Extension blocks (see above) are not softforks.

This comment has been minimized.

@psztorc

psztorc 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.

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

This comment has been minimized.

@luke-jr

luke-jr May 30, 2018

Member

Why isn't this in the main BIP file?

This comment has been minimized.

@psztorc

psztorc May 30, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment