I am fed back the concern that the circuitry of the WE may become inconsistent during a hard fork, making decryption impossible, but this is solvable and something we did not mention in this paper for simplicity.
In a simple construction, we consider the block header as a target for signature by PoS validators, but what we really want the circuit to validate is the irreversible inclusion of the states into the Merkle Root. The circuit should be fine as long as this is satisfied.
If we hard fork to a Layer1 configuration that does not have irreversible inclusion, that would put Layer1 in danger.
Thank you so much for the feedback with the information on the many protocols.
I think the priority is answering this part.
The difference is simply here:
If the threshold is T of N of the multi-sig,
Safety Byzantine fault tolerance of multi-sig with witness encryption: N-1 / N (99% tolerance)
Safety Byzantine fault tolerance of multi-sig with Shnorr threshold signature: T / N
Liveness Byzantine fault tolerance of multi-sig with witness encryption: N / N (No one can stop it)
Liveness Byzantine fault tolerance of multi-sig with Shnorr threshold signature: N-T / N (If N-T+1 nodes go offline, the system stops)
The trade-off of Safety(Security) and Liveness shifts to a better way.
So I can say this part stronger, “There’re no key holders, there’re cipher text holders.”
DFINITY’s threshold and its chain-key technology are quite smart but they are still relying on the online/liveness assumption of the validator in the subnet.
And about here,
The deposit addresses are one-time-use and with fixed amounts, since once the secret key is revealed by the decryption of WE, the decryptor can take everything from this private key after that.
There’s no split of UTXOs in this system.
To prevent the collision during the time before a several blocks confirmation, the deposit address needs to be booked by the depositor.
The generators are different from depositors, and this fact is misleading as this system relies on the liveness/online assumption of somebody. This system is independent of generators by the MPC setup including multi-sig. This setup has features similar to the Power of Tau ceremony of zkSNARKs.
I’m looking forward to having your feedback again.
Very interesting proposal, I had been looking forward to promising applications of Witness Encryption and this looks like it! I have many questions but let’s start with three:
1/ Is it correct that in your proposed scheme, the entire set of key pairs for deposit addresses is generated in an initial trusted setup, such that when we run out of addresses, another trusted ceremony would need to take place?
2/ Are you suggesting to store the ciphertexts in an on-chain contract? I imagine this would be a mapping to keep track of which ciphertexts have been decrypted by users who completed a withdrawal request.
3/ You say that the proof of inclusion can be verified by zkp circuits ifor Ethereum PoS too, but how exactly would you go about this without your proof program running a node that connects to the network? For PoW we can just verify that the cumulative proof of work of the series of block header (of which one contains the event log) is sufficiently high with minimal security tradeoffs, but on PoS you need to verify that you have the correct genesis state, and that the majority of signers that signed a block are indeed mainnet signers, and not signers of some other locally spawned fork
Brilliant idea overall, looking forward to reading more about this!
Thank you for the reading material :). I checked them through and I think I understand this better now. I think you need to be able to formulate Ethereum light client as a exact cover problem, which then reveals the private key of the bitcoin deposit. In PoW version you make the client just verify the pow and that it contains the right transactions (the deposit and the wbtc burn). In PoS you do the same but with validator signatures.
This made me to start to think how to attack this system, and the clear way to attack this is that when someone makes a btc deposit and mints the wbtc, you fork the Ethereum chain and start mining. Let’s assume we require 10 eth blocks worth of PoW in the proof. This would mean that once a deposit is made, attacker starts to mine on PRIVATE fork of the Ethereum starting from the deposit block. Once the attacker has been able to mine 10 blocks, they can produce the proof and steal the money. This fork is never published, there’s no direct competition. The only competition is that someone could withdraw the money using the purposed way.
To perform this attack, the miner needs to be able to produce 10 blocks worth of work. This cost should be higher than what the btc deposit is worth, for the system to be economically to secure by game theory. Ofcourse a suicidal whale could burn more money to steal the btc.
However, this attack gets worse, as the attacker can steal ALL the deposits with the same 10 proof of work blocks… To combat this I guess one could make the withdrawal process work in a way that you can only withdraw one deposit at once and then you need to wait some amount of time until a new withdrawal can be started. This ensures that each robbery would require the same 10 pow blocks. This would hinder the usability of the protocol.
Do you happen to have a discord server or similar to chat more about this topic? It would be interesting to collaborate!
Yes, we need it when we are short of deposit addresses.
Yes, on-chain or on a data-shard is the best way. Anyway, we need put data related to the ciphertexts to the input of zkp circuits which are proving the relationship between deposit addresses and ciphertexts. Without this, a depositor can put bitcoin into a faked deposit address. This circuit needs to guarantee that withdrawers can decrypt the ciphertexts when they burn Wrapped BTC, as described in this part.
Then, about this.
This is prevented like this way. This is not my idea but Barry’s idea.
First of all, the block signers of the faked offchain blockchain can be slashed and punished when only one honest person publishes it, among the colluded signers. This is the slash mechanism of Ethereum against the double votes to the fork. But when the colluded signers use MPC to eliminate the honest person, this security collapses. Then the signs or the hint/index of the signs should be published on Bitcoin blockchain. The OP_RETURN space is rather small, so some kind of an index to search this sign data is better to be written in OP_RETURN. Finally, the colluded signers cannot generate faked chains out of the network secretly.
I think this is exactly what we intended to prevent with this mechanism.
Is this answering your question?
This is the cost comparison between the mega slash event of 1/3 of PoS validators and unlocking all of the Wrapped BTC in this system in the worst case, and there’s no guarantee to succeed this attack while the mega slash will certainly happen.
What progress has been made since this post was published over a year ago, and
is the prototype described above available publicly?
In the meantime, the current prototype requires about 20 minutes to encrypt a message using a tiny problem. Therefore, we need to develop various speedup methods to implement a real-world Wrapped Bitcoin.
I made sure that “KanaPalladium” was not my co-author more than one year ago. Sorry to be late for reporting this.
My co-author, whose name was encrypted, said he had no account named “KanaPalladium.” And his name is not “Hiro.”
The person who uses the account knows me I guess, but please don’t receive any invitation from him just in case. Ignore the account if he talks about “investment to WE project.”
Encrypting the author’s name was a mistake. I highly recommend people not to try it.
Basically, no update, and just waiting for new WEs. But signature-based WE (https://fc23.ifca.ai/preproceedings/189.pdf) can be useful enough to update this architecture.
ADP can remain the best unless we have the multi-pairing.
The weakness of ADP is that one gate increases the length of cipher-text (memory consumption) 4x.
So, the direction is to make it with fewer constraints or to update WE to avoid ADP.
When using Witness Encryption (WE) for a Bitcoin bridge, there’s potential for the most efficient construction to be a Drivechain without the need for BIP300. If WE is efficient, a Drivechain can be built without the BIP300 soft fork, and with Drivechain in place, a trustless Bitcoin bridge becomes feasible.
To start, Drivechain (BIP300+Blind Merge Mining) can create a trustless Bitcoin Bridge. Concerning the unlocking of bitcoin through the hashrate escrow, a vote is taken based on hash power using a specific oracle. This oracle is set up to verify BTC burns that are wrapped by Ethereum’s stateless client.
The essence of this efficiency is that instead of incorporating the Burn’s Proof into a circuit as in the original plan with Witness Encryption (WE), miners with incentives will simply verify it. This means that the proof of this Burn and the Ethereum blockchain itself can be entirely removed from WE.
In constructing a Drivechain using WE, the method to execute hashrate escrow is using WE to unlock private keys instead of Bitcoin’s new opcode. The method to make this private key a 1/N security remains the same as the original proposal of this page. Essentially, it just involves integrating the difficulty adjustment, accumulated hash power value, hash calculation of block verification, and signature by the bundle’s destination into the circuit. This is far more efficient than the original plan which verified the entire Ethereum chain with a WE circuit.
Beyond the construction of WE, another challenge is whether the developed Drivechain will be sufficiently recognized by miners, and if a mistaken bundle is created, whether a soft fork will truly occur. There’s an inherent incentive on this matter. If miners act rationally, it will inherit the security of Bitcoin’s Layer1.
The idea of Drivechain has many discussions of its security influence on the Bitcoin protocol. So what you said makes some sense. What I refer to the trustless bridge discussion is not about whether or not each is a good idea. At least, this post (and the comment) is talking about the theoretical facts.
I have a little question. If someone forked both Ethereum&Bitcoin privately, s/he can unlock BTC without being slashed, so the security depends on the cost comparison between min(slash, BTC-fork) and unlocking all of the wrapped BTC?
Hi, correct me if I am wrong. Assuming the below condition:
Alice deposits 1 BTC to a deposit address generated by the generators and gets the ciphertext CT, and then mints 1 WBTC on the Ethereum chain.
The current Ethereum PoS network is maintained by a group of validators, say it’s group A. And a group named B, is a 2/3 subset of the group A. Say after a year, the group B validators exited the PoS network and withdraw their stake. Then they forked the chain from the checkpoint one year before, thus they wont get slashed even they publish the headers in OP_RETURNs, while they can still burn 1 WBTC to the contract to forge a witness to satisfy the circuit, thus recover the private key with Alice’s ciphertext CT. Does this assumption hold? This a common case for a PoS network according to my understanding.
BTW, is there an implemented PoC version of this brilliant idea? Published somewhere to check? or A plan to implement it?
The ciphertexts get generated when the deposit address is generated. So it already exists before he/she deposits BTC there.
If the BLS signature on a forked chain is published in OP_RETURN, they get slashed.
And even trying that is dangerous for them since only one honest node can reveal that to make them slashed.
It was mentioned in the Octopus Contracts post that
“This mechanism primarily enhances the performance of the previous research
result, Trustless Bitcoin Bridge with Witness Encryption (TBBWE) [19], to a
practical level.”
Can I ask how “impractical” is the performance of this design? Is it wait time during withdrawal, computational gas cost, or something else?
I’ve forgotten to share this.
The recent hot topic regarding making a trustless bitcoin bridge is BitVM.
Seems you can unlock bitcoin with ZKP.
I’m not 100% sure it works for the bridge, but I truly believe that it’s worth exploring.
