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

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

2020-02-24 Thread Antoine Riard via bitcoin-dev
chnorr 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 <

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

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

[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

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

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

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
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

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

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
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 >> to

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

[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

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, >> >>

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

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

2020-05-06 Thread Antoine Riard via bitcoin-dev
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 curre

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

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

[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

[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

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

[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

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,

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

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

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

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

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