Statechain implementations [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2020-05-07T14:54:53+00:00


Summary:

CommerceBlock is actively working on implementing their statechain using KZen's 2P ECDSA protocol and Rust. They plan to use a sparse Merkle tree attested to a Mainstay slot for the proof-of-publication/proof-of-ownership. The statechain will allow the current owner to prove if there has been theft from them.Nadav has concerns about potential scams by the Statechain Entity (SE) where they buy the UTXO, transfer it, and then steal it. This issue can be solved by adding a new user key to the protocol that would make it traceable/provable. For open-ended UTXOs, an invalidation tree relative locktime backup mechanism will likely be used. Tom Trevethan clarifies that his patent application is different from the ideas currently being worked on. On the bitcoin-dev mailing list, a proposal was made for an exchange platform that operates using off-chain transactions and does not require on-chain transactions. This platform would be capable of generating multiple transactions, which can be recorded on a blockchain under different circumstances. The proposal suggests that some off-chain transactions should still be valid for recording on the blockchain in the event of a catastrophic failure of the exchange, such as the permanent shutdown of the exchange or loss of key shares.A two-party elliptic curve digital signature algorithm script would be used to perform functions of a two-party elliptic curve digital signature algorithm. The proposal also notes that a malicious actor would have to collude with a previous owner of the funds to recreate the full key making it difficult for them to compromise the exchange platform. Dave proposed this idea, and Bob McElrath responded to it by quoting H.L. Mencken's famous statement that "For every complex problem, there is a solution that is simple, neat, and wrong. "In an email chain on the Bitcoin development mailing list, several proposals were discussed to increase platform security. One proposal involved using two-party elliptic curve digital signature algorithms to make it difficult for malicious actors to compromise the exchange platform. The processor would be configured to perform these functions, which would limit opportunities for attackers to compromise the platform. Bob McElrath noted that this proposed solution may not be effective in preventing all attacks and ended his email with a quote by H.L. Mencken: "For every complex problem, there is a solution that is simple, neat, and wrong. "Another proposal discussed was the statechain protocol. Nadav Kohen raised concerns over the possibility of a malicious Statechain Entity (SE) stealing a user's UTXO by collaborating with or being a previous owner. Tom suggested using proof-of-publication as a way to enable the current owner to prove ownership and prevent double-spending, as well as provide evidence of fraud on the part of the SE. Bob McElrath suggested using single use seals to track ownership history and prevent the SE from buying the UTXO, noting that the attack would require collusion with the current UTXO owner. Nadav proposed adding a new user key to the protocol, which would be required for a transfer to be valid on the statechain.Tom provided a more detailed document specifying the proposed protocol, including improvements to the transfer mechanism and an explanation of how this can be used to transfer/novate positions in DLCs. He also addressed concerns about nChain Holdings' patent application related to secure off-chain blockchain transactions.The discussion is about the security assumptions of statechains. It is mentioned that an attack on statechains requires collaboration with the current UTXO owner, who is transferring the UXTO to a non-statechain entity and knows the target of the transfer, obtaining the target pubkey for the transfer out-of-band with respect to the SE or the SE can MITM that. The security assumption is that the sender or receiver does not collude with the SE. If either does, then the attack is generally possible.The SE cannot be allowed to be both operator of the SE and a customer of it as this clearly violates the no-receiver collusion principle. Adding a new user key doesn't change the situation as the user has already acquiesced to the transfer. Any past owner of the coin can collude with the statechain authority in order to steal the onchain funds regardless of who the current owner is within the statechain. So, trust must still be put in the statechain authority. The security assumptions should be that the statechain authority really does delete keys and does not make backups, and no past or current owner of the coin colludes with the statechain authority.The Statechain concept proposes non-custodial off-chain Bitcoin transfer. The current holder of UTXO must obtain the target pubkey for the transfer out-of-band with respect to the SE, or the SE can MITM that. Nadav Kohen raised concerns about an untraceable scam by the Statechain Entity (SE).


Updated on: 2023-08-02T01:58:10.360456+00:00