Good morning Bob,
> Note that this attack requires collaboration with the current UTXO owner. > Generally if there's some form of address/payment request, the current holder > is > trying to transfer the UXTO to some other (non-statechain) entity, and he > knows > the target of the transfer, and participates in the protocol to authorize it. > The current holder must obtain the target pubkey for the transfer out-of-band > with respect to the SE, or the SE can MITM that. > > It's a stated security assumption that the sender or receiver do not collude > with the SE. If either do, then your attack is generally possible and all bets > are off. So what you've described is simply the SE colluding with the > receiver. > The receiver will already receive the UTXO, so the receiver here is assisting > the SE in stealing his (the receiver's) funds, or the SE has done a MITM on > the > transfer. Various improvements including blind signing, a SE-federation, etc > are valuable to consider to mitigate this. But the SE must be prevented, one > way > or another, from "buying the UTXO". 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. There's already a user > key > involved, and the user has already acquiesced to the transfer. Acquiescing > with > two keys doesn't change anything. The point is not that acquiescing with two keys is possible. Instead, the point is that any past owner of the coin can collude with the statechain authority (who, in the new scheme, must be trusted to delete old keys), or anyone who manages to get backups of the statechain authority keys (such as by digging for backups in a landfill), in order to steal the onchain funds, regardless of who the current owner is, within the statechain. Thus an amount of trust must still be put in the statechain authority. So I think the security assumptions should be that: * The statechain authority really does delete keys and does not make backups. * No *past* or *current* owner of the coin colludes with the statechain authority. * I think saying merely "sender" is not sufficient to capture the actual security assumption here. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
