Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.

2020-09-20 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.

2020-09-20 Thread Tom Trevethan via bitcoin-dev
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 own

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

2020-09-20 Thread Antoine Riard via bitcoin-dev
Right, I was off the shot. Thanks for the explanation. 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, Bo

Re: [bitcoin-dev] Taproot (and graftroot) complexity

2020-09-20 Thread Lloyd Fournier via bitcoin-dev
Hi Jay, I don't think there's much of a difference in security or privacy. The advice to avoid key-reuse remains the same and for the same reasons. LL On Sat, Sep 19, 2020 at 11:08 PM Jay Berg via bitcoin-dev wrote: > > Newb here.. don’t know if "in-reply-to" header is misbehaving. > > But th