Hi ZmnSCPxj,
>Basically, the "Stale Factory" and "Broken Factory" problems.
I see, I'll have to read up on those.
>Combining it via MuSig is probably best, as the server is now unable to
>recognize even the pubkey (assuming it never is informed `X`).
Yes, that's the current thinking. See
Good morning Ruben,
> > an early draft
>
> I meant an early draft of Statechains, sorry if that was confusing.
> But yes, it's essentially no different from channel factories without
> eltoo.
Sorry, I am referring to current issues with channel factories, which were not
addressed in the original
Hi ZmnSCPxj,
Thanks for the reply. Sorry to keep you waiting, Coredev and Breaking
Bitcoin have been keeping me busy.
Transcript from Coredev (thanks Bryan):
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-statechains/
Blind Statechains at Breaking Bitcoin:
Good morning Ruben,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday, June 6, 2019 1:20 PM, Ruben Somsen wrote:
> Hi ZmnSCPxj,
>
> Thank you for your comments.
>
> > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not
> > strictly
Hi ZmnSCPxj,
Thank you for your comments.
>Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not
>*strictly* required. We can still make use of the Decker-Wattenhofer
>construction instead.
Yes, an early draft (from before the eltoo paper) was using that
construction, but
Good morning Ruben,
> At
> Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
> [2] to make the entity unaware of what it's signing. I now think this
> is the more interesting approach. The functionality can be described
> fairly elegantly as follows.
I agree.
I had no
Hi everyone,
For those who are unfamiliar, Statechains enable the transfer UTXOs
off-chain with the help of a Statechain entity (trusted server(s))
without giving them full custodial control over your coins [0]. At
Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
[2] to make
