Hi,
An quick update on progress with our statechain implementation which we are
pressing ahead with - we have started work on a version in Rust (
https://github.com/commerceblock/mercury) that is based on the 2P ECDSA
gotham-city wallet from KZen (https://github.com/KZen-networks/gotham-city),
Hi Bob and Nadav,
There seems to be no way to prevent a malicious SE from stealing an
output from the current owner by either colluding with (or being) a
previous owner. But with a proof-of-publication (i.e. the statechain) it is
possible for the current owner to have a proof that the SE has
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,
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
Hey all,
So my main concern with the proposal as written is that the Statechain
Entity (SE) can untraceably scam its users with the following attack:
1) Buy the utxo (have it transferred to a key it knows), this first step
can be skipped if the utxo was created by the SE.
2) Transfer the UTXO to
Thanks for all of the input and comments - I do now think that the
decrementing nSequence relative locktime backup system with kick-off
transaction is the way to go, including a fee penalty via CPFP to
disincentivise DoS, as suggested.
I have started a more detailed document specifying the
Hi David,
Just for clarity, I left nChain over 2 years ago (having worked there since
2016). While there, I (along with other researchers) were given free rein
to work on any ideas we wanted to. I had been interested in the scaling of
Bitcoin off-chain, and this was one of several things I spent
On Wed, Mar 25, 2020 at 01:52:10PM +, Tom Trevethan via bitcoin-dev wrote:
> Hi all,
>
> We are starting to work on an implementation of the statechains concept (
> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),
>
> [...]
> There are two
Good morning Ruben,
> Hi ZmnSCPxj,
>
> > the current owner can ask the statechain entity to sign an alternative to
> > the first stage, with 0 relative locktime
>
> Unless I am misunderstanding something, this seems to run into the problem
> that the original first stage transaction is already
Hi ZmnSCPxj,
the current owner can ask the statechain entity to sign an alternative to
> the first stage, with 0 relative locktime
Unless I am misunderstanding something, this seems to run into the problem
that the original first stage transaction is already out there (and its
relative timelock
Hi Bob,
Looks like we're largely thinking along the same lines.
It's unlikely that a party sending a UTXO to another party will have a UTXO
> of exactly the right size that's needed
My original proposal uses adaptor signatures to ensure swapping UTXOs is
atomic. All parties choose a secret,
Good morning Bob,
> Big picture, it seems to me this idea is workable and very interesting. I see
> three likely enhancements that will be necessary or desirable:
> 1. Atomic swap of multiple UTXOs, and binary decomposition of value in lots
> 2. Key exchange ("addresses") to facilitate a secure
Good morning Ruben,
> >The broadcasting of the kickoff simply means that the first stage cannot be
> >easily changed
>
> I see what you're saying. Yeah, it does ruin the stages. If the kickoff tx
> hits the chain, you'd probably just want to "refresh" the UTXO by agreeing
> with the
Big picture, it seems to me this idea is workable and very interesting. I see
three likely enhancements that will be necessary or desirable:
1. Atomic swap of multiple UTXOs, and binary decomposition of value in lots
2. Key exchange ("addresses") to facilitate a secure comms path from
Hi ZmnSCPxj,
I appreciate the input.
>Any standardness issue can be fixed by embedding it in a P2WSH / P2SH, you
can use an `OP_TRUE` `redeemScript`, for instance.
Good point. I guess the conversation I recall reading must have been about
avoiding p2sh in order to lower the tx size.
>broadcast
Good morning Ruben,
> Hey Christian,
>
> Thanks for chiming in :)
>
> >It might be worth adopting the late fee binding we have in eltoo
>
> That is where my thinking originally went as well, but then I remembered that
> this alters the txid, causing the settlement tx to become invalid. What I am
Hey Christian,
Thanks for chiming in :)
>It might be worth adopting the late fee binding we have in eltoo
That is where my thinking originally went as well, but then I remembered
that this alters the txid, causing the settlement tx to become invalid.
What I am suggesting should be functionally
> Wouldn't that result in a changing pubkey at each update, and thus
require an onchain move to be committed?
Suggestion was in line with original proposal where no keys are changing
ever, just not presupposing existence of MuSig.
On Thu, Mar 26, 2020 at 1:15 PM Christian Decker via bitcoin-dev
Ruben Somsen via bitcoin-dev
writes:
> Regarding modification 1, I agree with ZmnSCPxj that
> Decker-Wattenhofer is your next best option, given that eltoo is not
> yet available. But if you are going to use a kickoff transaction, keep
> in mind that every previous owner will have a copy of it.
Very good point, but I think this is easy to fix.
It's not actually necessary that the quantity in (b) involve the SE's secret key
s1. It can be purely the blinding factor. This quantity gets relayed through the
SE anyway, after a round trip through owner 2, where the SE removes the blinding
Hi Tom,
Nice to see you working on this.
Regarding modification 1, I agree with ZmnSCPxj that Decker-Wattenhofer is
your next best option, given that eltoo is not yet available. But if you
are going to use a kickoff transaction, keep in mind that every previous
owner will have a copy of it.
Hi,
Great to see some work in this direction, here's some thoughts on your keygen
scheme:
In the scenario where Owner1=Owner2, that is, one of the owners sends some
coins to itself, that owner would get to know both x1*s1 and
x2*s2=x2*s1*o2_inv*o1, and, because he already knows o1 and o2,
Good morning Tom,
>
> We are starting to work on an implementation of the statechains concept
> (https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),
> with particular interest in using the protocol enable the change of
> ownership (novation) of
Hi all,
We are starting to work on an implementation of the statechains concept (
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),
with particular interest in using the protocol enable the change of
ownership (novation) of an individual position
24 matches
Mail list logo
