Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
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:
https://www.youtube.com/watch?v=DqhxPWsJFZE&t=4h59m4s
>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.
>If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems this
>transitory/common key can be used for the chaperone.
That is a good point. One thing I have not yet fully analysed are the
privacy considerations. Perhaps we don't want to reveal X on-chain.
>This would be nearer to my own Smart Contracts Unchained
Adding scripting is not my preferred approach. The beauty of the
system is that the server doesn't evaluate any scripts whatsoever.
That being said, Smart Contracts Unchained (SCU) can be inserted quite
elegantly as a separate smart contracting layer.
The observation is that anything that can be done with a UTXO
on-chain, can also be done off-chain via Statechains, including SCU.
If SCU is a single (N-of-N or (1-of-N + escrow)) key, you can simply
use this as the userKey (as well as inside the off-chain eltoo tx).
It's pretty interesting how smart contracting can be added like this.
Cool stuff, ZmnSCPxj. I'll definitely be thinking about this more.
Cheers,
Ruben
On Thu, Jun 6, 2019 at 8:32 AM ZmnSCPxj wrote:
>
> 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 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 it seemed quite unwieldy. Timelocks have to be long,
> > nesting adds more transactions, channels expire faster with more use,
> > and tx fee handling is more complex. But you make a good point that if
> > SIGHASH_ANYPREVOUT turns out to be too controversial (or for
> > supporting older altcoins), this would be a potential fallback.
>
> The lack of `SIGHASH_ANYPREVOUT` does make it difficult to operate a channel
> factory.
> Factory operations would still require the signatures of all participants,
> but once a participant has released its signature, it cannot be sure whether
> its channels should be rooted on the previous factory state or the next (i.e.
> the [Stale Factory
> problem](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001974.html)
> ).
> This is fixable if we use `SIGHASH_ANYPREVOUT` on channel update transactions.
> Alternately without that flag we can run channels rooted on both the previous
> and next factory states, which actually is similar to what we need to do for
> splice-in (so we could reuse that code, possibly).
>
> >
> > > This still admits the possibility of an exit scam once a few "big enough"
> > > swaps are in position to be stolen, trading off earned reputation for
> > > cold-stored cash.
> >
> > That is correct. The worst case for security still comes down to
> > having to trust the federation, but the transitory key, as well as the
> > blind signature scheme, does add an interesting layer of separation
> > that makes it essentially "non-custodial". The article I linked has
> > more on this.
>
> Of note is that this is roughly the same as the common key in my own Smart
> Contracts Unchained.
>
> If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems
> this transitory/common key can be used for the chaperone.
>
> Going further on Smart Contracts Unchained, I observe that the below:
>
> > // Start new signature chain
> > (1) requestNewKey(userPubkey) => returns a new serverPubkey and registers
> > it to userPubkey
> > // Extend existing chain
> > (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =>
> > returns blindSignature, registers the serverPubkey to nextUserPubkey
>
> Can be generalized, such that instead of pubKeys and their signatures, we
> have validation programs and their witnesses.
>
> For example, instead of userPubkey and nextUserPubkey we have a userScript
> and nextUserScript, with userSignature replaced by a userWitness.
>
> This would be nearer to my own Smart Contracts Unchained, though without
> committing to the smart contract onchain, only offchain in the server.
>
>
>
> >
> > Cheers,
> > Ruben
> >
> > On Thu, Jun 6, 2019 at 2:09 AM ZmnSCPxj zmnsc...@protonmail.com wrote:
> >
> > > 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
Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)
What about this? We store a RBU ("relay bandwidth used") with each transaction
in the mempool. Where RBU is defined as the size of the transaction + RBU of
all transactions it has evicted.
For a replacement to be valid: The feerate must be higher than what it's
evicting, and the fee must be greater than minRelayFee*RBU.
-Ryan
‐‐‐ Original Message ‐‐‐
On Sunday, June 9, 2019 7:07 AM, David A. Harding via bitcoin-dev
wrote:
> On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:
>
> > Matt Corallo lf-li...@mattcorallo.com writes:
> >
> > > 2. wrt rule 4, I'd like to see a calculation of worst-case free
> > > relay. I think we're already not in a great place, but maybe it's
> > > worth it or maybe there is some other way to reduce this cost
> > > (intuitively it looks like this proposal could make things very,
> > > very, very bad).
> > >
> >
> > I think you can currently create a tx at 1 sat/byte, have it
> > propagate, then RBF it to 2 sat/byte, 3... and do that a few thousand
> > times before your transaction gets mined.
>
> Yes, the current incremental relay fee in Bitcoin Core is 0.1000
> BTC/KvB.
>
> > If that's true, I don't think this proposal makes it worse.
>
> Here's a scenario that I think shows it being at least 20x worse.
>
> Let's imagine that you create two transactions:
>
> tx0: A very small transaction (~100 vbytes) that's just 1-in, 1-out.
> At the minimum relay fee, this costs 0.0100 BTC
>
> tx1: A child of that transaction that's very large (~100,000 vbytes,
> or almost 400,000 bytes using special scripts that allow witness
> stuffing). At the minimum relay fee, this costs 0.0010 BTC
>
> Under the current rules, if an attacker wants to fee-bump tx0 by the
> minimum incremental fee (a trivial amount, ~0.0100 BTC), the
> attacker's replacement also needs to pay for the eviction of the huge
> child tx1 by that same incremental fee (~0.0010).
>
> Thus the replacement would cost the attacker a minimum of about
> 0.00100100 (~1 mBTC) for the original transactions and 0.00100100 for
> the replacement (about 2 mBTC total).
>
> The attacker could then spend another 1 mBTC re-attaching the child and
> yet another 1 mBTC bumping again, incuring about a 2 mBTC cost per
> replacement round. At writing, 2 mBTC is about $14.00 USD---an amount
> that's probably enough to deter most attacks at scale.
>
> Under the new proposed rule 6, Mallory's replacement cost would be the
> amount to get the small tx0 to near the top of the mempool (say
> 0.0010 BTC/KvB, so 0.0001 BTC total). Because this would evict
> the expensive child, it would actually reduce the original amount paid
> by the attacker by 90% compared to the previous section's example where
> using RBF increased the original costs by 100%.
>
> The 0.1 mBTC cost of this attack is about $0.70 USD today for the
> roughly the same data relay use as one round of the currently possible
> attack. In short, if I haven't misplaced a decimal point or made some
> other mistake, I think the proposed rule 6 would result in approximately
> a 95% reduction in the cost paid by an attacker for wasting 400,000
> bytes of bandwidth per node (x60,000 nodes = 24 GB across all nodes, not
> counting INV overhead).
>
> Although the attacker might only get one replacement per block per
> transaction pair out of this version of the attack, they could execute
> the attack many times in parallel using different tranaction pairs. If
> this is combined with the treadmill leapfrogging Russell O'Connor
> described elsewhere in this thread, the attack could possibly be
> repeated multiple times per block per transaction pair at only slightly
> increased cost (to pay the increasing next-block transaction fees).
>
> > > > 3. wrt rule 5, I'd like to see benchmarks, it's probably a pretty
> > > > nasty DoS attack, but it may also be the case that is (a) not worse
> > > > than other fundamental issues or (b) sufficiently expensive.
> > > >
> >
> > I thought we still meet rule 5 in practice since bitcoind will never
> > even accept a tree of unconfirmed txs which is > 100 txs? That would
> > still stand, it's just that we'd still consider a replacement.
>
> Although the BIP125 limit is 100, Bitcoin Core's current default is 25.[1]
> (When RBF was implemented in Bitcoin Core, transaction ancestry was only
> tracked for purposes of ensuring valid transaction ordering within
> blocks; later when CPFP was implemented, ancestry was additionally used
> to calculate each transaction's package fee---the value of it and all
> its unconfirmed ancestors. This requires more computation to update
> the mempool metadata when the ancestry graph changes.)
>
> Again, I'd be thinking here of something similar to O'Connor's
> treadmilling attack where replacements can push each other out of the
> top mempool and so create enough churn for a CPU exhaustion attack.
>
> > > > Obviously there is also a ton more c
