Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.
Coinswap has been a struggling goal for many years now. Consider that bitshares' dexbot just recently lost their funding. Please make your projects usable before you announce you are working on them, to keep your work safe from distraction or harm. On Sun, Sep 13, 2020, 7:11 PM Tom Trevethan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > We are designing an off-chain coin-swap protocol that will work with the > statechain implementation we are developing ( > https://github.com/commerceblock/mercury). The general idea is that coins > deposited with a statechain entity (statecoins) can be transacted > peer-to-peer off-chain in a way that the statechain entity (SCE) is > trusted, but the statecoins always remain in the custody of the owners. A > statecoin swapping service would enable owners to mix their coins with > other users, giving the same privacy benefits of on-chain CoinSwap > protocols, but by being off-chain statecoin swaps would be much faster and > cheaper. > > The swapping service (conductor) would not have custody of the statecoins > at any point. The aim is to have the conductor coordinate the swap amongst > a group of statecoins (i.e. determine the which statecoin should be sent to > which new random owner in the group) without being able to learn the link > between owners and their provided addresses. To do this we will use a blind > signature scheme in a similar way to the zerolink protocol. > > Here is a high-level description of how this blinding can operate - with > the aim that the conductor does learn how the ownership of individual coins > has changed. > For example, imagine 4 individuals (A,B,C and D) who own equal value > statecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap > ownership privately, trusting the conductor/SCE to enforce atomicity. In > other words, the conductor will randomly assign each statecoin to one of > the owners (the mix), but will not be able to gain knowledge of that > assignment. > 1. A,B,C and D signal their participation by signing the swap_token (which > has details of the swap) with the proof-key of their input coin. (A > statecoin address is formed of a concatenation of the proof key and backup > address). > 2. Each of A,B,C and D then generate a new statecoin address (where they > what to receive the swapped coin), which they blind (encrypt) and sign with > the proof key of their input coin: add1, add2, add3 and add4 and send to > the conductor. > 3. The conductor authenticates each signature and then signs each payload > (i.e. the blinded destination addresses) with a blinded signature scheme > and returns these signatures to A,B,C and D. > 4. Each of A,B,C and D then reconnects over TOR with a new identity. > 5. Each of A,B,C and D then send their unblinded destination address with > the conductor signature to the conductor (the conductor now knows that > these 4 addresses belong to A,B,C and D, but not which ones map to each > input.) > 6. The conductor randomly assigns each address to one of utxo1, utxo2, > utxo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2) > and requests each participant to initiate the transfer to the given > address. > 7. Each participant then finalises each transfer - if any transfer fails > (due to a participant disappearing or acting maliciously) then all > transfers are reverted - here atomicity is guaranteed by the SCE. > > The interesting problem we have with this protocol is how to assign blame > in the case that one or more participants in the swap causes it to fail, so > that the corresponding statecoins can be penalized (prevented from > participating in further swaps for some timeout) to make any DoS attack > costly. In the case of an on-chain coinjoin, this is easy: whoever didn't > sign their input is to blame. However, in our statechain system a statecoin > transfer is a two stage process (to update the private key shares): the > sender performs an operation with the SCE (transfer_sender) and then sends > an encrypted value to the receiver, who then performs the second operation > with the SCE (transfer_reciever) which updates the UTXO private key shares > for the new owner ( > https://github.com/commerceblock/mercury/blob/master/doc/statechains.md > for more details). If the second stage fails (i.e. the values used for the > key update protocol are wrong) this could be due to either the sender > sending a bad/manipulated value to the receiver, or the receiver using bad > values in the second operation with the SCE. Essentially, either the sender > or the receiver can cause the transfer to fail, and it is not possible to > determine which one is malicious without revealing the encrypted value sent > between the sender and receiver (which must be kept secret from the SCE). > > All this means that if a multi-party coinswap fails, we will know which > statecoin was involved in the failure, but we cannot determine whether the > sender or receiver of that
Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring
I think this is a worthy idea as the funding outpoint of any off-chain protocols is an invariant known by participants. Thus by sponsoring an outpoint you're requiring from network mempools to increase the feerate of the package locally known without assuming about the concrete state as any of them confirming is moving protocol forward. That said, a malicious counterparty can still broadcast a heavy-weighted transaction such as an honest party, devoid of knowledge of this weight, won't attach a sponsor with a fee high enough to timely confirm the sponsoree. This counterparty capability is a function of package malleability allowed by the off-chain protocol. Thus an honest party has to overshoot your bump as a default setting. Now this is a new concern as such a mechanism can be used as a fee-burning one by your counterparty. I believe we want a fee-burning equilibrium for any pinning solution, Mallet shouldn't force Alice to overpay in fee more than Mallet is ready to feerate-bid in network mempools. > I don't think package relay based only on feerate solves RBF transaction > pinning (and maybe also doesn't solve ancestor/dependent limit pinning). Yes I agree with this. There are some really nasty cases of pinning where an adversary with knowledge of the tx-relay topology can block your compelling feerate bids (sponsors/package relay/anchor whatever) from propagating by leveraging conflicts and RBF logic. Outbound tx-relay peers rotation which makes the tx-relay topology harder to observe could help. Antoine Le lun. 21 sept. 2020 à 12:27, Jeremy a écrit : > Responses Inline: > > Would it make sense that, instead of sponsor vectors >> pointing to txids, they point to input outpoints? E.g.: >> >> 1. Alice and Bob open a channel with funding transaction 0123...cdef, >>output 0. >> >> 2. After a bunch of state updates, Alice unilaterally broadcasts a >>commitment transaction, which has a minimal fee. >> >> 3. Bob doesn't immediately care whether or not Alice tried to close the >>channel in the latest state---he just wants the commitment >>transaction confirmed so that he either gets his money directly or he >>can send any necessary penalty transactions. So Bob broadcasts a >>sponsor transaction with a vector of 0123...cdef:0 >> >> 4. Miners can include that sponsor transaction in any block that has a >>transaction with an input of 0123...cdef:0. Otherwise the sponsor >>transaction is consensus invalid. >> >> (Note: alternatively, sponsor vectors could point to either txids OR >> input outpoints. This complicates the serialization of the vector but >> seems otherwise fine to me.) >> > > *This seems like a fine suggestion and I think addresses Antoine's issue.* > > > *I think there are likely some cases where you do want TXID and not Output > (e.g., if you * > > *are sponsoring a payment to your locktime'd cold storage wallet (no CPFP) > from an untrusted third party (no RBF), they can grift you into paying for > an unrelated payment). This isn't a concern when the root utxo is multisig > & you are a participant.* > > *The serialization to support both, while slightly more complicated, can > be done in a manner that permits future extensibility as well if there are > other modes people require.* > > > >> >> > If we want to solve the hard cases of pinning, I still think mempool >> > acceptance of a whole package only on the merits of feerate is the >> easiest >> > solution to reason on. >> >> I don't think package relay based only on feerate solves RBF transaction >> pinning (and maybe also doesn't solve ancestor/dependent limit pinning). >> Though, certainly, package relay has the major advantage over this >> proposal (IMO) in that it doesn't require any consensus changes. >> Package relay is also very nice for fixing other protocol rough edges >> that are needed anyway. >> >> -Dave >> > > *I think it's important to keep in mind this is not a rival to package > relay; I think you also want package relay in addition to this, as they > solve different but related problems.* > > > *Where you might be able to simplify package relay with sponsors is by > doing a sponsor-only package relay, which is always limited to 2 > transactions, 1 sponsor, 1 sponsoree. This would not have some of the > challenges with arbitrary-package package-relay, and would (at least from a > ux perspective) allow users to successfully get parents with insufficient > fee into the mempool.* > > > > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.
Good morning Tom, > Hi ZmnSCPxj, > > > I think the entire point of non-custodiality ***is*** trust minimization. > > There are also legal and regulatory implications. It is much easier for a > service to operate without requiring its users to be KYCed if it is > non-custodial and funds cannot be frozen/seized. Complying with the letter of the law without complying to its spirit seems rather hair-splitting to me. Ideally, a law regarding any financial mechanisms would judge based on how much control the purported owner has over the actual coin and what risks it would entail for them, and protect citizens against risk of damage to their finances, not focus on whether storage is "custodial" or not. So I still suggest that, for purposes of technical discussion, we should avoid the term "custodial" and instead consider technical risks. > > > The main objection against custodiality is that someone else can prevent > > you from spending the coin. > > If I have to tr\*st the SE to not steal the funds, is it *really* > > non-custodial, when after a swap, a corrupted SE can, in collusion with > > other participants, take control of the coin and prevent me from spending > > it as I wish? > > I would argue that it is non-custodial if the SE performs the protocol as > specified (i.e. securely deleting expired key shares). The SE can run in a virtual environment that monitors deletion events and records them. Such a virtual environment could be set up by a rootkit that has been installed on the SE hardware. Thus, even if the SE is honest, corruption of the hardware it is running on can allow recovery of old privkeys and violation of the tr\*st assumption. Compare this to, for example, TumbleBit or Wasabi. In those cases, even if the service providing the mixing is corrupted by a rootkit on the hardware running the honest service software in a virtual environment and monitoring all its internal state and communications, they cannot lead to loss of funds even with cooperation of previous participants. They can at most be forced into denial-of-service, but not outright theft of coins. Thus, I believe this solution is inferior to these older solutions, at least in terms of financial security. I admit the new solution is superior blockspace-wise, if you consider multiple mixing rounds. However, multiple mixing rounds under this solution have increased exposure to the risk of theft noted above, and thus it would be better, risk-wise, to immediately withdraw after every round, and potentially seek other SEs (to reduce risks arising from a particular SE being corrupted), thus obviating the blockspace savings. The above remain true regardless of what definition of "custodial" you have. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.
Hi ZmnSCPxj, > I think the entire point of non-custodiality ***is*** trust minimization. There are also legal and regulatory implications. It is much easier for a service to operate without requiring its users to be KYCed if it is non-custodial and funds cannot be frozen/seized. > The main objection against custodiality is that someone else can prevent you from spending the coin. > If I have to tr\*st the SE to not steal the funds, is it *really* non-custodial, when after a swap, a corrupted SE can, in collusion with other participants, take control of the coin and prevent me from spending it as I wish? I would argue that it is non-custodial if the SE performs the protocol as specified (i.e. securely deleting expired key shares). If users do trust that it is doing this, then they don't need to worry about the SE being shut down or even hacked - assuming the SE has deleted *old* keys (in the past) then there is no way the current owner can have their funds stolen - this is a sort of 'forward security' that makes the protocol much more secure than a fully custodial one which stores the full key(s) at all times (and I would argue therefore has higher trust requirements). The SE cannot decide or be compelled to seize any specific coin without conspiring in advance to: 1. Keep the expired key shares and 2. Collude with a previous owner of that coin. We have designed a scheme to ensure secure deletion of shares using HSMs, and are exploring the possibility of using remote attestation to prove key share deletion on the HSM to users. These are different properties compared to a federated sidechain, which while lowering trust requirements with an m-of-n peg, remains custodial (if the m-of-n collude at any point they can steal ALL the money, and if (n - m + 1) are shut down/disappear then the money is gone forever). However, in the same way as a federated sidechain, users retain a verifiable proof of their unique ownership of a coin and must sign a peg-out transaction to withdraw on-chain. The publication of this peg-out transaction is proof that the current owner authenticated the on-chain spend, and so any absence of this is a signal that the SE should not be trusted. Cheers, Tom On Mon, Sep 21, 2020 at 2:14 AM ZmnSCPxj wrote: > Good morning Tom, > > > Hi ZmnSCPxj, > > > > Thanks for the reply. > > > > > Okay, I suppose this is much too high-level a view, and I have no idea > what you mean by "statecoin" exactly. > > > > Sorry, most of the protocol details are in the links, but terminology > should be made clearer. A "statecoin" is a UTXO that is a 2-of-2 between > the owner and SE (the tr*sted signing server) i.e. can be transferred > off-chain. > > > > Also, should have been clear that `addr1` is the 'statecoin address' > which is different from the on-chain address (the shared public key the > bitcoin is paid to). The on-chain address does not change, whereas > the 'statecoin address' changes with each new owner and is used to > authenticate owners to the SE and act as proof of ownership on > the statechain - it is not related to the onchain address/pubkey and > controlled by the owner only. > > > > > So it seems to me that this requires tr\*st that the coordinator is > not going to collude with other participants. > > > > This is correct. The SE also must be trusted to not actively defraud > users. The main advantage of this scheme is that assuming the SE can be > trusted, it is strictly non-custodial. > > > > > This is strictly worse than say Wasabi, where the coordinator > colluding with other participants only allows the coordinator to break > privacy, not outright steal funds. > > > It seems to me that the trust-minimized CoinSwap plan by belcher_ is > superior to this, with reduced scope for theft. > > > > This is true if the overriding aim is trust minimisation, but not if the > aim is speed and cost while staying non-custodial. Off-chain SE > transactions are near instant and orders of magnitude cheaper than > on-chain. Probably best thought of as a non-custodial centralised mixer. > > > I think the entire point of non-custodiality ***is*** trust minimization. > > The main objection against custodiality is that someone else can prevent > you from spending the coin. > If I have to tr\*st the SE to not steal the funds, is it *really* > non-custodial, when after a swap, a corrupted SE can, in collusion with > other participants, take control of the coin and prevent me from spending > it as I wish? > > So I think touting "non-custodial" is relatively pointless if tr\*st is > not minimized. > > (I am aware there is an update mechanism, either Decker-Russell-Osuntokun > or Decker-Wattenhofer, that is anchored off he onchain transaction output, > but anyone who can recover the raw keys for signing the funding transaction > output --- such as a previous participant and a corrupt SE --- can very > easily bypass the mechanism.) > > For example, in my previous description of [implementing investment >
Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring
Responses Inline: Would it make sense that, instead of sponsor vectors > pointing to txids, they point to input outpoints? E.g.: > > 1. Alice and Bob open a channel with funding transaction 0123...cdef, >output 0. > > 2. After a bunch of state updates, Alice unilaterally broadcasts a >commitment transaction, which has a minimal fee. > > 3. Bob doesn't immediately care whether or not Alice tried to close the >channel in the latest state---he just wants the commitment >transaction confirmed so that he either gets his money directly or he >can send any necessary penalty transactions. So Bob broadcasts a >sponsor transaction with a vector of 0123...cdef:0 > > 4. Miners can include that sponsor transaction in any block that has a >transaction with an input of 0123...cdef:0. Otherwise the sponsor >transaction is consensus invalid. > > (Note: alternatively, sponsor vectors could point to either txids OR > input outpoints. This complicates the serialization of the vector but > seems otherwise fine to me.) > *This seems like a fine suggestion and I think addresses Antoine's issue.* *I think there are likely some cases where you do want TXID and not Output (e.g., if you * *are sponsoring a payment to your locktime'd cold storage wallet (no CPFP) from an untrusted third party (no RBF), they can grift you into paying for an unrelated payment). This isn't a concern when the root utxo is multisig & you are a participant.* *The serialization to support both, while slightly more complicated, can be done in a manner that permits future extensibility as well if there are other modes people require.* > > > If we want to solve the hard cases of pinning, I still think mempool > > acceptance of a whole package only on the merits of feerate is the > easiest > > solution to reason on. > > I don't think package relay based only on feerate solves RBF transaction > pinning (and maybe also doesn't solve ancestor/dependent limit pinning). > Though, certainly, package relay has the major advantage over this > proposal (IMO) in that it doesn't require any consensus changes. > Package relay is also very nice for fixing other protocol rough edges > that are needed anyway. > > -Dave > *I think it's important to keep in mind this is not a rival to package relay; I think you also want package relay in addition to this, as they solve different but related problems.* *Where you might be able to simplify package relay with sponsors is by doing a sponsor-only package relay, which is always limited to 2 transactions, 1 sponsor, 1 sponsoree. This would not have some of the challenges with arbitrary-package package-relay, and would (at least from a ux perspective) allow users to successfully get parents with insufficient fee into the mempool.* ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring
On Sun, Sep 20, 2020 at 07:10:23PM -0400, Antoine Riard via bitcoin-dev wrote: > As you mentioned, if the goal of the sponsor mechanism is to let any party > drive a state N's first tx to completion, you still have the issue of > concurrent states being pinned and thus non-observable for sponsoring by an > honest party. > > E.g, Bob can broadcast a thousand of revoked LN states and pin them with > low-feerate sponsors such as these malicious packages absolute fee are > higher than the honest state N. Alice can't fee-sponsor > them as we can assume she hasn't a global view of network mempools. Due to > the proposed policy rule "The Sponsor Vector's entry must be present in the > mempool", Alice's sponsors won't propagate. Would it make sense that, instead of sponsor vectors pointing to txids, they point to input outpoints? E.g.: 1. Alice and Bob open a channel with funding transaction 0123...cdef, output 0. 2. After a bunch of state updates, Alice unilaterally broadcasts a commitment transaction, which has a minimal fee. 3. Bob doesn't immediately care whether or not Alice tried to close the channel in the latest state---he just wants the commitment transaction confirmed so that he either gets his money directly or he can send any necessary penalty transactions. So Bob broadcasts a sponsor transaction with a vector of 0123...cdef:0 4. Miners can include that sponsor transaction in any block that has a transaction with an input of 0123...cdef:0. Otherwise the sponsor transaction is consensus invalid. (Note: alternatively, sponsor vectors could point to either txids OR input outpoints. This complicates the serialization of the vector but seems otherwise fine to me.) > If we want to solve the hard cases of pinning, I still think mempool > acceptance of a whole package only on the merits of feerate is the easiest > solution to reason on. I don't think package relay based only on feerate solves RBF transaction pinning (and maybe also doesn't solve ancestor/dependent limit pinning). Though, certainly, package relay has the major advantage over this proposal (IMO) in that it doesn't require any consensus changes. Package relay is also very nice for fixing other protocol rough edges that are needed anyway. -Dave signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
