Re: [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features

2021-01-16 Thread Antoine Riard via bitcoin-dev
Hello Kevin,

Thanks for starting this thread, that's a really relevant discussion
ecosystem-wise !

> * Proposed improvement: The HW should display the Bitcoin Script itself
when possible (including the unlock conditions).

What level of script literacy are you assuming on your users ? I can see
enterprise/hobbyist folks to know enough of Script to understand the
intended behavior but I don't think that's a reasonable assumption for your
average user. Of course, Miniscript Policy makes things easier, but IMHO, I
still hope to see some mature, higher-level language (e.g Ivy) to ease
script semantic understanding and thus widen the crowd of users.

Further, I would do a bit on UX research on the correctness model expected
by your users. I.e if they fail to verify accordingly, are they losing
funds, transaction doesn't confirm, transaction doesn't even propagate,
etc. You should also make assumptions on the mental resources you're
required from them. Time-sensitive L2 protocols have a wide scope to check,
e.g not verifying the nSequence/nLocktime fields can provoke funds failures.

> This applies to pre-signed transaction protocols especially well as the
template of these transactions could be known
and recognized by the HW. Typically for Revault, the HW could display:
"Unvault Transaction, all expected pubkeys
present in the script".

In the future, I would expect templates of high-security protocols like
vaults to be part of the trusted computing base of any decent HW. I think
good standards there would avoid HW vendors to come with some kind of
certified-templates scheme and thus having to bless custom scripts of every
vaults implementations.

> Proposed improvement: The HW could know pubkeys or xpubs it does not hold
the private keys
for, and display a label (or
understand it for logic reasons, such as "expected pubkeys" as the previous
example).

I don't think you even need user input on this, the absence of pubkeys
knowledge itself is a trigger to display a label or ask for further
information. Where absence of pubkeys knowledge can be interpreted as
devoid from key whitelisting or privkey ownership.

> Going further, the xpubs could be
aliased the first time they are entered/verified (as part of, say, an
initial setup ceremony) for instance with the
previously mentioned Miniscript policy: or(pk(Alice), and(pk(Bob),
after(42))).

I would be careful about accidental or malicious alias collisions. But yes
that can be something, you can even conserve a merkle tree root in the
Secure Element where the hashed element are
previously authenticated alias/pubkeys. And require from the non-trusted
challenger to come with a merkle branch to validate address inclusion.

> Then there is PSBT support and the maximum transaction size limit for
these: we need more transparency from HW manufacturers on their li
mitations.

I understand them, Script is full of subtleties, taproot is likely to have
more of them and if you take sighash malleability that's not something you
want your average user to play with. Maybe it
would be better to come up with a first wave of script features on which
you expect transparency ? For sure, OP_CSV is a good candidate.

> Once any input of a (pre-signed)transaction is
spent, this transaction isn't valid anymore. Most pre-signed transactions
protocols are used today as a form of defense
mechanism, spending any input would mean incapacitating the entire defense
mechanism.

I don't see the exact issue here. E.g in Lightning, even if you pre-sign a
justice transaction punishing every revokeable outputs on counterparty
transaction, and one input is spent, will current HWs prevent you to-resign
an updated justice transaction ?

> I understand some of these changes may be very difficult, especially
given the low memory and computational power of
secure elements.

Instead of relying on hand-sized devices, what about relying on HSMs for a
first-wave of adoptions, those ones have far enough resources to run a
reasonable L2 stack on the trusted-side ?

But overall agree, on the requirement to level-up HWs for L2. IMO, a first
step could be to list a  common set of features beyond
deployed/soon-to-be-deployed L2s, that would make things easier for HW
vendors to have a unique list of grievances. Before they engage in further,
dedicated tweaks to adapt for each protocol security model. OP_CSV/OP_CTLV
decoding/"burned" standard scripts support would be a good starter.

> Feel free to reply with your comments or adding suggestions, I am not a
hardware wallet expert and would take criticism
wit
hout being offended.

I don't know yet any *L2* hardware wallet expert :)

Cheers,
Antoine

Le jeu. 14 janv. 2021 à 13:46, Kevin Loaec via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hello everyone,
>
> I would like to start a discussion on improving Hardware Wallets.
>
> My approach to this right now is from a vault protocol we are developing
> (Revault, [1]), and its Hardware Wallet
> 

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

2020-09-22 Thread Antoine Riard via bitcoin-dev
Hello AC,

Yes that's a real issue. In the context of multi-party protocols, you may
pre-signed transactions with the feerate of _today_ and then only going to
be broadcast later with a feerate of _tomorrow_.
In that case the pre-signed feerate may be so low that the transaction
won't even propagate across network mempools with a local minimal feerate
higher.

That's why you want to be sure that the feerate of your  package of
transactions (either sponsor+sponsoree or parent+CPFP) is going to be
evaluated as a whole to decide acceptance of each element of the package.

Antoine


Le mar. 22 sept. 2020 à 03:28, ArmchairCryptologist via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Not sure if I'm missing something, but I'm curious if (how) this will work
> if the sponsored transaction's feerate is so low that it has been largely
> evicted from mempools due to fee pressure, and is too low to be widely
> accepted when re-broadcast? It seems to me that the following requirement
>
> >1. The Sponsor Vector's entry must be present in the mempool
>
> means that you enter a catch-22 where the sponsor transaction cannot be
> broadcast because the sponsored transaction is not in the mempool, and the
> sponsored transaction cannot be (re-)broadcast because the fee is too low.
> This requirement might therefore need to be revised.
>
> There is of course no global mempool, but RBF by its nature would still
> work in this case, by replacing the transaction if it exists and inserting
> it if it does not.
>
> --AC
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-09-21 Thread Antoine Riard via bitcoin-dev
I think this is a worthy idea as the funding outpoint of any off-chain
protocols is an invariant known by participants. Thus by sponsoring an
outpoint you're requiring from network mempools to increase the feerate of
the package locally known without assuming about the concrete state as any
of them confirming is moving protocol forward.

That said, a malicious counterparty can still broadcast a heavy-weighted
transaction such as an honest party, devoid of knowledge of this weight,
won't attach a sponsor with a fee high enough to timely confirm the
sponsoree. This counterparty capability is a function of package
malleability allowed by the off-chain protocol.

Thus an honest party has to overshoot your bump as a default setting. Now
this is a new concern as such a mechanism can be used as a fee-burning one
by your counterparty. I believe we want a fee-burning equilibrium for any
pinning solution, Mallet shouldn't force Alice to overpay in fee more than
Mallet is ready to feerate-bid in network mempools.

> I don't think package relay based only on feerate solves RBF transaction
> pinning (and maybe also doesn't solve ancestor/dependent limit pinning).

Yes I agree with this. There are some really nasty cases of pinning where
an adversary with knowledge of the tx-relay topology can block your
compelling feerate bids (sponsors/package relay/anchor whatever) from
propagating by leveraging conflicts and RBF logic.

Outbound tx-relay peers rotation which makes the tx-relay topology harder
to observe could help.

Antoine

Le lun. 21 sept. 2020 à 12:27, Jeremy  a écrit :

> Responses Inline:
>
> Would it make sense that, instead of sponsor vectors
>> pointing to txids, they point to input outpoints?  E.g.:
>>
>> 1. Alice and Bob open a channel with funding transaction 0123...cdef,
>>output 0.
>>
>> 2. After a bunch of state updates, Alice unilaterally broadcasts a
>>commitment transaction, which has a minimal fee.
>>
>> 3. Bob doesn't immediately care whether or not Alice tried to close the
>>channel in the latest state---he just wants the commitment
>>transaction confirmed so that he either gets his money directly or he
>>can send any necessary penalty transactions.  So Bob broadcasts a
>>sponsor transaction with a vector of 0123...cdef:0
>>
>> 4. Miners can include that sponsor transaction in any block that has a
>>transaction with an input of 0123...cdef:0.  Otherwise the sponsor
>>transaction is consensus invalid.
>>
>> (Note: alternatively, sponsor vectors could point to either txids OR
>> input outpoints.  This complicates the serialization of the vector but
>> seems otherwise fine to me.)
>>
>
> *This seems like a fine suggestion and I think addresses Antoine's issue.*
>
>
> *I think there are likely some cases where you do want TXID and not Output
> (e.g., if you *
>
> *are sponsoring a payment to your locktime'd cold storage wallet (no CPFP)
> from an untrusted third party (no RBF), they can grift you into paying for
> an unrelated payment). This isn't a concern when the root utxo is multisig
> & you are a participant.*
>
> *The serialization to support both, while slightly more complicated, can
> be done in a manner that permits future extensibility as well if there are
> other modes people require.*
>
>
>
>>
>> > If we want to solve the hard cases of pinning, I still think mempool
>> > acceptance of a whole package only on the merits of feerate is the
>> easiest
>> > solution to reason on.
>>
>> I don't think package relay based only on feerate solves RBF transaction
>> pinning (and maybe also doesn't solve ancestor/dependent limit pinning).
>> Though, certainly, package relay has the major advantage over this
>> proposal (IMO) in that it doesn't require any consensus changes.
>> Package relay is also very nice for fixing other protocol rough edges
>> that are needed anyway.
>>
>> -Dave
>>
>
> *I think it's important to keep in mind this is not a rival to package
> relay; I think you also want package relay in addition to this, as they
> solve different but related problems.*
>
>
> *Where you might be able to simplify package relay with sponsors is by
> doing a sponsor-only package relay, which is always limited to 2
> transactions, 1 sponsor, 1 sponsoree. This would not have some of the
> challenges with arbitrary-package package-relay, and would (at least from a
> ux perspective) allow users to successfully get parents with insufficient
> fee into the mempool.*
>
>
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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, Bob can broadcast a thousand of revoked LN states and pin them with
low-feerate sponsors such as these malicious packages absolute fee are
higher than the honest state N. Alice can't fee-sponsor
them as we can assume she hasn't a global view of network mempools. Due to
the proposed policy rule "The Sponsor Vector's entry must be present in the
mempool", Alice's sponsors won't propagate. Even amending this rule, we
can't assume Alice has a thousand of sponsoring utxos to avoid conflict
between her own broadcast.

Of course, offchain protocols designers can limit a participant's
capability to construct a pinning package by constraining its malleability
and thus to always have a compelling feerate. E.g in Lightning you can bind
the size of a commitment transaction by refusing relayed HTLCs and thus
have less HTLC outputs. This security increase comes at the price of less
protocol flexibility, e.g reducing payments throughput.

Further, a malicious counterparty can still take advantage of
mempool-congestion spikes. Even if the pinning package has a compelling
feerate, high enough to bounce off a honest broadcast, there is no
guarantee it stays such. Just after the pinning, congestion can increase
and bury it for long-enough until a timelock expires.

If we want to solve the hard cases of pinning, I still think mempool
acceptance of a whole package only on the merits of feerate is the easiest
solution to reason on.

Le sam. 19 sept. 2020 à 15:46, Jeremy  a écrit :

> Antoine,
>
> Yes I think you're a bit confused on where the actual sponsor vector is.
> If you have a transaction chain A->B->C and a sponsor S_A, S_A commits to
> txid A and A is unaware of S.
>
>
> W.r.t your other points, I fully agree that the 1-to-N sponsored case is
> very compelling. The consensus rules are clear that sponsor commitments are
> non-rival, so there's no issue with allowing as many sponsors as possible
> and including them in aggregate. E.g., if S_A and S'_A both sponsor A with
> feerate(S*) > feerate(A), there's no reason not to include all of them in a
> block. The only issue is denial of service in the mempool. In the future,
> it would definitely be desirable to figure out rules that allow mempools to
> track both multiple sponsors and multiple sponsor targets. But in the
> interest of KISS, the current policy rules are designed to be minimally
> invasive and maximally functional.
>
> In terms of location for the sponsor vector, I'm relatively indifferent.
> The annex is a possible location, but it's a bit odd as we really only need
> to allow one such vector per tx, not one per input, and one per input would
> enable some new use cases (maybe good, maybe bad). Further, being in the
> witness space would mean that if two parties create a 2 input transaction
> with a desired sponsor vector they would both need to specify it as you
> can't sign another input's witness data. I wholeheartedly agree with the
> sentiment though; there could be a more efficient place to put this data,
> but nothing jumps out to me as both efficient and simple in implementation
> (a new tx-level field sounds like a lot of complexity).
>
>
> > n >=1 ? I think you can have at least one vector and this is matching
> the code
>
> yes, this has been fixed in the gist (cred to Dmitry Petukhov for pointing
> it out first), but is correct in the code. Thank you for your careful
> reading.
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-09-19 Thread Antoine Riard via bitcoin-dev
EDIT: I misunderstood the emplacement of the sponsor vector, please
disregard previous review :( Beyond where the convenient place should live,
which is still accurate I think.

> The
> Sponsor Vector TXIDs  must also be
> in the block the transaction is validated in, with no restriction on
> order or on specifying a TXID
> more than once.


Le sam. 19 sept. 2020 à 14:39, Antoine Riard  a
écrit :

> Hi Jeremy,
>
> This is a really interesting proposal to widen the scope of fee
> mechanisms.
>
> First, a wider point on what this proposal brings with regards to pinning,
> to the best of my knowledge.
>
> A pinning may have different vectors by exploiting a) mempools limits (e.g
> descendants) or b) mempools absolute-fee/feerate/conflicts logic. The lack
> of a global mempool means you can creatively combine them to provoke
> mempools-partitions [0]
>
> As far as I understand this proposal, it aims to solve the class a) of
> pinnings by allowing fee-bumping with a new definition of dependencies. I'm
> not sure it achieves to do  so as the Sponsor Vector TXIDs being committed
> in the Sponsoree signature hash means the Sponsor feerate is part of this
> commitment and can't be unilaterally adjusted to actual mempool-congestion.
>
> After broadcasting the Sponsor/Sponsoree pair, mempools feerate may
> increase again and thus obsoleting the previous fee-bump. Or you need a
> Sponsor Vector for every blockspace feerate, in the worst-case bound by the
> value of the Sponsoree funds.
>
> Further, I would say this proposal won't solve class b) of pinnings for
> multi-party time-sensitive protocols without further modifications. E.g in
> a LN-channel, assuming the commitment transaction is the Sponsoree, Alice
> the honest party can't increase Sponsor feerate by mal eating its outputs
> without breaking the sponsoring dependency. And thus evict a Bob's
> malicious pin across network mempools.
>
> I think a further softfork proposal with regards to sighash malleability
> is needed to achieve the security semantic for Lightning type of protocols.
> Roughly, a SIGHASH_IOVECTOR allows N-inputs to commit to N-outputs, thus
> committing to all the balance/HTLC outputs minus the last output Vector,
> non-interactively malleable by channel participants. This would be a form
> of transaction finalization delegation, allowing Alice to direct the
> Sponsor vector to a good-feerate adjusted transaction.
>
> Note, I may have misunderstood completely the proposal as the feerate
> observed might be the Sponsor _package_ one and each party could have a
> pair of outputs to spend from to non-interactively increase the Sponsoree.
> Though sounds like re-introducing the limits issues...
>
> That said, see following review points.
>
> > This is insufficient because if new attacks are found, there is
> > limited ability to deploy fixes for
> > them against deployed contract instances (such as open lightning
> > channels). What is required is a
> > fully abstracted primitive that requires no special structure from an
> > underlying transaction in
> > order to increase fees to confirm the transactions.
>
> This is really true, in case of vulnerability discovered mass closing of
> the channel would be in itself a concern as it would congest mempools and
> open to looter behaviors [1]. Though I don't think a special structure can
> claim covering every potential source of vulnerability for  off-chain
> protocols as some of them might be tx-relay based (e.g reject-filters for
> segwit txn).
>
> Further, a "fully abstracted primitive" is loosely defined, one could
> argue that anchor outputs don't require special structure from an
> underlying transaction (i.e on the order of outputs ?).
>
> >  where
> n>1, it is interpreted as a vector of TXIDs (Sponsor Vector).
>
> n >=1 ? I think you can have at least one vector and this is matching the
> code
>
> > If there is another convenient place to put the TXID vector, that's fine
> too.
>
> You might use the per-input future Taproot annex, and even apply a witness
> discount as this mechanism could be argued to be less blockspace expensive
> than a CPFP for the same semantic.
>
> An alternative could be a new transaction field like a new `stxid` :
>
>
> `[nVersion][marker][flag][txins][txouts][witness][nLockTime][nSponsor][nVersion][n*STXID]`
>
> It would be cheaper as you likely save the output amount size and OP_VER.
> And you don't have to subtract a dust output + 1 from the other output
> amount to make sure the Sponsor output meets dust propagation requirements.
>
> Though it's more demanding on the tx-relay layer (new serialization and
> transaction identifier) and new a version bump of the signature digest algo
> to avoid a third-party malleating the per-transaction sponsor field
>
> > To prevent garbage sponsors, we also require that:
>
> Does the reverse hold ? Garbage Sponsoree by breaking the dependency and
> double-spending the utxo spent by the Sponsor and thus decreasing
> Sponsoree's 

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

2020-09-19 Thread Antoine Riard via bitcoin-dev
Hi Jeremy,

This is a really interesting proposal to widen the scope of fee mechanisms.

First, a wider point on what this proposal brings with regards to pinning,
to the best of my knowledge.

A pinning may have different vectors by exploiting a) mempools limits (e.g
descendants) or b) mempools absolute-fee/feerate/conflicts logic. The lack
of a global mempool means you can creatively combine them to provoke
mempools-partitions [0]

As far as I understand this proposal, it aims to solve the class a) of
pinnings by allowing fee-bumping with a new definition of dependencies. I'm
not sure it achieves to do  so as the Sponsor Vector TXIDs being committed
in the Sponsoree signature hash means the Sponsor feerate is part of this
commitment and can't be unilaterally adjusted to actual mempool-congestion.

After broadcasting the Sponsor/Sponsoree pair, mempools feerate may
increase again and thus obsoleting the previous fee-bump. Or you need a
Sponsor Vector for every blockspace feerate, in the worst-case bound by the
value of the Sponsoree funds.

Further, I would say this proposal won't solve class b) of pinnings for
multi-party time-sensitive protocols without further modifications. E.g in
a LN-channel, assuming the commitment transaction is the Sponsoree, Alice
the honest party can't increase Sponsor feerate by mal eating its outputs
without breaking the sponsoring dependency. And thus evict a Bob's
malicious pin across network mempools.

I think a further softfork proposal with regards to sighash malleability is
needed to achieve the security semantic for Lightning type of protocols.
Roughly, a SIGHASH_IOVECTOR allows N-inputs to commit to N-outputs, thus
committing to all the balance/HTLC outputs minus the last output Vector,
non-interactively malleable by channel participants. This would be a form
of transaction finalization delegation, allowing Alice to direct the
Sponsor vector to a good-feerate adjusted transaction.

Note, I may have misunderstood completely the proposal as the feerate
observed might be the Sponsor _package_ one and each party could have a
pair of outputs to spend from to non-interactively increase the Sponsoree.
Though sounds like re-introducing the limits issues...

That said, see following review points.

> This is insufficient because if new attacks are found, there is
> limited ability to deploy fixes for
> them against deployed contract instances (such as open lightning
> channels). What is required is a
> fully abstracted primitive that requires no special structure from an
> underlying transaction in
> order to increase fees to confirm the transactions.

This is really true, in case of vulnerability discovered mass closing of
the channel would be in itself a concern as it would congest mempools and
open to looter behaviors [1]. Though I don't think a special structure can
claim covering every potential source of vulnerability for  off-chain
protocols as some of them might be tx-relay based (e.g reject-filters for
segwit txn).

Further, a "fully abstracted primitive" is loosely defined, one could argue
that anchor outputs don't require special structure from an underlying
transaction (i.e on the order of outputs ?).

>  where
n>1, it is interpreted as a vector of TXIDs (Sponsor Vector).

n >=1 ? I think you can have at least one vector and this is matching the
code

> If there is another convenient place to put the TXID vector, that's fine
too.

You might use the per-input future Taproot annex, and even apply a witness
discount as this mechanism could be argued to be less blockspace expensive
than a CPFP for the same semantic.

An alternative could be a new transaction field like a new `stxid` :

`[nVersion][marker][flag][txins][txouts][witness][nLockTime][nSponsor][nVersion][n*STXID]`

It would be cheaper as you likely save the output amount size and OP_VER.
And you don't have to subtract a dust output + 1 from the other output
amount to make sure the Sponsor output meets dust propagation requirements.

Though it's more demanding on the tx-relay layer (new serialization and
transaction identifier) and new a version bump of the signature digest algo
to avoid a third-party malleating the per-transaction sponsor field

> To prevent garbage sponsors, we also require that:

Does the reverse hold ? Garbage Sponsoree by breaking the dependency and
double-spending the utxo spent by the Sponsor and thus decreasing
Sponsoree's feerate to mempool bottom. AFAIK you can't do this with CPFP.

> rational miners may wish to permit multiple sponsor
> targets, or multiple sponsoring
> transactions,

I'm not sure if your policy sktech prevents multiple
1-Sponsor-to-N-Sponsoree. Such a scheme would have some edges. A mempool
might receive Sponsoree in different order than evaluated by original
sender and thus allocate the Sponsor feerate to the less-urgent Sponsoree.

> This is treated as a separate
> concern, as any strides on
> package relay generally should be able to support sponsors 

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-09-05 Thread Antoine Riard via bitcoin-dev
Hi Zeeman,

I think one of the general problems for any participant in an
interdependent chain of contracts like Lightning or CoinSwap is to avoid a
disequilibrium in its local HTLC ledger. Concretely sending forward more
than you receive backward. W.r.t, timelocks delta aim to enforce order of
events, namely that a forward contract must be terminated before any
backward contract to avoid a discrepancy in settlement. Order of events can
be enforced by a) absolute timelocks and thus linearized on the same scale
by blockchain ticks or b) by a counterparty to two relative-time locked
contracts which observe the broadcast of the backward transaction and thus
manually trigger the kickoff of forward timelock by broadcasting the
corresponding transaction.

With this rough model in mind, pinning an absolute or relative timelocked
transaction produce the same effect, i.e breaking contracts settlement
order.

> This can be arranged by having one side offer partial signatures for the
transaction of the other, and once completing the signature, not sharing it
with the other until we are ready to actually broadcast the transaction of
our own volition.
> There is no transaction that both participants hold in completely-signed
form

I don't think that's different from the current model where you have either
a valid HTLC-timeout or HTLC-Sucess tx to solve a HTLC output but never
full witness material to build both ?

I see a theoretical issue with RBF-range, if you're likely to lose the
balance, you can broadcast your highest-RBF version thus incentivizing
miners to censor counterparty claim tx. Kind of a "nothing at stake" issue.
As of today, you have to take this fee out of your pocket if you want to
incentivize miners to act so, not promising a fee from an ongoing disputed
balance.

> Private key turnover is still useful even in an absolute-timelock world.

The way I understand the either-HTLC-or-private-key-turnover construction
in CoinSwap is for the HTLC to serve as a security backup in case the
cooperative key turnover fails. Lightning don't have this model as you
don't switch funding transaction ownership.

> To reduce this risk, A can instead first swap A->B->A, then when that
completes, A->C->A.
This limits its funding lockup to 1 week.

Okay I think I understand your point. So by intermediating the chain with
the taker you ensure that in case of previous hop failure, taker funds are
only timelocked for the delta of this faulting hop not the whole route. But
still not anchoring onchain the next route segment means that any moment
the next maker can exit from the proposed position ?

That's interesting, so a) you require all takers to lock their funds
onchain before initiating the whole routing and you will pay more in
service fees or b) you only lock them step by step but you increase risk of
next hop default and thus latency. Roughly.

It might be an interesting construction to explore on its own, minus the
downside of producing weird spend patterns due to next hop maker bidding
with another party.

Cheers,

Antoine

Le lun. 24 août 2020 à 23:16, ZmnSCPxj  a écrit :

>
> Good morning Antoine,
>
>
> > Note, I think this is independent of picking up either relative or
> absolute timelocks as what matters is the block delta between two links.
>
> I believe it is quite dependent on relative locktimes.
> Relative locktimes *require* a contract transaction to kick off the
> relative locktime period.
> On the other hand, with Scriptless Script (which we know how to do with
> 2p-ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a
> contract transaction.
>
> With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one
> participant holds a completely-signed timelock transaction while the other
> participant holds a completely-signed pointlock transaction.
> This can be arranged by having one side offer partial signatures for the
> transaction of the other, and once completing the signature, not sharing it
> with the other until we are ready to actually broadcast the transaction of
> our own volition.
> There is no transaction that both participants hold in completely-signed
> form.
>
> This should remove most of the shenanigans possible, and makes the 30xRBF
> safe for any range of fees.
> I think.
>
> Since for each PTLC a participant holds only its "own" transaction, it is
> possible for a participant to define its range of fees for the RBF versions
> of the transaction it owns, without negotiation with the other participant.
> Since the fee involved is deducted from its own transaction, each
> participant can define this range of RBFed fees and impose it on the
> partial signatures it gets from the other participant.
>
> --
>
> Private key turnover is still useful even in an absolute-timelock world.
>
> If we need to bump up the block delta between links, it might be
> impractical to have the total delta of a multi-hop swap be too long at the
> taker.
>
> As a concrete example, 

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-09-05 Thread Antoine Riard via bitcoin-dev
Hi Chris,

I forgot to underscore that contract transaction output must be grieved by
at least a CSV of 1. Otherwise, a malicious counterparty can occupy with
garbage both the timelock-or-preimage output and its own anchor output thus
blocking you to use the bumping capability of your own anchor ouput.

A part of this, I think it works.

> Another possible fix for both vulnerabilities is to separate the
> timelock and hashlock cases into two separate transactions as described
> by ZmnSCPxj in a recent email to this list. This comes at the cost of
> breaking private key handover allowing coins to remain unspent
indefinitely.

This works too assuming these second-stage transactions aren't malleable at
all (e.g SIGASH_SINGLE). Other ways you can increase their feerate/absolute
fee and you're back to the initial situation.

Beyond note also that anchors-on-second-stage are more risky here, as
otherwise your counterparty can again attach a low-feerate child. In case
of concurrent broadcast (assuming you haven't achieved to claim the output
before timelock expiration due to network outage/mempool-congestion) you
might not see your counterparty version. I.e, your local mempool has the
timelock tx and the rest of the network the hashlock and your CPFP bump
won't propagate as being an orphan.

So you're left with a RBF-range, which is mostly okay minus a theoretical
concern : a party guessing the odds to lose the balance are high can
broadcast/send out-of-band the highest-fee bound to miners thus
incentivizing them to censor a honest, low-fee  preimage tx. A
"nothing-at-stake-for-genuinely-evil-counterparty" issue.

> Another possible fix for the second attack, is to encumber the output
> with a `1 OP_CSV` which stops that output being spent while unconfirmed.
> This seems to be the simplest way if your aim is to only fix the second
> attack.

Yes you don't package fee malleability so an honest party can always
unilaterally bump the feerate and override concurrent bids.


That said, I would lean towards anchors and thus unileratel fee bumping.
Feerate interactivity among a multi-party protocol should be seen as an
oracle to leak the full-node of a participant. By sending a range of
conflicting transactions with different feerates to a set of network
mempools I could theoretically observe variations in the protocol feerate
announced.

I would recommend you to have a look on this paper, if it's not done yet :
https://arxiv.org/pdf/2007.00764.pdf, the first one analyzing privacy
holistically across Bitcoin layers.

Cheers,

Antoine

Le sam. 29 août 2020 à 18:03, Chris Belcher  a écrit :

> Hello Antoine,
>
> Thanks for the very useful insights.
>
> It seems having just one contract transaction which includes anchor
> outputs in the style already used by Lightning is one way to fix both
> these vulnerabilities.
>
> For the first attack, the other side cannot burn the entire balance
> because they only have access to the small amount of satoshi of the
> anchor output, and to add miner fees they must add their own inputs. So
> they'd burn their own coins to miner fees, not the coins in the contract.
>
> For the second attack, the other side cannot do transaction pinning
> because there is only one contract transaction, and all the protections
> already developed for use with Lightning apply here as well, such as
> CPFP carve out.
>
>
> Another possible fix for both vulnerabilities is to separate the
> timelock and hashlock cases into two separate transactions as described
> by ZmnSCPxj in a recent email to this list. This comes at the cost of
> breaking private key handover allowing coins to remain unspent
> indefinitely.
>
> Another possible fix for the second attack, is to encumber the output
> with a `1 OP_CSV` which stops that output being spent while unconfirmed.
> This seems to be the simplest way if your aim is to only fix the second
> attack.
>
>
> These are all the possible fixes I can think of.
>
> Regards
> Chris
>
> On 24/08/2020 20:30, Antoine Riard wrote:
> > Hello Chris,
> >
> > I think you might have vulnerability issues with the current design.
> >
> > With regards to the fee model for contract transactions, AFAICT timely
> > confirmation is a fund safety matter for an intermediate hop. Between the
> > offchain preimage reveal phase and the offchain private key handover
> phase,
> > the next hop can broadcast your outgoing contract transactions, thus
> > forcing you to claim quickly backward as you can't assume previous hop
> will
> > honestly cooperate to achieve the private key handover. This means that
> > your range of pre-signed RBF-transactions must theoretically have for fee
> > upper bound the maximum of the contested balance, as game-theory side,
> it's
> > rational to you to burn your balance instead of letting your counterparty
> > claim it after timelock expiration, in face of mempool congestion. Where
> > the issue dwells is that this fee is pre-committed and not cancelled when
> > the 

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-24 Thread Antoine Riard via bitcoin-dev
Hello Chris,

I think you might have vulnerability issues with the current design.

With regards to the fee model for contract transactions, AFAICT timely
confirmation is a fund safety matter for an intermediate hop. Between the
offchain preimage reveal phase and the offchain private key handover phase,
the next hop can broadcast your outgoing contract transactions, thus
forcing you to claim quickly backward as you can't assume previous hop will
honestly cooperate to achieve the private key handover. This means that
your range of pre-signed RBF-transactions must theoretically have for fee
upper bound the maximum of the contested balance, as game-theory side, it's
rational to you to burn your balance instead of letting your counterparty
claim it after timelock expiration, in face of mempool congestion. Where
the issue dwells is that this fee is pre-committed and not cancelled when
the balance change of ownership by the outgoing hop learning the preimage
of the haslock output. Thus the previous hop is free to broadcast the
highest-fee RBF-transactions and burn your balance, as for him, his balance
is now encoded in the output of the contract transactions on the previous
link, for which he knows the preimage.

Note, I think this is independent of picking up either relative or absolute
timelocks as what matters is the block delta between two links. Of course
you can increase this delta to be week-lengthy and thus decrease the need
for a compelling fee but a) you may force quickly close with contract
transactions if the private key handover doesn't happen soon, you don't
want to be caught by surprise by congestion so you would close far behind
delta period expiration like half of it, and b) you increase the time-value
of makers funds in case of faulty hop, thus logically increasing the maker
fee and making the cost of the system higher in average. I guess a better
solution would be to use dual-anchor outputs has spec'ed out by Lightning,
it lets the party who has a balance at stake unilaterally increase feerate
with a CPFP. The CPFP is obviously a higher blockchain cost but a) it's a
safety mechanism for a worst-case scenario, 99% of the time they won't be
committed, b) you might use this CPFP to aggregate change outputs or other
opportunistically side-usage.

With regards to the preimage release phase, I think you might have a
pinning scenario. The victim would be an intermediate hop, targeted by a
malicious taker. The preimage isn't revealed offchain to this victim hop. A
low-feerate version of the outgoing contract transaction is broadcast and
not going to confirm, assuming a bit of congestion. As preimage is known,
the malicious taker can directly attach a high-fee, low-feerate child
transaction and thus prevent any replacement of the pinned parent by a
honest broadcast of a high-fee RBF-transaction under BIP 125 rules. At the
same time, the malicious taker broadcasts the contract tx on the previous
link and gets it confirmed. At relative timelock expiration, malicious
taker claims back the funds. When the pinned transaction spending the
outgoing link gets evicted (either by replacing child by a higher feerate
or waiting for mempool expiration after 2 weeks), taker gets it confirmed
this time and claims output through hashlock. Given the relative timelock
blocking the victim, there is not even a race.

I guess restraining the contract transaction to one and only one version
would overcome this attack. A honest intermediate hop, as soon as seeing a
relative timelock triggered backward would immediately broadcast the
outgoing link contract tx or if it's already in network mempools broadcast
a higher-feerate child. As you don't have valid multiple contract
transactions, an attacker can't obstruct you to propagate the correct
child, as you are not blind about the parent txid.

Lastly, one downside of using relative timelocks, in case of one downstream
link failure, it forces every other upstream hops to go onchain to protect
against this kind of pinning scenario. And this would be a privacy
breakdown, as a maker would be able to provoke one, thus constraining every
upstream hops to go onchain with the same hash and revealing the CoinSwap
route.

Let me know if I reviewed the correct transactions circuit model or
misunderstood associated semantic. I might be completely wrong, coming from
a LN perspective.

Cheers,
Antoine

Le mar. 11 août 2020 à 13:06, Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> I'm currently working on implementing CoinSwap (see my other email
> "Design for a CoinSwap implementation for massively improving Bitcoin
> privacy and fungibility").
>
> CoinSwaps are special because they look just like regular bitcoin
> transactions, so they improve the privacy even for people who do not use
> them. Once CoinSwap is deployed, anyone attempting surveillance of
> bitcoin transactions will be forced to ask themselves the question: how
> do we know this transaction 

[bitcoin-dev] Advances in Bitcoin Contracting : Uniform Policy and Package Relay

2020-07-29 Thread Antoine Riard via bitcoin-dev
Hi list,

Security and operations of higher-layer protocols (vaults, LN, CoinJoin,
watchtowers, ...) come with different assumptions and demands with regards
to tx-relay and fee models. As the Bitcoin stack is quite young, it would
be great to make those ones more understood and what p2p/mempool changes we
might adopt at the base layer to better answer them. I would like to
explore this with my current post.

### Time-Sensitive Protocols Security-Model (you can skip this if you know
LN)

Lightning, the most deployed time-sensitive protocol as of now, relies on
the timely confirmations of some of its transactions to enforce its
security model. Like timing out an outgoing HTLC, claiming an incoming HTLC
or punishing a revoked commitment. Ensuring timely confirmation is
two-fold: a) propagating well-transactions across the network to quickly
hit miner mempools b) offering a competitive feerate to get in next coming
blocks.

Updating feerate just-in-time is quite challenging for LN as you can't
resign a commitment once your counterparty is non-responsive or malicious,
and thus any fee strategy assuming interactivity is closed. With current
constraints of maintaining a trustless chain of transactions (no
Parent-Pay-For-Child), the only option is a CPFP. Ongoing update of LN
protocol (anchor-outputs) will allow a channel participant to unilaterally
bump feerate of its commitment/HTLCs txn, assuming there is no
_adversarial_ network mempool conditions like a concurrent broadcast.

Beyond enforcing the need to secure its funds by bumping feerate, an
offchain user might be willingly to accelerate confirmation of a broadcast
for liquidity management in face of mempool-congestion. This issue is
likely shared by any multi-party protocol like Coinjoins where resigning is
painful and a party may have different liquidity preferences than other
participants and would like to express them in an unilateral fee bumping.

### Effective Transaction Propagation and Uniform Relay Policy

Even before competing on feerate, the first and foremost point of the
laid-out security model was the well-propagation of transactions across the
p2p network. Its effectiveness is determined by compliance to 1) consensus
rules 2) policy rules. This second set is a tighter one governing different
aspects of your transactions (like size, output type, feerate,
ancestors/descendants, ...) and introduced to sanitize the p2p network
against a wide scope of resources abuses (RBF bandwidth waste, package
evaluation CPU DoS, economic nonsense outputs, ...)

These rules diverge across implementations/versions and a subset of them
can be tightened or relaxed by node operators. This heterogeneity is
actually where the risk is scored for higher protocols, your LN's full-node
might be connected to tx-relay peers with more constraining policies than
yours and thus will always reject your time-sensitive transactions,
silently breaking security of your channels [0].

Of course, LN protocols devs have always been aware of these issues and
carefully reflect policies enforcement in their codebase. That said an
important subset of them aren't documented or even standardized and thus
hard to incorporate in upper layers specs. Testing them in a black box
approach (i.e `testmempoolaccept`) before production doesn't work as your
broadcast has to be valid against the union of your yet-unknown tx-relay
topology, further static checks are blurred with dynamic ones (the feerate
now is different than the one at a future broadcast), and your transaction
might be malleate by your counterparty (like a ridiculous feerate).

And the other side, AFAIK, Core developers have always acknowledged these
issues and been really conscientious when updating such API policy. The
concerning change with protocol like LN is the severity consequences in
case of incompatible changes. Previously, your basic transaction would have
been rejected by the network and your application could have been updated
before successfully rebroadcasting. Now, such changes potentially outlawing
your time-sensitive broadcasts is a direct, measurable risk of fund loss,
either triggered by mempool-congestion or exploited by a malicious
counterparty.

Therefore, moving towards such stable tx-relay/bumping API, I propose:
a) Identifying and documenting the subset of policy rules on which upper
layers have to rely on to enforce their security model
b) Guaranteeing backward-compatibility of those rules or, in case of
tightening change, making sure there is ecosystem coordination with some
minimal warning period (1 release ?)

Committing to a uniform policy would be a philosophical change, it would
ossify some parts of full-node implementations. Another side-effect means
that upper layer devs would be incentivized to rely on such stable API. In
case of new DoS on the base layer, we might have to tighten them in a short
timeline at the price of breaking some offchain applications [1] On the
other side, full-node operators 

[bitcoin-dev] Pinning : The Good, The Bad, The Ugly

2020-06-28 Thread Antoine Riard via bitcoin-dev
(tl;dr Ideally network mempools should be an efficient marketplace leading
to discovery of best-feerate blockspace demand by miners. It's not due to
current anti-DoS rules assumptions and it's quite harmful for shared-utxo
protocols like LN)

Hello all,

Lightning security model relies on the unilateral capability for a channel
participant to confirm transactions, like timing out an outgoing HTLC,
claiming an incoming HTLC or punishing a revoked commitment transaction and
thus enforcing onchain a balance negotiated offchain. This security model
is actually turning back the double-spend problem to a private matter,
making the duty of each channel participant to timely enforce its balance
against the competing interest of its counterparties. Or laid out
otherwise, contrary to a miner violating a consensus rules, base layer
peers don't care about your LN node failing to broadcast a justice
transaction before the corresponding timelock expiration (CSV delay).

Ensuring effective propagation and timely confirmation of LN transactions
is so a critical-safety operation.  Its efficiency should be always
evaluated with regards to base layer network topology, tx-relay propagation
rules, mempools behaviors, consistent policy applied by majority of nodes
and ongoing blockspace demand. All these components are direct parameters
of LN security. Due to the network being public, a malicious channel
counterparty do have an incentive to tweak them to steal from you.

The pinning attacks which have been discussed since a few months are a
direct illustration of this model. Before digging into each pinning
scenario, few properties of the base layer components should be evocated
[0].

Network mempools aren't guaranteed to be convergent, the local order of
events determines the next events accepted. I.e Alice may observe tx X, tx
Y, tx Z and Bob may observe tx Z, tx X, tx Y. If tx Z disable-RBF and tx X
try to replace Z, Alice accepts X and Bob rejects it. This divergence may
persevere until a new block.

Tx-relay topology can be observed by spying nodes [1]. An attacker can
exploit this fact to partition network mempools in different subset and
hamper propagation across them of same-spending output concurrent
transactions. If subset X observes Alice commitment transaction and subset
Y observes Bob commitment transaction, Alice's HTLC-timeout spending her
commitment won't propagate beyond the X-Y set boundaries. An attacker can
always win the propagation race through massive connections or bypassing
tx-relay privacy timers.

Miners mempools are likely identifiable, you could announce a series of
conflicting transactions to different subsets of the network and observe
"tainted" block composition to assign to each subset a miner mempool. I'm
not aware of any research on this, but it sounds plausible to identify all
power-miner mempool, i.e the ones likely to mine a block during the block
delay of the timelock you're looking to exploit. If you can't bid a
transaction in such miner mempools your channel state will stale and your
funds may be in danger.

### Scenario 1) HTLC-Preimage Pinning

As Matt previously explained in his original mail on RBF-pinning, a
malicious counterparty has an interest to pin a low-feerate HTLC-preimage
transaction in some network mempools and thus preventing a honest
HTLC-timeout to confirm. For details, refer to Optech newsletter [2].

This scenario doesn't bear any risk to the attacker, is easy to execute and
has double-digit rate of success. You don't assume network topologies
manipulation, mempools partitions or LN-node-to-full-node mapping [3] That
said this should be solved by implementing and deploying anchor outputs,
which effectively allows a party to unilaterally bump feerate of its
HTLC-timeout transactions.

### The Anchor Output Proposal

Anchor Output proposal is a current spec object implemented by the LN dev
community, it introduces the ability to _unilaterally_ and _dynamically_
bump feerate of any commitment transaction. It also opened the way to bump
local 2nd-stage transactions.

Beyond solving scenario 1), it makes LN node safe with regards to
unexpected mempool congestion. If your commitment transaction is stucking
in network mempools you can bump its feerate by attaching a CPFP on the new
`to_local` anchor. If the remote commitment gets stuck in network mempools,
you're able to bump it by attaching a CPFP on the `to_remote` anchor. This
should keep your safe against an unresponsive or lazy counterparty in case
of onchain funds to claim.

IMO, it comes with a trade-off as it introduces a mapping oracle, i.e a
linking vector between a LN node and its full-node. In this case, a spying
node may establish a dummy, low-value channel with a probed LN node, break
it by broadcasting thousands of different versions of the (revoked)
commitment and observes which one broadcast a CPFP first on the p2p layer.
Obviously, you can mitigate it by not chasing after low-value HTLC, but
that is a 

Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-12 Thread Antoine Riard via bitcoin-dev
Hi ZmnSCPxj,

> I have not studied the proposal in close detail yet, but anyway, my main
takeaway roughly is:
>
> * The core of CoinPool is some kind of multiparticipant (N > 2) offchain
update mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun).
>   * The output at each state of the update mechanism is some kind of
splitting construction (which I have not studied in detail).
>   * At each update of the state, all participants must sign off on the
new state.

Overall, that's a really accurate description. I would add you can embed a
funding outpoint of any offchain protocol on the splitting construction,
modulo some timelocks shenanigans.

> In order to hide transfers from the elected WabiSabi server, participants
can maintain two coins in every state, and move coins randomly across the
two coins they own at each state update, in order to hide "real" transfers
from the elected server.

Yes I'm quite sure you can reuse WabiSabi as a communication channel
between participants, assuming you support tapscript and merkle branch
transports, and server build a tree. Generally, we tried to keep design as
flexible as we can to reuse privacy tools.

> Indeed, from what I can understand, in order to properly set up the
splitting transactions in the first place, at each state every participant
needs to know how much each other participant actually owns in the CoinPool
at that point in time.

Yes, that's part of future research, defining better *in-pool* observer.
Sadly, right now, even if you use mask construction inside, it's quite easy
to trace leaves by value weight. Of course, you can enforce equal-value
leaves, as for a regular onchain CoinJoin. I think it comes with a higher
onchain cost in case of pool breakage.

> That way, output addresses can be to fresh pseudonyms of the participant,
removing all linkages of participant to amount they own, and each
participant can maintain multiple outputs per state for their own purposes
and to mildly obscure exactly how much they own in total.

That's right that an in-pool observer may learn a link between an exit and
an onchain withdraw. There is a future optimization, if you can swap your
withdraw with an already onchain output, therefore breaking heuristics.

> We can do this by using `SIGHASH_ANYPREVOUT` to force whoever performs a
unilateral close of the CoinPool to pay the onchain fees involved, so that
it would have to be a good reason indeed to perform a unilateral close.

Absolutely, for the fee structure, as the withdraw output is at the
discretion of user, I was thinking some CPFP. There is maybe a better
solution, haven't spend that much on the exact adequate, incentives-align
mechanism beyond a "withdraw-must-pay-its-fees".

Thanks for the high-quality review, as usual ;)

Antoine

Le ven. 12 juin 2020 à 04:39, ZmnSCPxj  a écrit :

> Good morning Antoine and Gleb,
>
> I have not studied the proposal in close detail yet, but anyway, my main
> takeaway roughly is:
>
> * The core of CoinPool is some kind of multiparticipant (N > 2) offchain
> update mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun).
>   * The output at each state of the update mechanism is some kind of
> splitting construction (which I have not studied in detail).
>   * At each update of the state, all participants must sign off on the new
> state.
>
> It seems to me that it would be possible to use a [WabiSabi protocol](
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017969.html)
> during negotiation of a new state.
>
> Now, WabiSabi is a client-server protocol.
> As all participants in the CoinPool are needed in order to ratify each new
> state anyway, they can simply elect one of their number by drawing lots, to
> act as server for a particular state update.
>
> Then the participants can operate as WabiSabi clients.
> Each participant registers the outputs they currently own in the current
> state, getting credentials that sum up to the correct value.
> Then, during the WabiSabi run, they can exchange credentials among the
> participants in order to perform value transfers inside the WabiSabi
> construction.
> Then, at output registration, they register new outputs to put in the next
> state of the CoinPool.
>
> In order to hide transfers from the elected WabiSabi server, participants
> can maintain two coins in every state, and move coins randomly across the
> two coins they own at each state update, in order to hide "real" transfers
> from the elected server.
>
> Then, after output registration, the participants ratify the new state by
> signing off on the new state and revoking the previous state, using the
> update mechanism.
>
> Of course, we should note that one desired feature for CoinPool in the
> original proposal is that a participant can exit, and the CoinPool would
> still remain valid, but only for the remaining participants.
>
> This is arguably a mild privacy leak: every other participant now knows
> how much that particular participant 

Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-12 Thread Antoine Riard via bitcoin-dev
Hi Jeremy,

For the records, I didn't know between Greg and you was at the origin of
payment pools. Thanks for your pioneer work here, obviously this draws
inspiration from OP_CTV use cases and Channel Factories works, even if we
picked up different assumptions and tried to address another set of issues.

With regards to scalability, I hit it on my own while inquiring
covenanted-Bitcoin contracts for international trade. I mentioned the
any-order issue on such multi-party complex contracts in a talk last summer
(https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf).

> All of these channels can be constructed and set up non-interatively using
> CTV, and updated interactively. By default payments can happen with
minimal
> coordination of parties by standard lightning channel updates at the leaf
> nodes, and channels can be rebalanced at higher layers with more
> participation.

Side review note on OP_CTV: I think it would be great to define
non-interactivity better, namely at least between 3 phases: establishment,
operation, closing.

Even OP_CTV protocols assume interactivity at establishment, at least 1) to
learn payees pubkeys endpoint (and internal leaves pubkeys if you want
update at operation) 2) validate transaction tree correctness between
participants.

At operation, it depends if participants want to dynamically rebalance
value across channels or not. If you desire dynamically rebalancing, assume
internal leaves scriptpubkeys are (multisig-all OR OP_CTV'ed merkle_tree).
Using OP_CTV is a saving in message rounds for every constant expression
across tree updates.

At closing, depends again if participants have committed update keys or
not. If dynamic update, you can prune the whole tree and just commit final
balances onchain, either with a O(N) fan-out transaction (N outputs) or a
O(log(N)) congestion tree (N transactions).

So I would say the originality of a hashchain covenant like OP_CTV is to
provide onchain *immutability* (unforgeability?) of the offchain
transaction tree and thus provides instant finality to payees. You can get
the same semantic with off-chain covenant, pre-signed set of transactions,
assuming more communications rounds and performance hit.

That said, IMO, immutability comes with a security trade-off, namely if any
payout key committed in your OP_CTV tree gets compromised your funds are at
stake. And you can't update the tree anymore at the root to rotate keys. I
think this should be weighted by anyone designing covenant protocols,
especially vaults.

> I don't think the following requirement: "A
> CoinPool must satisfy the following *non-interactive any-order withdrawal*
> property: at any point in time and any possible sequence of previous
> CoinPool events, a participant should be able to move their funds from the
> CoinPool to any address the participant wants without cooperation with
> other CoinPool members." is desirable in O(1) space.

With current design (Pool_tx+Split_tx) it's O(2) space. Pool_tx is similar
to a commitment tx and thus enables off-chain novation of pool distribution.

> Let's be favorable to Accumulators and assume O(1), but keep in mind
constant may
> be somewhat large/operations might be expensive in validation for updates.

Using a Merkle Tree as an accumulator should be constant-size in space, but
likely it has to be O(log(N) in computation (N set elements). This overhead
in computation should be accounted for in accumulator sigops to avoid
network validation resources free-riding, but I think it's a better
trade-off minimizing chain footprint.

> So in this context, CTV Pool has a clear benefit. The last recipient can
> always clear in Log(N) time whereas in the accumulator pool, the last
> recipient has to wait much much longer. There's no asymptotic difference
in
> Tx Size, but I suspect that CTV is at least as good or cheaper since it's
> just one tx hash and doesn't depend on implementation.

Yes I agree CTV pool performs better in the worst-case scenario. In my
opinon what we should really look on is the probability of withdrawal
scenarios. I see 2 failure cases:
* a pool participant being offline, thus halting the pool
* a pool participant with external protocol requirement to fulfill, like a
HTLC to timeout onchain

With regards to 1) we assume that watchtower infra are likely to become
ubiquitous in the future (if you want a secure LN experience), so user
uptime should be near to 100%. Of course,  it's a new architecture which
comes with trade-offs, but interesting to explore.

With regards to 2) as of today channel-failure-rate (like unilateral close)
it's still quite important (30% IIRC) so it plays in favor of OP_CTV pool
but in the future I expect single-digit
therefore making CoinPool far more competitive. Do we envision protocol
more time-sensitive than LN in the future (atomic swaps...) ? Hard to gauge.

Do you see other ways to refine model, like integrating out-of-pool
liquidity needs rate ?

Note, I think 

[bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-11 Thread Antoine Riard via bitcoin-dev
Hi list,

We (Gleb Naumenko + I) think that a wide range of second-layer protocols
(LN, vaults, inheritance, etc) will be used by average Bitcoin users. We
are interested in finding and addressing the privacy issues coming from the
unique fingerprints these protocols bring.

More specifically, we are interested in answering the following questions:
1. How bad are privacy leaks from on-chain txn of second-layer protocols
and how much is leaked via protocol-specific metadatas (LN domain names,
watchtowers, ...) ?
2. How to establish a list of Bitcoin fingerprints and their severity to
inform protocol designers and clarify threat models ?
3. What kind of sophisticated heuristics spies may use in the future ?
4. How to mitigate privacy leaks ? Should each protocol adopt a common
toolbox (scriptless scripts, taproot, ...) in its own way or should we
design a confidential-layer to wrap around all of them ?
5. How to make the solution usable (cheaper, easier to integrate, safer)
for a daily basis ?

We suggest CoinPool: a generic payment pool [0] as a solution to those
problems. Although the design we propose is somewhat a scaling solution, we
won't focus on this aspect. This work is rather an exploration of *how a
pool construction could serve as a TLS for Bitcoin, enhancing both on-chain
and off-chain privacy*.

### Motivation: cross-protocols privacy

It has always been a challenge to make the on-chain UTXO graph more
private. We all know the issues with cleartext amounts, the linkability of
inputs/outputs, and other metadatas. Combining with p2p-level spying
(transaction-to-IP mapping) or some other patterns leading to real-world
identities enable serious spying.

Protocols on top of Bitcoin (LN, vaults[1], complicated spending conditions
based on Miniscript, DLC [2] are even more vulnerable to spying because:
- each of them brings new unique fingerprint/metadata [3]
- known spying techniques against second-layer are currently limited to
trivial heuristics, but we can't assume spies will always this
unsophisticated

There is already a wiki list [4] attempting to cover all issues like that,
although maintaining it would be challenging considering privacy is a
moving target.

Let's consider this example: Alice is a well-known LN merchant with a node
tied to a domain name. She always directs the output of channel closing to
her vault address. If she has another vault address on-chain with the same
unique unlocking script (like a CSV timelock with a specific delta) this
can be leveraged to cluster her transactions. And since one of her
addresses is tied to a domain name, all her funds can now be linked to a
real-world identity.

In theory, one may use CoinJoin-like solutions to mask cross-protocol
on-chain transfers. Unfortunately, robust designs like CoinSwap depend on
timelocking coins, extensive use of the on-chain space, and paying fees to
provide sufficient privacy, as we explain further. These properties imply
we can't expect users to be using strong CoinSwaps by default.

That's why instead of specialized high-latency, high-chain-use
CoinJoin-style protocols, we propose CoinPool: a low-latency, generic
off-chain protocol used to be wrapped around any other protocol. CoinPool
is based on shared UTXO ownership. It may reasonably improve on-chain
privacy while avoiding latency and locked liquidity issues. CoinPool may
also reduce the on-chain use (thus, help to scale Bitcoin) if participants
cooperate sufficiently.

We do believe that CoinSwap and other CoinJoins are of interest, but we
have to consider the trade-offs and choose the best tool for a job to make
privacy usable with regards to user resources. We will compare CoinPool to
CoinSwap in more detail later in this write-up.

### Extra-motivation: on-chain scalability

Even though it's not the main focus of this proposal, we also want to
mention that since CoinPool is a payment pool, it helps with on-chain
scalability. More specifically:
1. Shared UTXO ownership allows to represent many outputs as one, reducing
the UTXO set in size.
2. The CoinPool design enables off-chain transfers within the pool, helping
to save the block space by committing fewer transactions on-chain.
3. CoinPool provides decent support for batching activities from different
users, also helping to have fewer individual transactions on-chain.

Since the CoinPool provides scalability benefits, users will be even
incentivized to join CoinPools due to the conservative chain resources
usage and such enjoy privacy as a side-effect.

### CoinPool design

A CoinPool must satisfy the following *non-interactive any-order
withdrawal* property: at any point in time and any possible sequence of
previous CoinPool events, a participant should be able to move their funds
from the CoinPool to any address the participant wants without cooperation
with other CoinPool members.

The state of a CoinPool is represented by one on-chain UTXO (a funding
multisig of all pool participants) and a set of 

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-11 Thread Antoine Riard via bitcoin-dev
Hi ZmnSCPxj

Well your deeclipser is already WIP ;)

See my AltNet+Watchdog proposals in Core:
https://github.com/bitcoin/bitcoin/pull/18987/https://github.com/bitcoin/bitcoin/pull/18988

It's almost covering what you mention, a driver framework to plug
alternative transports protocols : radio, DNS, even LN Noise, Tor's
Snowflake... Proposal is a PoC with a multi-threaded process but yes I want
production-design to be a multi-process for the reasons you mentioned.
Drivers should be developed out-of-tree but with an interface to plug them
smoothly (tm).

Proposal is more generic than pure LN, like some privacy-concerned users
may want to broadcast by default their transactions over radio. But for LN
support it should a) detect network/block issuance anomalies b) dynamically
react by closing channels or c) fetch headers/blocks through redundant
communication channels and d) provide emergency transactions broadcast if
your time-sensitive transactions are censored.

It's long-term work so be patient but getting opt-in support in Core would
make it far easier for any LN routing/vaulting node to deploy it. In the
meanwhile you can have multiple nodes on different infrastructures to serve
as a backend for your LN node.

Bonus: if LN nodes are incentivized to deploy such strong anti-eclipsing
measures to mitigate time-dilation it would benefit base layer p2p security
network-wise. In case of network partition, your node with link layer
redundancy will keep it in-sync its connected peers on the same side of the
partition, even if they don't deploy anything.

I'm sure you have improvements to suggest !

Best,
Antoine


Le mer. 10 juin 2020 à 19:35, ZmnSCPxj  a écrit :

> Good morning Antoine and Gleb,
>
> One thing I have been idly thinking about would be to have a *separate*
> software daemon that performs de-eclipsing for your Bitcoin fullnode.
>
> For example, you could run this deeclipser on the same hardware as your
> Bitcoin fullnode, and have the deeclipser bind to port 8334.
> Then you set your Bitcoin fullnode with `addnode=localhost:8334` in your
> `bitcoind.conf`.
>
> Your Bitcoin fullnode would then connect to the deeclipser using normal
> P2P protocol.
>
> The deeclipser would periodically, every five minutes or so, check the
> latest headers known by your fullnode, via the P2P protocol connection your
> fullnode makes.
> Then it would attempt to discover any blocks with greater blockheight.
>
> The reason why we have a separate deeclipser process is so that the
> deeclipser can use a plugin system, and isolate the plugins from the main
> fullnode software.
> For example, the deeclipser could query a number of plugins:
>
> * One plugin could just try connecting to some random node, in the hopes
> of getting a new connection that is not eclipsed.
> * Another plugin could try polling known blockchain explorers and using
> their APIs over HTTPS, possibly over Tor as well.
> * Another plugin could try connecting to known Electrum servers.
> * New plugins can be developed for new mitigations, such as sending
> headers over DNS or blocks over mesh or etc.
>
> Then if any plugin discovers a block later than that known by your
> fullnode, the deeclipser can send an unsolicited `block` or `header`
> message to your fullnode to update it.
>
> The advantage of using a plugin system is that it becomes easier to
> prototype, deploy, and maybe even test new de-eclipsing mitigations.
>
> At the same time, by running a separate daemon from the fullnode, we
> provide some amount of process isolation in case some problem with the
> plugin system exists.
> The deeclipser could be run by a completely different user, for example,
> and you might even run multiple deeclipser daemons in the same hardware,
> with different non-overlapping plugins, so that an exploit of one plugin
> will only bring down one deeclipser, with other deeclipser daemons
> remaining functional and still protecting your fullnode.
>
> Finally, by using the P2P protocol, the fullnode you run could be a
> non-Bitcoin-Core fullnode, such as btcd or rust-bitcoin or whatever other
> fullnode implementations exist, assuming you actually want to use them for
> some reason.
>
> What do you think?
>
> Regards,
> ZmnSCPxj
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-07 Thread Antoine Riard via bitcoin-dev
Hi ZmnSCPxj,

> (Of note as well, is that the onchain contract provided by such services
is the same in spirit as those instantiated in channels of the Lightning
Network, thus the same attack schema works on the onchain side.)

If you onchain contract uses a timelock and has concurrent transactions
arbiter by this one , it's subject to time-dilation attack. So yes
submarine swaps, or any kind of atomic swap is concerned. We note this in
discussion.
But you're right for the attack cost, you don't need a channel to these
services, which is also concerning for their attack surface.

> Since the issue here is that eclipsing of Bitcoin nodes is risky, it
strikes me that a mitigation would be to run your Bitcoin fullnode on
clearnet while running your Lightning node over Tor

We clearly mention that risk of running a Bitcoin node over Tor, where do
we recommend running a LN node over Tor ?

>   And this seems to tie with what you propose: that the LN node should
use a different view-fullnode from the broadcast-fullnode.

Yes in Countermeasures - Link layer diversity, specially if it's easy for
an attacker to provoke a transaction broadcast by buying a channel to the
LN node.

> A mitigation to this would be to run a background process which sleeps
for 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.

Yeah instead of having every node operator running their own hacky scripts,
without them being bulletproofs on detection, I'm working on getting such
mitigations directly in Core, easily deployable for everyone.

> The victim *could* instead check that the absolute timelocks seem very
far in the future relative to its own view of the current blockheight.

I think you're right it's really dependent on CLTV_delta deployed on the
path and time-dilation offset. The alternative you're proposing is a good
one, but you shouldn't know where you're in the path and max CLTV is 2048
blocks IIRC.

Thanks for your reading and review,

Cheers,
Antoine

Le mer. 3 juin 2020 à 22:58, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Good morning Gleb and Antoine,
>
> This is good research, thank you for your work.
>
> > **Targeting Per-Hop Packet Delay** is based on routing via the victim,
> and the victim should have at least two channels with the attacker.
>
> The existence of offchain-to-onchain swap services means that the attacker
> needs only build one channel to the victim for this attack to work.
> Rather than route to themselves, the attacker routes to a convenient
> service providing such a swap service, and receives the stolen funds
> onchain, with no need even for an incoming channel from a different node.
> (Of note as well, is that the onchain contract provided by such services
> is the same in spirit as those instantiated in channels of the Lightning
> Network, thus the same attack schema works on the onchain side.)
>
> Indeed, the attack can be mounted on such a service directly.
>
> Even without such a service, the incoming channel need not be directly
> connected to the victim.
>
>
> > [Tor is tricky](https://arxiv.org/abs/1410.6079) too
>
> Since the issue here is that eclipsing of Bitcoin nodes is risky, it
> strikes me that a mitigation would be to run your Bitcoin fullnode on
> clearnet while running your Lightning node over Tor.
> Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on)
> "only" loses you the ability to pay, receive, or route (and thereby earn
> forwarding fees), but as long as your blockchain view is clear, it should
> be fine.
>
> Of course, the Lightning node could still be correlated with the Bitcoin
> node when transactions are broadcast with the attached Bitcoin node (as
> noted in the paper).
> Instead the Lightning node should probably connect, over Tor, to some
> random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
>
> And this seems to tie with what you propose: that the LN node should use a
> different view-fullnode from the broadcast-fullnode.
>
>
> > if a node doesn’t observe a block within the last 30 minutes, it
> attempts to make a new random connection to someone in the network.
>
> A mitigation to this would be to run a background process which sleeps for
> 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
> It might want to `disconnectnode` any previous node it attempted to
> connect to.
>
> However I note that the help for `addnode` contains the text "though such
> peers will not be synced from", which confuses me, since it also refers to
> the `-connect` command line option, and `-connect` means you only connect
> out to the specific nodes, so if those are not synced from huh?
>
> And of course the interesting part is "how do we get a `${BITCOINNODE}`
> that we think is not part of the eclipsing attacker?"
>
>
> > If a Lightning node is behind in its Bitcoin blockchain view, but
> Lightning payments between honest nodes are still flowing through it, this
> node will 

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-17 Thread Antoine Riard via bitcoin-dev
> * At the same time, it retains your-keys-your-coins noncustodiality,
because every update of a Lightning channel requires your keys to sign off
on it.

Yes I agree, I can foresee an easier step where managing low-value channel
and get your familiar with smooth key management maybe a first step before
running a full-node and getting a more full-fledged key management solution.

> It may even be possible, that the Lightning future with massive SPV might
end up with more economic weight in SPV nodes, than in the world without
Lightning and dependent on centralized custodial services to scale.

Even evaluating economic weight in Lightning is hard, both parties have
their own chain view, and it's likely if you assume a hub-and-spoke
topology, leaf nodes are going to be SPV and internal nodes full-nodes ?

> Money makes the world go round, so such backup servers that are
publicly-facing rather than privately-owned should be somehow incentivized
to do so, or else they would not exist in the first place.

I was thinking about the current workflow, Alice downloads her New Shiny
LN-wallet, she is asked to backup the seed, she is asked to pick-up
backup(s) nodes among her friends, relatives or business partners and is
NOT provided any automatic hint and register backup nodes addresses, maybe
even do out-of-band key exchange with this full-node operator. Therefore
you may avoid centralization by having not such publicly-facing servers. Of
course, Alice can still scrawl the web to and be lured to pickup malicious
public servers but if she is severely notified to not do so that may be
enough.

So it would be a combination of UX+user education+fallback security
mechanism to avoid economy hijack. That maybe a better solution rather than
PoW-only SPV. We have an open network so you can't prevent someone to run
such type of client but at least if they have to do so you can provide them
with a better option ?

Antoine




Le jeu. 14 mai 2020 à 00:02, ZmnSCPxj  a écrit :

> Good morning Antoine,
>
>
> > While approaching this question, I think you should consider economic
> weight of nodes in evaluating miner consensus-hijack success. Even if you
> expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the
> same  economic weight at all, therefore even if miners are able to lure a
> majority of SPV clients they may not be able to stir economic nodes. SPV
> clients users will now have an incentive to cancel their hijacked history
> to stay on the most economic meaningful chain. And it's already assumed,
> that if you run a bitcoin business or LN routing node, you do want to run
> your own full-node.
>
> One hope I have for Lightning is that it will replace centralized
> custodial services, because:
>
> * Lightning gains some of the scalability advantage of centralized
> custodial services, because you can now transfer to any Lightning client
> without touching the blockchain, for much reduced transfer fees.
> * At the same time, it retains your-keys-your-coins noncustodiality,
> because every update of a Lightning channel requires your keys to sign off
> on it.
>
> If most Lightning clients are SPV, then if we compare these two worlds:
>
> * There are a few highly-important centralized custodial services with
> significant economic weight running fullnodes (i.e. now).
> * There are no highly-important centralized custodial services, and most
> everyone uses Lightning, but with SPV (i.e. a Lightning future).
>
> Then the distribution of economic weight would be different between these
> two worlds.
> It may even be possible, that the Lightning future with massive SPV might
> end up with more economic weight in SPV nodes, than in the world without
> Lightning and dependent on centralized custodial services to scale.
>
>
> It is also entirely possible that custodial services for Lightning will
> arise anyway and my hope is already dashed, come on universe, work harder
> will you, would you really disappoint some randomly-generated Internet
> person like that.
>
>
> >
> > I agree it may be hard to evaluate economic-weight-to-chain-backend
> segments, specially with offchain you disentangle an onchain output value
> from its real payment traffic. To strengthen SPV, you may implement forks
> detection and fallback to some backup node(s) which would serve as an
> authoritative source to arbiter between branches. Such backup node(s) must
> be picked up manually at client initialization, before any risk of conflict
> to avoid Reddit-style of hijack during contentious period or other massive
> social engineering. You don't want autopilot-style of recommendations for
> picking up a backup nodes and avoid cenralization of backups, but somehow a
> uniform distribution. A backup node may be a private one, it won't serve
> you any data beyond headers, and therefore you preserve public nodes
> bandwidth, which IMO is the real bottleneck. I concede it won't work well
> if you have a ratio of 1000-SPV for 1-full-node and 

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-13 Thread Antoine Riard via bitcoin-dev
Hi Chris,

While approaching this question, I think you should consider economic
weight of nodes in evaluating miner consensus-hijack success. Even if you
expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the
same  economic weight at all, therefore even if miners are able to lure a
majority of SPV clients they may not be able to stir economic nodes. SPV
clients users will now have an incentive to cancel their hijacked history
to stay on the most economic meaningful chain. And it's already assumed,
that if you run a bitcoin business or LN routing node, you do want to run
your own full-node.

I agree it may be hard to evaluate economic-weight-to-chain-backend
segments, specially with offchain you disentangle an onchain output value
from its real payment traffic. To strengthen SPV, you may implement forks
detection and fallback to some backup node(s) which would serve as an
authoritative source to arbiter between branches. Such backup node(s) must
be picked up manually at client initialization, before any risk of conflict
to avoid Reddit-style of hijack during contentious period or other massive
social engineering. You don't want autopilot-style of recommendations for
picking up a backup nodes and avoid cenralization of backups, but somehow a
uniform distribution. A backup node may be a private one, it won't serve
you any data beyond headers, and therefore you preserve public nodes
bandwidth, which IMO is the real bottleneck. I concede it won't work well
if you have a ratio of 1000-SPV for 1-full-node and people are not
effectively able to pickup a backup among their social environment.

What do you think about this model ?

Cheers,

Antoine

Le mar. 12 mai 2020 à 17:06, Chris Belcher  a écrit :

> On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote:
> > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> >>> Trust-minimization of Bitcoin security model has always relied first
> and
> >>> above on running a full-node. This current paradigm may be shifted by
> LN
> >>> where fast, affordable, confidential, censorship-resistant payment
> >> services
> >>> may attract a lot of adoption without users running a full-node.
> >>
> >> No, it cannot be shifted. This would compromise Bitcoin itself, which
> for
> >> security depends on the assumption that a supermajority of the economy
> is
> >> verifying their incoming transactions using their own full node.
> >>
> >
> > Hi Luke,
> >
> > I have heard this claim made several times but have never understood the
> > argument behind it. The question I always have is: If I get scammed by
> not
> > verifying my incoming transactions properly how can this affect anyone
> > else? It's very unintuative.  I've been scammed several times in my life
> in
> > fiat currency transactions but as far as I could tell it never negatively
> > affected the currency overall!
> >
> > The links you point and from what I've seen you say before refer to
> "miner
> > control" as the culprit. My only thought is that this is because a light
> > client could follow a dishonest majority of hash power chain. But this
> just
> > brings me back to the question. If, instead of BTC, I get a payment in
> some
> > miner scamcoin on their dishonest fork (but I think it's BTC because I'm
> > running a light client) that still seems to only to damage me. Where does
> > the side effect onto others on the network come from?
> >
> > Cheers,
> >
> > LL
> >
>
> Hello Lloyd,
>
> The problem comes when a large part of the ecosystem gets scammed at
> once, which is how such an attack would happen in practice.
>
> For example, consider if bitcoin had 1 users. 10 of them use a full
> node wallet while the other 9990 use an SPV wallet. If a miner attacked
> the system by printing infinite bitcoins and spending coins without a
> valid signature, then the 9990 SPV wallets would accept those fake coins
> as payment, and trade the coins amongst themselves. After a time those
> coins would likely be the ancestors of most active coins in the
> 9990-SPV-wallet ecosystem. Bitcoin would split into two currencies:
> full-node-coin and SPV-coin.
>
> Now the fraud miners may become well known, perhaps being published on
> bitcoin news portals, but the 9990-SPV-wallet ecosystem has a strong
> incentive to be against any rollback. Their recent transactions would
> disappear and they'd lose money. They would argue that they've already
> been using the coin for a while, and it works perfectly fine, and

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-09 Thread Antoine Riard via bitcoin-dev
Hi Christopher,

Thanks for Blockchain Commons and Learning Bitcoin from the Command Line!

> If there are people interested in coordinating some proposals on how to
defining different sets of wallet functionality, Blockchain Commons would
be interested in hosting that collaboration. This could start as just being
a transparent shim between bitcoin-core & remote RPC, but later could
inform proposals for the future of the core wallet functionality as it gets
refactored.

Yes generally refactoring in Core wallets are making good progress [0]. I'm
pretty sure feedbacks and proposals on future changes with regards to
usability would be greatly appreciated.

Maybe you can bring these during a IRC meeting ?

Antoine

[0] See https://github.com/bitcoin/bitcoin/pull/16528 or
https://github.com/bitcoin/bitcoin/pull/16426

Le ven. 8 mai 2020 à 17:31, Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Perhaps I wasn't explicit in my previous note but what I mean is that
>> there seems to be a demand for something *in between* a peer interface,
>> and an owner interface. I have little opinion as to whether this belongs in
>> core or not, I think there are much more experienced folks who can weight
>> in on that, but without something like this, you cannot limit your exposure
>> for serving something like bip157 filters without removing your own ability
>> to make use of some of those same services.
>>
>
> Our FullyNoded2 multisig wallet on iOS & Mac, communicates with your own
> personal node over RPC, securing the connection using Tor over a hidden
> onion service and two-way client authentication using a v3 Tor
> Authentication key: https://github.com/BlockchainCommons/FullyNoded-2
>
> It many ways the app (and its predecessor FullyNoded1) is an interface
> between a personal full node and a user.
>
> However, we do wish that the full RPC functionality was not exposed in
> bitcoin-core. I’d love to see a cryptographic capability mechanism such
> that the remote wallet could only m ask the node functions that it needs,
> and allow escalation for other rarer services it needs with addition
> authorization.
>
> This capability mechanism feature set should go both ways, to a minimum
> subset needed for being a watch-only transaction verification tool, all the
> way to things RPC can’t do like deleting a wallet and changing bitcoin.conf
> parameters and rebooting, without requiring full ssh access to the server
> running the node.
>
> If there are people interested in coordinating some proposals on how to
> defining different sets of wallet functionality, Blockchain Commons would
> be interested in hosting that collaboration. This could start as just being
> a transparent shim between bitcoin-core & remote RPC, but later could
> inform proposals for the future of the core wallet functionality as it gets
> refactored.
>
> — Christopher Allen
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-09 Thread Antoine Riard via bitcoin-dev
Hi Igor,

Thanks for sharing about what it's technically possible to do for a
full-node on phone, specially with regards to lower grade devices.

I do see 2 limitations for sleeping nodes:
- a lightning specific one, i.e you need to process block data real-time in
case of incoming HTLC you need to claim on chain or a HTLC timeout. There
is a bunch of timelocks implications in LN,  with regards to CSV,
CLTV_DELTA, incoming policy, outgoing policy, ... and you can't really
afford to be late without loosing a payment. I don't see timelocks being
increase, that would hinder liquidity.
- a p2p bandwidth concern, even if this new class of nodes turn as public
ones, they would still have a heavy sync period due to be fallen-behind
during the day, so you would have huge bandwidth spikes every a timezone
falls asleep and a risk of choking upload links of stable full-nodes.

I think assume-utxo may be interesting in the future in case of long-fork
detection, you may be able to download a utxo-set on the fly, and fall-back
to a full-node. But that would be only an emergency measure, not a regular
cost on the backbone network.

Antoine


Le jeu. 7 mai 2020 à 12:41, Igor Cota  a écrit :

> Hi Antoine et al,
>
> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
>> just rely on few thousands of full-node operators being nice and servicing
>> friendly millions of LN mobiles clients. But just in case it may be good to
>> consider a reasonable alternative.
>>
>
>
>> So you may want to separate control/data plane, get filters from CDN and
>> headers as check-and-control directly from the backbone network. "Hybrid"
>> models should clearly be explored.
>
>
> For some months now I've been exploring the feasibility of running full
> nodes on everyday phones [1]. One of my first thoughts was how to avoid the
> phones mooching off the network. Obviously due to battery, storage and
> bandwidth constraints it is not reasonable to expect pocket full nodes to
> serve blocks during day time.
>
> Huge exception to this is the time we are asleep and our phones are
> connected to wifi and charging. IMO this is a huge untapped resource that
> would allow mobile nodes to earn their keep. If we limit full node
> operation to sleepy night time the only constraining resource is storage:
> 512 gb of internal storage in phones is quite rare, probably about $100 for
> an SD card with full archival node capacity but phones with memory card
> slots rarer still - no one is going to bother.
>
> So depending on their storage capacity phone nodes could decide to store
> and serve just a randomly selected range of blocks during their nighttime
> operation. With trivial changes to P2P they could advertise the blocks they
> are able to serve.
> If there comes a time that normal full nodes feel DoS'ed they can
> challenge such nodes to produce the blocks they advertise and ban them as
> moochers if they fail to do so. Others may elect to be more charitable and
> serve everyone.
>
> These types of nodes would truly be part-timing since they only carry a
> subset of the blockchain and work while their operator is asleep. Probably
> should be called part-time or Sleeper Nodes™.
>
> They could be user friendly as well, with Assume UTXO they could be
> bootstrapped quickly and while they do the IBD in the background instead of
> traditional pruning they can keep the randomly assigned bit of blockchain
> to later serve the network.
>
> Save for the elderly, all the people I know could run such a node, and I
> don't live in a first world country.
>
> There is also the feel-good kumbaya aspect of American phone nodes serving
> the African continent while the Americans are asleep, Africans and
> Europeans serving the Asians in kind. By plugging in our phones and going
> to sleep we could blanket the whole world in (somewhat) full nodes!
>
> Cheers,
> Igor
>
> [1] https://icota.github.io/
>
> On Tue, 5 May 2020 at 12:18, Antoine Riard 
> wrote:
>
>> Hi,
>>
>> (cross-posting as it's really both layers concerned)
>>
>> Ongoing advancement of BIP 157 implementation in Core maybe the
>> opportunity to reflect on the future of light client protocols and use this
>> knowledge to make better-informed decisions about what kind of
>> infrastructure is needed to support mobile clients at large scale.
>>
>> Trust-minimization of Bitcoin security model has always relied first and
>> above on running a full-node. This current paradigm may be shifted by LN
>> where fast, affordable, confidential, censorship-resistant payment services
>> may attract a lot of adoption without users running a full-node. Assuming a
>> user adoption path where a full-node is required to benefit for LN may
>> deprive a lot of users, especially those who are already denied a real
>> financial infrastructure access. It doesn't mean we shouldn't foster node
>> adoption when people are able to do so, and having a LN wallet maybe even a
>> first-step to it.
>>
>> Designing a 

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-07 Thread Antoine Riard via bitcoin-dev
What I'm thinking more is if the costs of security are being too much
externalized from the light clients onto full nodes, nodes operators are
just going to stop servicing light clients `peercfilters=false`. The
backbone p2p network is going to be fine. But the massive LN light clients
network built on top is going to rely on centralized services for its chain
access and now you may have consensus capture by those..

Le mer. 6 mai 2020 à 12:00, Keagan McClelland 
a écrit :

> Hi Antoine,
>
> Consensus capture by miners isn't the only concern here. Consensus capture
> by any subset of users whose interests diverge from the overall consensus
> is equally damaging. The scenario I can imagine here is that the more light
> clients outpace full nodes, the more the costs of security are being
> externalized from the light clients onto the full nodes. In this situation,
> it can make full nodes harder to run. If they are harder to run it will
> price out some marginal set of full node operators, which causes a net new
> increase in light clients (as the disaffected full nodes convert), AND a
> redistribution of load onto a smaller surface area. This is a naturally
> unstable process. It is safe to say that as node counts drop, the set of
> node operators will increasingly represent economic actors with extreme
> weight. The more this process unfolds, the more likely their interests will
> diverge from the population at large, and also the more likely they can be
> coerced into behavior they otherwise wouldn't. After all it is easier to
> find agents who carry lots of economic weight. This is true independent of
> their mining status, we should be just as wary of consensus capture by
> exchanges or HNWI's as we are about miners.
>
> Keagan
>
> On Wed, May 6, 2020 at 3:06 AM Antoine Riard 
> wrote:
>
>> I do see the consensus capture argument by miners but in reality isn't
>> this attack scenario have a lot of assumptions on topology an deployment ?
>>
>> For such attack to succeed you need miners nodes to be connected to
>> clients to feed directly the invalid headers and if these ones are
>> connected to headers/filters gateways, themselves doing full-nodes
>> validation invalid chain is going to be sanitized out ?
>>
>> Sure now you trust these gateways, but if you have multiple connections
>> to them and can guarantee they aren't run by the same entity, that maybe an
>> acceptable security model, depending of staked amount and your
>> expectations. I more concerned of having a lot of them and being
>> diversified enough to avoid collusion between gateways/chain access
>> providers/miners.
>>
>> But even if you light clients is directly connected to the backbone
>> network and may be reached by miners you can implement fork anomalies
>> detection and from then you may have multiples options:
>> * halt the wallet, wait for human intervention
>> * fallback connection to a trusted server, authoritative on your chain
>> view
>> * invalidity proofs?
>>
>> Now I agree you need a wide-enough, sane backbone network to build on
>> top, and we should foster node adoption as much as we can.
>>
>> Le mar. 5 mai 2020 à 09:01, Luke Dashjr  a écrit :
>>
>>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>> > Trust-minimization of Bitcoin security model has always relied first
>>> and
>>> > above on running a full-node. This current paradigm may be shifted by
>>> LN
>>> > where fast, affordable, confidential, censorship-resistant payment
>>> services
>>> > may attract a lot of adoption without users running a full-node.
>>>
>>> No, it cannot be shifted. This would compromise Bitcoin itself, which
>>> for
>>> security depends on the assumption that a supermajority of the economy
>>> is
>>> verifying their incoming transactions using their own full node.
>>>
>>> The past few years has seen severe regressions in this area, to the
>>> point
>>> where Bitcoin's future seems quite bleak. Without serious improvements
>>> to the
>>> full node ratio, Bitcoin is likely to fail.
>>>
>>> Therefore, all efforts to improve the "full node-less" experience are
>>> harmful,
>>> and should be actively avoided. BIP 157 improves privacy of fn-less
>>> usage,
>>> while providing no real benefits to full node users (compared to more
>>> efficient protocols like Stratum/Electrum).
>>>
>>> For this reason, myself and a few others oppose merging support for BIP
>>> 157 in
>>> Core.
>&g

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-06 Thread Antoine Riard via bitcoin-dev
> As a result, the entire protocol could be served over something like
HTTP, taking advantage of all the established CDNs and anycast serving
infrastructure,

Yes it's moving the issue of being a computation one to a distribution one.
But still you need the bandwidth capacities. What I'm concerned is the
trust model of relying on few-establish CDNs, you don't want to make it
easy to have "headers-routing" hijack and therefore having massive channel
closure or time-locks interference due to LN clients not seeing the last
few block. So you may want to separate control/data plane, get filters from
CDN and headers as check-and-control directly from the backbone network.
"Hybrid" models should clearly be explored.

Web-of-trust style of deployments should be also envisioned, you may get
huge scaling improvement, assuming client may be peers between themselves
and the ones belonging to the same social entity should be able to share
the same chain view without too much risk.

> Piggy backing off the above idea, if the data starts being widely served
over HTTP, then LSATs[1][2] can be used to add a lightweight payment
mechanism by inserting a new proxy server in front of the filter/header
infrastructure.

Yeah, I hadn't time to read the spec yet but that was clearly something
like LSATs I meaned speaking about monetary compensation to price
resources. I just hope it isn't too much tie to HTTP because you may want
to read/write over other communication channels like
tx-broadcast-over-radio to solve first-hop privacy.

Le mar. 5 mai 2020 à 20:31, Olaoluwa Osuntokun  a écrit :

> Hi Antoine,
>
> > Even with cheaper, more efficient protocols like BIP 157, you may have a
> > huge discrepancy between what is asked and what is offered. Assuming 10M
> > light clients [0] each of them consuming ~100MB/month for
> filters/headers,
> > that means you're asking 1PB/month of traffic to the backbone network. If
> > you assume 10K public nodes, like today, assuming _all_ of them opt-in to
> > signal BIP 157, that's an increase of 100GB/month for each. Which is
> > consequent with regards to the estimated cost of 350GB/month for running
> > an actual public node
>
> One really dope thing about BIP 157+158, is that the protocol makes serving
> light clients now _stateless_, since the full node doesn't need to perform
> any unique work for a given client. As a result, the entire protocol could
> be served over something like HTTP, taking advantage of all the established
> CDNs and anycast serving infrastructure, which can reduce syncing time
> (less latency to
> fetch data) and also more widely distributed the load of light clients
> using
> the existing web infrastructure. Going further, with HTTP/2's server-push
> capabilities, those serving this data can still push out notifications for
> new headers, etc.
>
> > Therefore, you may want to introduce monetary compensation in exchange of
> > servicing filters. Light client not dedicating resources to maintain the
> > network but free-riding on it, you may use their micro-payment
> > capabilities to price chain access resources [3]
>
> Piggy backing off the above idea, if the data starts being widely served
> over HTTP, then LSATs[1][2] can be used to add a lightweight payment
> mechanism by inserting a new proxy server in front of the filter/header
> infrastructure. The minted tokens themselves may allow a user to purchase
> access to a single header/filter, a range of them in the past, or N headers
> past the known chain tip, etc, etc.
>
> -- Laolu
>
> [1]: https://lsat.tech/
> [2]: https://lightning.engineering/posts/2020-03-30-lsat/
>
>
> On Tue, May 5, 2020 at 3:17 AM Antoine Riard 
> wrote:
>
>> Hi,
>>
>> (cross-posting as it's really both layers concerned)
>>
>> Ongoing advancement of BIP 157 implementation in Core maybe the
>> opportunity to reflect on the future of light client protocols and use this
>> knowledge to make better-informed decisions about what kind of
>> infrastructure is needed to support mobile clients at large scale.
>>
>> Trust-minimization of Bitcoin security model has always relied first and
>> above on running a full-node. This current paradigm may be shifted by LN
>> where fast, affordable, confidential, censorship-resistant payment services
>> may attract a lot of adoption without users running a full-node. Assuming a
>> user adoption path where a full-node is required to benefit for LN may
>> deprive a lot of users, especially those who are already denied a real
>> financial infrastructure access. It doesn't mean we shouldn't foster node
>> adoption when people are able to do so, and having a LN wallet maybe even a
>> first-step to it.
>>
>> Designing a mobile-first LN experience opens its own gap of challenges
>> especially in terms of security and privacy. The problem can be scoped as
>> how to build a scalable, secure, private chain access backend for millions
>> of LN clients ?
>>
>> Light client protocols for LN exist (either BIP157 or Electrum 

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-06 Thread Antoine Riard via bitcoin-dev
> The choice between whether we offer them a light client technology that
is better or worse for privacy and scalability.

And offer them a solution which would scale in the long-term.

Again it's not an argumentation against BIP 157 protocol in itself, the
problem I'm interested in is how implementing BIP157 in Core will address
this issue ?

Le mar. 5 mai 2020 à 13:36, John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> There doesn't seem to be anything in the original email that's specific to
> BIP 157. It's a restatement of the arguments against light clients:
>
> - light clients are a burden on the full nodes that serve them
> - if light clients become more popular, there won't be enough full nodes
> to serve them
> - people might build products that depend on altruistic nodes serving
> data, which is unsustainable
> - maybe at some point in the future, light clients will need to pay for
> services
>
> The choice isn't between people using light clients or not. People already
> use light clients. The choice between whether we offer them a light client
> technology that is better or worse for privacy and scalability.
>
> The arguments for why BIP 157 is better than the existing light client
> technologies are available elsewhere, but to summarize:
>
> - they're unique for a block, which means they can easily be cached.
> Serving a filter requires no computation, just i/o (or memory access for
> cached filter/header data) and bandwidth. There are plenty of other
> services that a full node offers that use i/o and bandwidth, such as
> serving blocks.
> - unique-for-block means clients can download from multiple sources
> - the linked-headers/filters model allows hybrid approaches, where headers
> checkpoints can be fetched from trusted/signed nodes, with intermediate
> headers and filters fetched from untrusted sources
> - less possibilities to DoS/waste resources on the serving node
> - better for privacy
>
> > The intention, as I understood it, of putting BIP157 directly into
> bitcoind was to essentially force all `bitcoind` users to possibly service
> BIP157 clients
>
> Please. No-one is forcing anyone to do anything. To serve filters, a node
> user needs to download the latest version, set `-blockfilterindex=basic` to
> build the compact filters index, and set `-peercfilters` to serve them over
> P2P. This is an optional, off-by-default feature.
>
> Regards,
> John
>
>
> On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning ariard and luke-jr
>>
>>
>> > > Trust-minimization of Bitcoin security model has always relied first
>> and
>> > > above on running a full-node. This current paradigm may be shifted by
>> LN
>> > > where fast, affordable, confidential, censorship-resistant payment
>> services
>> > > may attract a lot of adoption without users running a full-node.
>> >
>> > No, it cannot be shifted. This would compromise Bitcoin itself, which
>> for
>> > security depends on the assumption that a supermajority of the economy
>> is
>> > verifying their incoming transactions using their own full node.
>> >
>> > The past few years has seen severe regressions in this area, to the
>> point
>> > where Bitcoin's future seems quite bleak. Without serious improvements
>> to the
>> > full node ratio, Bitcoin is likely to fail.
>> >
>> > Therefore, all efforts to improve the "full node-less" experience are
>> harmful,
>> > and should be actively avoided. BIP 157 improves privacy of fn-less
>> usage,
>> > while providing no real benefits to full node users (compared to more
>> > efficient protocols like Stratum/Electrum).
>> >
>> > For this reason, myself and a few others oppose merging support for BIP
>> 157 in
>> > Core.
>>
>> BIP 157 can be implemented as a separate daemon that processes the blocks
>> downloaded by an attached `bitcoind`, i.e. what Wasabi does.
>>
>> The intention, as I understood it, of putting BIP157 directly into
>> bitcoind was to essentially force all `bitcoind` users to possibly service
>> BIP157 clients, in the hope that a BIP157 client can contact any arbitrary
>> fullnode to get BIP157 service.
>> This is supposed to improve to the situation relative to e.g. Electrum,
>> where there are far fewer Electrum servers than fullnodes.
>>
>> Of course, as ariard computes, deploying BIP157 could lead to an
>> effective DDoS on the fullnode network if a large number of BIP157 clients
>> arise.
>> Though maybe this will not occur very fast?  We hope?
>>
>> It seems to me that the thing that *could* be done would be to have
>> watchtowers provide light-client services, since that seems to be the major
>> business model of watchtowers, as suggested by ariard as well.
>> This is still less than ideal, but maybe is better than nothing.
>>
>> Regards,
>> ZmnSCPxj
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> 

Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-06 Thread Antoine Riard via bitcoin-dev
I do see the consensus capture argument by miners but in reality isn't this
attack scenario have a lot of assumptions on topology an deployment ?

For such attack to succeed you need miners nodes to be connected to clients
to feed directly the invalid headers and if these ones are connected to
headers/filters gateways, themselves doing full-nodes validation invalid
chain is going to be sanitized out ?

Sure now you trust these gateways, but if you have multiple connections to
them and can guarantee they aren't run by the same entity, that maybe an
acceptable security model, depending of staked amount and your
expectations. I more concerned of having a lot of them and being
diversified enough to avoid collusion between gateways/chain access
providers/miners.

But even if you light clients is directly connected to the backbone network
and may be reached by miners you can implement fork anomalies detection and
from then you may have multiples options:
* halt the wallet, wait for human intervention
* fallback connection to a trusted server, authoritative on your chain view
* invalidity proofs?

Now I agree you need a wide-enough, sane backbone network to build on top,
and we should foster node adoption as much as we can.

Le mar. 5 mai 2020 à 09:01, Luke Dashjr  a écrit :

> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment
> services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, which for
> security depends on the assumption that a supermajority of the economy is
> verifying their incoming transactions using their own full node.
>
> The past few years has seen severe regressions in this area, to the point
> where Bitcoin's future seems quite bleak. Without serious improvements to
> the
> full node ratio, Bitcoin is likely to fail.
>
> Therefore, all efforts to improve the "full node-less" experience are
> harmful,
> and should be actively avoided. BIP 157 improves privacy of fn-less usage,
> while providing no real benefits to full node users (compared to more
> efficient protocols like Stratum/Electrum).
>
> For this reason, myself and a few others oppose merging support for BIP
> 157 in
> Core.
>
> > Assuming a user adoption path where a full-node is required to benefit
> for
> > LN may deprive a lot of users, especially those who are already denied a
> > real financial infrastructure access.
>
> If Bitcoin can't do it, then Bitcoin can't do it.
> Bitcoin can't solve *any* problem if it becomes insecure itself.
>
> Luke
>
> P.S. See also
>
> https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
>
> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-06 Thread Antoine Riard via bitcoin-dev
I didn't trust myself and verify. In fact the [3] is the real [2].

Le mar. 5 mai 2020 à 06:28, Andrés G. Aragoneses  a
écrit :

> Hey Antoine, just a small note, [3] is missing in your footnotes, can you
> add it? Thanks
>
> On Tue, 5 May 2020 at 18:17, Antoine Riard 
> wrote:
>
>> Hi,
>>
>> (cross-posting as it's really both layers concerned)
>>
>> Ongoing advancement of BIP 157 implementation in Core maybe the
>> opportunity to reflect on the future of light client protocols and use this
>> knowledge to make better-informed decisions about what kind of
>> infrastructure is needed to support mobile clients at large scale.
>>
>> Trust-minimization of Bitcoin security model has always relied first and
>> above on running a full-node. This current paradigm may be shifted by LN
>> where fast, affordable, confidential, censorship-resistant payment services
>> may attract a lot of adoption without users running a full-node. Assuming a
>> user adoption path where a full-node is required to benefit for LN may
>> deprive a lot of users, especially those who are already denied a real
>> financial infrastructure access. It doesn't mean we shouldn't foster node
>> adoption when people are able to do so, and having a LN wallet maybe even a
>> first-step to it.
>>
>> Designing a mobile-first LN experience opens its own gap of challenges
>> especially in terms of security and privacy. The problem can be scoped as
>> how to build a scalable, secure, private chain access backend for millions
>> of LN clients ?
>>
>> Light client protocols for LN exist (either BIP157 or Electrum are used),
>> although their privacy and security guarantees with regards to
>> implementation on the client-side may still be an object of concern
>> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
>> estimation). That said, one of the bottlenecks is likely the number of
>> full-nodes being willingly to dedicate resources to serve those clients.
>> It's not about _which_ protocol is deployed but more about _incentives_ for
>> node operators to dedicate long-term resources to client they have lower
>> reasons to care about otherwise.
>>
>> Even with cheaper, more efficient protocols like BIP 157, you may have a
>> huge discrepancy between what is asked and what is offered. Assuming 10M
>> light clients [0] each of them consuming ~100MB/month for filters/headers,
>> that means you're asking 1PB/month of traffic to the backbone network. If
>> you assume 10K public nodes, like today, assuming _all_ of them opt-in to
>> signal BIP 157, that's an increase of 100GB/month for each. Which is
>> consequent with regards to the estimated cost of 350GB/month for running an
>> actual public node. Widening full-node adoption, specially in term of
>> geographic distribution means as much as we can to bound its operational
>> cost.
>>
>> Obviously,  deployment of more efficient tx-relay protocol like Erlay
>> will free up some resources but it maybe wiser to dedicate them to increase
>> health and security of the backbone network like deploying more outbound
>> connections.
>>
>> Unless your light client protocol is so ridiculous cheap to rely on
>> niceness of a subset of node operators offering free resources, it won't
>> scale. And it's likely you will always have a ratio disequilibrium between
>> numbers of clients and numbers of full-node, even worst their growth rate
>> won't be the same, first ones are so much easier to setup.
>>
>> It doesn't mean servicing filters for free won't work for now, numbers of
>> BIP157 clients is still pretty low, but what is worrying is  wallet vendors
>> building such chain access backend, hitting a bandwidth scalability wall
>> few years from now instead of pursuing better solutions. And if this
>> happen, maybe suddenly, isn't the quick fix going to be to rely on
>> centralized services, so much easier to deploy ?
>>
>> Of course, it may be brought that actually current full-node operators
>> don't get anything back from servicing blocks, transactions, addresses...
>> It may be replied that you have an indirect incentive to participate in
>> network relay and therefore guarantee censorship-resistance, instead of
>> directly connecting to miners. You do have today ways to select your
>> resources exposure like pruning, block-only or being private but the wider
>> point is the current (non?)-incentives model seems to work for the base
>> layer. For light clients data, are node operators going to be satisfied to
>> serve this new *class* of traffic en masse ?
>>
>> This doesn't mean you won't find BIP157 servers, ready to serve you with
>> unlimited credit, but it's more likely their intentions maybe not aligned,
>> like spying on your transaction broadcast or block fetched. And you do want
>> peer diversity to avoid every BIP157 servers being on few ASNs for
>> fault-tolerance. Do people expect a scenario a la Cloudflare, where
>> everyone connections is to far or less the same set of entities ?

[bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread Antoine Riard via bitcoin-dev
Hi,

(cross-posting as it's really both layers concerned)

Ongoing advancement of BIP 157 implementation in Core maybe the opportunity
to reflect on the future of light client protocols and use this knowledge
to make better-informed decisions about what kind of infrastructure is
needed to support mobile clients at large scale.

Trust-minimization of Bitcoin security model has always relied first and
above on running a full-node. This current paradigm may be shifted by LN
where fast, affordable, confidential, censorship-resistant payment services
may attract a lot of adoption without users running a full-node. Assuming a
user adoption path where a full-node is required to benefit for LN may
deprive a lot of users, especially those who are already denied a real
financial infrastructure access. It doesn't mean we shouldn't foster node
adoption when people are able to do so, and having a LN wallet maybe even a
first-step to it.

Designing a mobile-first LN experience opens its own gap of challenges
especially in terms of security and privacy. The problem can be scoped as
how to build a scalable, secure, private chain access backend for millions
of LN clients ?

Light client protocols for LN exist (either BIP157 or Electrum are used),
although their privacy and security guarantees with regards to
implementation on the client-side may still be an object of concern
(aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
estimation). That said, one of the bottlenecks is likely the number of
full-nodes being willingly to dedicate resources to serve those clients.
It's not about _which_ protocol is deployed but more about _incentives_ for
node operators to dedicate long-term resources to client they have lower
reasons to care about otherwise.

Even with cheaper, more efficient protocols like BIP 157, you may have a
huge discrepancy between what is asked and what is offered. Assuming 10M
light clients [0] each of them consuming ~100MB/month for filters/headers,
that means you're asking 1PB/month of traffic to the backbone network. If
you assume 10K public nodes, like today, assuming _all_ of them opt-in to
signal BIP 157, that's an increase of 100GB/month for each. Which is
consequent with regards to the estimated cost of 350GB/month for running an
actual public node. Widening full-node adoption, specially in term of
geographic distribution means as much as we can to bound its operational
cost.

Obviously,  deployment of more efficient tx-relay protocol like Erlay will
free up some resources but it maybe wiser to dedicate them to increase
health and security of the backbone network like deploying more outbound
connections.

Unless your light client protocol is so ridiculous cheap to rely on
niceness of a subset of node operators offering free resources, it won't
scale. And it's likely you will always have a ratio disequilibrium between
numbers of clients and numbers of full-node, even worst their growth rate
won't be the same, first ones are so much easier to setup.

It doesn't mean servicing filters for free won't work for now, numbers of
BIP157 clients is still pretty low, but what is worrying is  wallet vendors
building such chain access backend, hitting a bandwidth scalability wall
few years from now instead of pursuing better solutions. And if this
happen, maybe suddenly, isn't the quick fix going to be to rely on
centralized services, so much easier to deploy ?

Of course, it may be brought that actually current full-node operators
don't get anything back from servicing blocks, transactions, addresses...
It may be replied that you have an indirect incentive to participate in
network relay and therefore guarantee censorship-resistance, instead of
directly connecting to miners. You do have today ways to select your
resources exposure like pruning, block-only or being private but the wider
point is the current (non?)-incentives model seems to work for the base
layer. For light clients data, are node operators going to be satisfied to
serve this new *class* of traffic en masse ?

This doesn't mean you won't find BIP157 servers, ready to serve you with
unlimited credit, but it's more likely their intentions maybe not aligned,
like spying on your transaction broadcast or block fetched. And you do want
peer diversity to avoid every BIP157 servers being on few ASNs for
fault-tolerance. Do people expect a scenario a la Cloudflare, where
everyone connections is to far or less the same set of entities ?

Moreover, the LN security model diverges hugely from basic on-chain
transactions. Worst-case attack on-chain a malicious light client server
showing a longest, invalid, PoW-signed chain to double-spend the user. On
LN, the *liveliness* requirement means the entity owning your view of the
chain can lie to you on whether your channel has been spent by a revoked
commitment, the real tip of the blockchain or even dry-up block
announcement to trigger unexpected behavior in the client logic. A
malicious 

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Antoine Riard via bitcoin-dev
> In that case, would it be worth re-implementing something like a BIP61
reject message but with an extension that returns the txids of any
conflicts?

That's an interesting idea, but an attacker can create a local conflict in
your mempool
and then send the preimage tx to make hit recentRejects until next tip so
when the rejection code with conflict is received transaction isn't going
to be fetched.
Of course you can make an exception for this, but seems a DoS vector...

And also if you have a private full-node and connect only to 8 outbounds,
an attacker
can do a bit of tx-relay topology discovery and blind your tx-relay peers
too...

I think p2p/mempool hardening measures will only make attack harder but not
erase it, we
should avoid tie too much the security model of Lightning on a given p2p
topology. If you don't
do manual peering (whitelist,addnode), this one may change without
visibility (like stale tip).



Le mer. 22 avr. 2020 à 14:25, David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev
> wrote:
> > A lightning counterparty (C, who received the HTLC from B, who
> > received it from A) today could, if B broadcasts the commitment
> > transaction, spend an HTLC using the preimage with a low-fee,
> > RBF-disabled transaction.  After a few blocks, A could claim the HTLC
> > from B via the timeout mechanism, and then after a few days, C could
> > get the HTLC-claiming transaction mined via some out-of-band agreement
> > with a small miner. This leaves B short the HTLC value.
>
> IIUC, the main problem is honest Bob will broadcast a transaction
> without realizing it conflicts with a pinned transaction that's already
> in most node's mempools.  If Bob knew about the pinned transaction and
> could get a copy of it, he'd be fine.
>
> In that case, would it be worth re-implementing something like a BIP61
> reject message but with an extension that returns the txids of any
> conflicts?  For example, when Bob connects to a bunch of Bitcoin nodes
> and sends his conflicting transaction, the nodes would reply with
> something like "rejected: code 123: conflicts with txid 0123...cdef".
> Bob could then reply with a a getdata('tx', '0123...cdef') to get the
> pinned transaction, parse out its preimage, and resolve the HTLC.
>
> This approach isn't perfect (if it even makes sense at all---I could be
> misunderstanding the problem) because one of the problems that caused
> BIP61 to be disabled in Bitcoin Core was its unreliability, but I think
> if Bob had at least one honest peer that had the pinned transaction in
> its mempool and which implemented reject-with-conflicting-txid, Bob
> might be ok.
>
> -Dave
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Antoine Riard via bitcoin-dev
Personally, I would have wait a bit before to go public on this, like
letting some implementations
increasing their CLTV deltas, but anyway, it's here now.

Mempool-pinning attacks were already discussed on this list [0], but what
we found is you
can _reverse_ the scenario, where it's not the malicious party delaying
confirmation of honest
party transactions but malicious deliberately stucking its own transactions
in the mempool to avoid
confirmation of timeout. And therefore gaming inter-link timelock to
provoke an unbalanced
settlement for the victim ("aka you pay forward, but don't get pay
backward").

How much attacks are practical is based on how you can leverage mempool
rules to pin your own
transaction. What you're looking for is a  _mempool-obstruction_ trick, i.e
a way to get honest party
transaction being bounce off due to your transaction being already there.

Beyond disabling RBF on your transaction (with current protocol, not anchor
proposal), there is
two likely candidates:
* BIP 125 rule 3: "The replacement transaction pays an absolute fee of at
least the sum paid by the original transactions."
* BIP 125 rule 5: "The number of original transactions to be replaced and
their descendant transactions which will be evicted from the mempool must
not exceed a total of 100 transactions."

Let's go through whole scenario:
* Mallory and Eve are colluding
* Eve and Mallory are opening channels with Alice, Mallory do a bit of
rebalancing
to get full incoming capacity, like receiving funds on an onchain address
through another Alice
link
* Eve send a HTLC #1 to Mallory through Alice expirying at block 100
* Eve send a second HTLC #2 to Mallory through Alice, expirying at block
110 on outgoing link
(A<->M), 120 on incoming link (E<->A)
* Before block 100, without cancellation from Mallory, Alice will
force-close channel and broadcast
her local commitment and HTLC-timeout to get back HTLC #1
* Alice can't broadcast HTLC-timeout for HTLC #2 as it's only expires at 110
* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output
on Alice's transaction,
feerate is maliciously chosen to get in network mempools but never to
confirm. Absolute fee must
be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p
race.
* As Alice doesn't watch the mempool, she is never going to learn the
preimage to redeeem incoming
HTLC #2
* At block 110, Alice is going to broadcast HTLC-timeout #2, feerate may be
higher but as absolute
fee is lower, it's going to be rejected from network mempools as
replacement for Pinning Preimage
Tx (BIP 125 rule 3)
* At block 120, Eve closes channel and HTLC-timeout HTLC #2
* Mallory can RBF its Pinning Preimage Tx by a high-feerate one and get it
confirmed

New anchor_output proposal, by disabling RBF, forces attacker to bid on the
absolute fee. It may
be now a risk to loose the fee if Pinning Tx is confirming. You may extend
your "pinning
lease" by ejecting your malicious tx, like conflicting or trimming out of
the mempool one of its
parents. And then reannounce your preimage tx with a
lower-feerate-but-still-high-fee before a
new block and a honest HTLC-timeout rebroadcast.

AFAICT, even with anchor_output deployed, even assuming empty mempools,
success rate and economic
rationality of attacks is finding such cheap, reliable "pinning lease
extension" trick.

I think any mempool watching mitigation is at best a cat-and-mouse hack.
Contrary to node
advancing towards a global blockchain view thanks to PoW, network mempools
don't have a convergence
guarantee. This means,  in a distributed system like bitcoin, node don't
see events in the same
order, Alice may observe tx X, tx Y, tx Z and Bob may observe tx Z, tx X,
tx Y. And order of events
affects if a future event is going to be rejected or not, like if tx Z
disable-RBF and tx X try to
replace Z, Alice accepts X and Bob rejects it. And this divergence may
perserve until a new block.

Practically, it means an attacker can provoke a local conflict to bounce
off HTLC preimage tx out
of your mempool while broadcasting preimage tx without conflict to the rest
of the network by
tweaking tx-relay protocol and so easily manipulating order of events for
every node. A local
conflict is easy to provoke, just make tx A double-spent by both
HTLC-preimage-tx and non-RBF-tx-B.
Announce txA+txB to mempool victim and txA+HTLC-preimage-tx to rest of
network. When rest of
network announce HTLC-preimage-tx, it's going to rejected by your mempool.

Provoking local conflict assumes of course _interlayer_ mapping by an
attacker, i.e mapping your LN
node to your full-node(s). Last time, we check, there was 982 match by IP
for 4,500 LN/52,000
full-node. Mapping heuristics is an ongoing research subject and sadly
seems affordable.

Yes a) you can enable full-RBF on your local node but blinding conflicting
may still be with higher
feerate as everything is attacker malleable b) you may want to catch tx and
extract preimage
on the p2p wire, but 

Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

2020-02-25 Thread Antoine Riard via bitcoin-dev
Morning Zeeman,

> I proposed before to consider splicing as a form of merged closing plus
funding, rather than a modification of channel state; in particular we
might note that, for compatibility with our existing system, a spliced
channel would have to change its short channel ID > and channel ID, so it
is arguably a different channel already.

Yes but you may want alias to keep your channel routing-score across
splicing, though how to do this is more LN-dev specific.

> Emulating LN splices mildly makes ConJoinXT less desirable, however, as
the mix takes longer and is more costly.

Intuitively, a lot of Coinjoin traffic may be redirected in the future
through LN when protocol matures, privacy properties may be better (though
need careful analysis).
Coinjoins would be only for high-amounts for which security/liquidity isn't
offered by LN, and in this case time for increasing privacy is IMO an
acceptable tradeoff.

> Does not Electrum do RBF by default?

Dunno, for more context on RBF and its controversies see
https://bitcoincore.org/en/faq/optin_rbf/ (or Optech resources)

> 1.5RTT with MuSig

Yes right I meaned you don't need to assume latter interactivity if it's a
multi-party tx construction you sign multiple RBF versions at same time.
Still need to think about privacy-preserving fee bumping wrt to mempool
observer

> This can be mitigated if all participants contribute equal or
nearly-equally to the fees, though that complicates single-funding, and may
violate Initiator Pays Principle (the initiator of an action should pay all
fees related to the action, as otherwise it may be  possible to create a
null operation that the acceptor of the action ends up paying fees for,
which can be used as a financial attack to drain acceptors).

Yes, but also you want the acceptor to pay for its inputs announced to
avoid pouring the spending burden on the initiator only, or doing any
free-ride aggregation .

> There may be other protocols interested in this as well --- for instance
"submarine swaps" and "lightning loops", which are the same thing.

Yes good point, specially batched submarine swaps are good candidates, also
DLCs (will enquiry on tx pattern of more bitcoin protocol)


Le lun. 24 févr. 2020 à 18:36, ZmnSCPxj  a écrit :

> Good morning Antoine,
>
>
> > > On mutual closes, we should probably set `nLockTime` to the current
> blockheight + 1 as well.
> > > This has greater benefit later in a Taproot world.
> >
> > I assume mutual closes would fall under the aforementioned tx
> construction proposal, so a closing may be a batch to fund other channels or
> > splice existent ones.
>
> Ah, that is indeed of great interest.
> I proposed before to consider splicing as a form of merged closing plus
> funding, rather than a modification of channel state; in particular we
> might note that, for compatibility with our existing system, a spliced
> channel would have to change its short channel ID and channel ID, so it is
> arguably a different channel already.
>
> >
> > > A kind of non-equal-value CoinJoin could emulate a Lightning open +
> close, but most Lightning channels will have a large number of blocks
> (thousands or tens of thousands) between the open and the close; it seems
> unlikely that a short-term channel will exist > that matches the
> non-equal-value CoinJoin.
> >
> > That's a really acute point, utxo age and spending frequency may be
> obvious protocol leaks.
>
> Yes; I am curious how JoinMarket reconciles how makers mix their coins vs.
> how takers do; presumably the tumbler.py emulates the behavior of a maker
> somehow.
>
> > Splicing may help there because a LN node would do multiple chain writes
> during channel lifecycle for liquidity reasons but it's
> > near-impossible to predict its frequency without deployment.
>
> Long ago, I proposed an alternative to splicing, which would today be
> recognizable as a "submarine swap" or "lightning loop".
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000692.html
> Perhaps the frequencies of those operations may hint as to how much
> splicing would occur in practice in the future.
>
> > Even with this, I do fear an analysis gap between Coinjoin spending
> delta and LN ones. A way to circumvent this would be for CoinjoinXT to
> timelock its PTG
> > transactions to mimick actively-spliced LN channels. That's where
> adoption of a common format by other onchain transactions than LN ones
> would help a lot.
>
> Well, one way to implement splice-in would be to have an output that is
> first dedicated to the splice-in, and *then* a separate transaction which
> actually does the splice-in.
> This has a drawback of requiring an extra transaction, which wins us the
> facility to continue operation of the channel even while the splice-in
> transactions are being confirmed while retaining only one state.
> (the latest proposal, I believe, does *not* use this construction, and
> instead requires both sides to maintain two sets of states, with 

Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

2020-02-24 Thread Antoine Riard via bitcoin-dev
> I notice your post puts little spotlight on unilateral cases.
> A thing to note, is that we only use `nSequence` and the weird watermark
on unilateral closes.
> Even HTLCs only exist on unilateral closes --- on mutual closes we wait
for HTLCs to settle one way or the other before doing the mutual close.

Yes, I'm only aiming LN-cooperative cases, as your noticed HTLCs only exist
on commitment txn and masquerading them in some Taptree would come
with its own challenges. Cooperative closings should be the majority of
channels if network is reliable and so would be a set big enough to achieve
the goal
of blurring Coinjoins among LN transactions.

Right now we don't use `nSequence` but the current interactive tx
construction proposal uses it for RBF (weird watermark was an example).

> On mutual closes, we should probably set `nLockTime` to the current
blockheight + 1 as well.
> This has greater benefit later in a Taproot world.

I assume mutual closes would fall under the aforementioned tx construction
proposal, so a closing may be a batch to fund other channels or
splice existent ones.

> A kind of non-equal-value CoinJoin could emulate a Lightning open +
close, but most Lightning channels will have a large number of blocks
(thousands or tens of thousands) between the open and the close; it seems
unlikely that a short-term channel will exist > that matches the
non-equal-value CoinJoin.

That's a really acute point, utxo age and spending frequency may be obvious
protocol leaks. Splicing may help there because a LN node would do multiple
chain writes during channel lifecycle for liquidity reasons but it's
near-impossible to predict its frequency without deployment. Even with
this, I do fear an analysis gap between Coinjoin spending delta and LN
ones. A way to circumvent this would be for CoinjoinXT to timelock its PTG
transactions to mimick actively-spliced LN channels. That's where adoption
of a common format by other onchain transactions than LN ones would help a
lot.

> Should always be on, even if we do not (yet) have a facility to
re-interact to bump fees higher.
> While it is true that a surveillor can determine that a transaction has
in fact been replaced (by observing the mempool) and thus eliminate the set
of transactions that arose from protocols that mark RBF but do not (yet)
have a facility to bump fees higher, this > information is not permanently
recorded on all fullnodes and at least we force surveillors to record this
information themselves.

Yes but if you do this for Core and given some merchants are refusing RBF
transactions for onchain payments, people are going to complain...
Also see footnote on spurious-RBF about not-having facility to bump fees
higher (you can sign multiple RBF transactions in 1-RTT and agree to
broadcast them later to obfuscate mempool analysis).

> However, it seems to me that we need to as well nail down the details of
this format.

Of course, just curious of people opinions right now but if it's a good way
to solve the described problem, will draft a spec.

Le sam. 22 févr. 2020 à 20:29, ZmnSCPxj  a écrit :

> Ggood morning Antoine, and list,
>
>
> > * nLocktime/nSequence
> > ...
> > * weird watermark (LN commitment tx obfuscated commitment number)
> > ...
> > LN (cooperative case):
>
> I notice your post puts little spotlight on unilateral cases.
> A thing to note, is that we only use `nSequence` and the weird watermark
> on unilateral closes.
> Even HTLCs only exist on unilateral closes --- on mutual closes we wait
> for HTLCs to settle one way or the other before doing the mutual close.
>
> If we assume that unilateral closes are rare, then it might be an
> acceptable risk to lose privacy in that case.
> Of course, it takes two to tango, and it takes two to make a Lightning
> channel, so ---
> In any case, I explored some of the difficulties with unilateral closes as
> well:
>
> *
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002421.html
> *
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002415.html
>
> On mutual closes, we should probably set `nLockTime` to the current
> blockheight + 1 as well.
> This has greater benefit later in a Taproot world.
>
> > Questions:
> > * Are there any protocol-specific semantic wrt to onchain transactions
> incompatibility
> > between Coinjoin and cooperative LN txn ?
>
> A kind of non-equal-value CoinJoin could emulate a Lightning open + close,
> but most Lightning channels will have a large number of blocks (thousands
> or tens of thousands) between the open and the close; it seems unlikely
> that a short-term channel will exist that matches the non-equal-value
> CoinJoin.
>
> In particular, a LN cooperative close will, in general, have only one
> input.
> A new form of CoinJoin could, instead of using a single transaction, use
> two, with an entry transaction that spends into an n-of-n of the
> participants, and the n-of-n being spent to split the coin back to their
> 

Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

2020-02-24 Thread Antoine Riard via bitcoin-dev
> Another one, usually wouldn't be *protocol* as much as wallet leakage,
but could be: utxo selection algorithm (which of course may be difficult to
deduce, but often, far from impossible).

Yes sure that's a good point, it may affect protocol too if your LN
implementation has its own onchain wallet. If not, and it reuses a non-LN
wallet you just carry on its fingerprint.
An extension in the future could be for closing/splicing transaction, your
liquidity algorithm may select in a really specific fashion which channels
must be closed or increased...

> But I would ask people to consider CoinJoinXT[1] more seriously in a
taproot/schnorr world, since it addresses this exact point.

The equal value paradigm is such a watermark and I assume it leans to
increase the number of outputs so I don't see it followed by any other
protocol. But yes CoinjoinXT, if you can come up with a easy interactive
multi-tx construction protocol that would be interesting (and could be
reused by any cut-through implementation I guess).

Overall, my thinking was to start specifying this now because such thing
would take a fair amount of time/coordination to get adopted. This way if
and when Taproot/Schnorr happen we don't
have to wait another period to start enjoying the privacy enhancement
(worst-case we can fallback on 2p-ecdsa).



Le sam. 22 févr. 2020 à 07:10, AdamISZ  a écrit :

> ‐‐‐ Original Message ‐‐‐
> On Friday, 21 February 2020 22:17, Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > How can a Bitcoin tranaction leak protocol usage ?
> > * the output type (p2sh, p2wsh, ...)
> > * the spending policy (2-of-3 multisig, timelock, hashlock,...)
> > * outputs ordering (BIP69)
> > * nLocktime/nSequence
> > * RBF-signaling
> > * Equal-value outputs
> > * weird watermark (LN commitment tx obfuscated commitment number)
> > * fees strategy like CPFP
> > * in-protocol announcements [0]
> >
> Good list.
> Another one, usually wouldn't be *protocol* as much as wallet leakage, but
> could be: utxo selection algorithm (which of course may be difficult to
> deduce, but often, far from impossible).
> (Also trivial and increasingly irrelevant, but nVersion).
>
> With regards to coinjoin in this context (I know your points are much
> broader), my comment is:
> For existing protocols (joinmarket's, wasabi's, samourai's), in the
> equal-outs paradigm, I don't see much that can be done in this area.
> But I would ask people to consider CoinJoinXT[1] more seriously in a
> taproot/schnorr world, since it addresses this exact point. With a short
> (not cross-block like swaps or LN setup) interaction, participants can
> arrange the effect of coinjoin without the on-chain watermark of coinjoin
> (so, steganographic). The taproot/schnorr part is needed there because
> multisig is required from transaction to transaction in that protocol, so
> doing it today is less interesting (albeit still interesting).
>
> waxwing
>
> [1] https://joinmarket.me/blog/blog/coinjoinxt/
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

2020-02-21 Thread Antoine Riard via bitcoin-dev
Coinjoins interceptions seem to raise at an increasing pace. Their onchain
fingerprint (high-number of inputs/outputs, lack of anti-fee snipping,
script
type, ...) makes their detection quite easy for a chain observer. A ban of
coinjoin'ed coins or any other coins linked through a common ownwer would
undermine the long-term fungibility of the whole ecosystem.

Of course, they do provide privacy for the participating coins but at the
tradeoffs of creating two observable sets: coinjoin'ed vs non-coinjoin'ed.
Ideally, all onchain transactions should conform to a common transaction
pattern that provides unobservability -- i.e a specific transaction would
be indistinguishable from any other transaction at all. For LN or Coinjoin
it means an external observer, not-involved in the protocol, should be
unable to tell which protocol is being used, or if _any_ specific protocol
is being used.

How can a Bitcoin tranaction leak protocol usage ?
* the output type (p2sh, p2wsh, ...)
* the spending policy (2-of-3 multisig, timelock, hashlock,...)
* outputs ordering (BIP69)
* nLocktime/nSequence
* RBF-signaling
* Equal-value outputs
* weird watermark (LN commitment tx obfuscated commitment number)
* fees strategy like CPFP
* in-protocol announcements [0]

A solution could be to blur multiple protocol onchain transactions into
one common transaction format [1]. For example, if one of them uses
nSequence
for some protocol semantic all the other ones should do it too. Any
deviation
would be enough to be leverage as a watermark and blow up all other tweaks.
If Schnorr-Taproot gets adopted and deployed by the community and LN
specifies
an interactive tx construction protocol [2], the timing would be pretty good
to adopt such format IMO.

Coinjoin:
* nSequence can be set, it's still secure if party don't resign [3]
* nLocktime can be set for anti-fee snipping
* Taproot spending

LN (cooperative case):
* splicing may blur funding/closing as the same thing, closing
address can be a funding output
* splice-in would allow equal value outputs
* nSequence likely to be set for multi-party tx construction
* nLocktime can be set for anti-fee snipping

Adopting a common transaction format isn't a cure-all solution
on the long-term privacy road but if it circumvent ban of some class
of transactions that would be already a nice win and a worthy effort
to do so.

Questions:
* Are there any protocol-specific semantic wrt to onchain transactions
incompatibility
between Coinjoin and cooperative LN txn ?
* What about RBF-by-default ?
* Core wallet or any other protocol or even batching algorithms could adopt
to this format ?
* Is artificially increasing the number of outputs to mimic Coinjoins txn
acceptable wrt to utxo bloat/fees ?

Cheers,

Antoine

[0] Like LN announcing public channels with signatures committing both
to onchain utxos and nodes static pubkeys. And them being display on LN
search engines with full owner info...

[1] By format, I don't mean a *binary* format a la PSBT but mere something
like BOLT3, a *logical* format.

[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002500.html

[3] But "blank" RBF would be a privacy leak if Coinjoin are never bumped,
because if you see both a low-fees and high-fees transaction you now know
they are a LN one, so Coinjoins implems should do some time spurious RBFs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-02-09 Thread Antoine Riard via bitcoin-dev
 > In particular, you care more about privacy when you are contesting a
> close of a channel or other script path because then the miners could be
more
> likely to extract a rent from you as "ransom" for properly closing your
channel
> (or in other words, in a contested close the value of the closing
transaction is
> larger than usual).

Not sure this point holds, independently of which Taproot/MASTmechanism
deployed,
any time-sensitive transaction will likely leak its "contestness" by the
setting of its
nSequence/nLocktime fields. E.g, for LN, justice tx are not encumbered by a
CSV
delay which distinguish them from a non-revoked spend. And when you're
relaying
htlcs and need to close unilaterally channel to prevent different
settlement on
incoming/outgoing links the HTLC-timeout tx broadcast have a nLocktime set.

Beyond LN, timelocks are a privacy leak and miner-withholding vector for any
offchain protocols but this problem is not tied to Taproot design.
Confidential
enforcement of them would be great but that's another debate..

Antoine








Le dim. 9 févr. 2020 à 15:40, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Responding purely to one point as this may be sufficient to clear up
> lots of discussion:
>
> On 2/9/20 8:19 PM, Bryan Bishop via bitcoin-dev wrote:
> > Is Taproot just a probability assumption about the frequency and
> > likelihood of
> > the signature case over the script case? Is this a good assumption?  The
> BIP
> > only goes as far as to claim that the advantage is apparent if the
> outputs
> > *could be spent* as an N of N, but doesn't make representations about
> > how likely
> > that N of N case would be in practice compared to the script paths.
> Perhaps
> > among use cases, more than half of the ones we expect people to be doing
> > could be
> > spent as an N of N. But how frequently would that path get used?
> > Further, while
> > the *use cases* might skew toward things with N of N opt-out, we might
> > end up in
> > a power law case where it's the one case that doesn't use an N of N opt
> > out at
> > all (or at a de minimis level) that becomes very popular, thereby making
> > Taproot
> > more costly then beneficial.
> Its not just about the frequency and likelihood, no. If there is a
> clearly-provided optimization for this common case in the protocol, then
> it becomes further more likely that developers put in the additional
> effort required to make this possibility a reality. This has a very
> significant positive impact on user privacy, especially those who wish
> to utilize more advanced functionality in Bitcoin. Further, yes, it is
> anticipated that the N of N case is possible to take in the vast
> majority of deployed use-cases for advanced scripting systems, ensuring
> that it is maximally efficient to do so (and thereby encouraging
> developers to do so) is a key goal in this work.
>
> Matt
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev