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

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

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

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

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

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 >

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

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,

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

[bitcoin-dev] Reminder: Transaction relay workshop on IRC Libera - Tuesday 15th June 19:00 UTC

2021-06-14 Thread Antoine Riard via bitcoin-dev
Hi, A short reminder about the 1st transaction relay workshop happening tomorrow on #l2-onchain-support Libera chat (!), Tuesday 15th June, from 19:00 UTC to 20:30 UTC Scheduled topics are: * "Guidelines about L2 protocols onchain security design" * "Coordinated cross-layers security

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-06-14 Thread Antoine Riard via bitcoin-dev
>>> OP_CHECKSIGADD(p2-fee-bump-key, ) OP_2 >>> OP_NUMEQUALVERIFY >>> >>> where <...> indicates the thing comes from the witness stack. >>> So to bump the fee of the commit tx after it has been signed either >>> party takes the and adds a signature

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-06-14 Thread Antoine Riard via bitcoin-dev
Thanks for this analysis of a sponsor-like mechanism. For sure, "watchtower friendly" and "post hoc" are really good point towards sponsorship, at least other proposals are struggling with watchtower support, at least in way where your watchtower policy doesn't leak to your counterparties (which

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-06-10 Thread Antoine Riard via bitcoin-dev
> So something like `or(and(pk(FB),pk(A)),and(pk(FB),pk(B)),and(pk(FB),pk(C)))` with each `or` in their own leaf? I think it works, but only if the keys `A`, `B`, `C` are "hot", as in available to the fee-bumper. For Revault it means introducing a key for each watchtower in the vaults descriptors,

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-06-10 Thread Antoine Riard via bitcoin-dev
fee bumping without DoS or pinning attacks but hopefully I > have demonstrated that this class of solutions also exists. > > [1] https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki > > Cheers, > > LL > > > > On Fri, 28 May 2021 at 07:13, Antoi

Re: [bitcoin-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

2021-06-18 Thread Antoine Riard via bitcoin-dev
> That's a question I hope we'll gather feedback during next Thursday's transaction relay workshops. As someone kindly pointed out to me, workshop is happening Tuesday, June 22th. Not Thursday, mistake of mine :/ Le ven. 18 juin 2021 à 18:11, Antoine Riard a écrit : > Hi, > > It's a big

[bitcoin-dev] On the recent softforks survey, forget to fulfill my answer!

2021-06-21 Thread Antoine Riard via bitcoin-dev
Hi, I was super glad to see the recent survey on potential softforks for the near-future of Bitcoin! I didn't have time to answer this one but will do so for the future. I wanna to salute the grassroots involvement in bitcoin protocol development, that's cool to see :) Though softforks are what

Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

2021-06-21 Thread Antoine Riard via bitcoin-dev
Hi Dave, > That might work for current LN-penalty, but I'm not sure it works for eltoo. Well, we have not settled yet on the eltoo design but if we take the later proposal in date [0], signing the update transaction with SIGHGASH_ANYPREVOUT lets you attach non-interactively a single-party

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

2021-06-25 Thread Antoine Riard via bitcoin-dev
course of a year or two seems fine, no need to rush. But I > suppose it would depend on how often 0-conf is used in the bitcoin > ecosystem at this point, which I don't have any data on. > > On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxf

Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

2021-06-24 Thread Antoine Riard via bitcoin-dev
Hi Michael, > Browsing quickly through Greg's piece, a lot of the reasoning is based on FOSS experience from Linux/Juniper, which to the best of my knowledge are centralized software projects ? > That is Greg's point. If Linux doesn't look further than the current > version and the next version

[bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

2021-06-15 Thread Antoine Riard via bitcoin-dev
Hi, I'm writing to propose deprecation of opt-in RBF in favor of full-RBF as the Bitcoin Core's default replacement policy in version 24.0. As a reminder, the next release is 22.0, aimed for August 1st, assuming agreement is reached, this policy change would enter into deployment phase a year

[bitcoin-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

2021-06-18 Thread Antoine Riard via bitcoin-dev
Hi, It's a big chunk, so if you don't have time browse parts 1 and 2 and share your 2 sats on the deployment timeline :p This post recalls some unsolved safety holes about Lightning, how package-relay or SIGHASH_ANYPREVOUT can solve the first one, how a mempool hardening can solve the second

Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic

2021-05-12 Thread Antoine Riard via bitcoin-dev
r. 11 mai 2021 à 17:51, Luke Dashjr a écrit : > Is there a list of software impacted by this CVE, and the versions it is > fixed > in? > > (Note this isn't a vulnerability in Bitcoin Core; BIP125 is strictly a > policy > matter, not part of the consensus rules and never safe to r

Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic

2021-05-12 Thread Antoine Riard via bitcoin-dev
Hi Ruben, Thanks for raising awareness about spacechains/BMM, I didn't have knowledge it was relying on a fee-based English auction to mine side-blocks. IIUC, it's another type of dynamic membership multi-party signature where parties are block-signing with a fee proposal instead of a PoW ?

[bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic

2021-05-06 Thread Antoine Riard via bitcoin-dev
Hi, I'm writing to report a defect in Bitcoin Core bip125 logic with minor security and operational implications for downstream projects. Though this defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn't impacted. # Problem Bip 125 specification describes the following

[bitcoin-dev] L2s Onchain Support IRC Workshop : Agenda & Schedule

2021-05-12 Thread Antoine Riard via bitcoin-dev
Hi, Following-up on the workshop announcement [0], I'm proposing today's early agenda and schedule. Dates have been picked up 2 weeks after the end of the Miami's conference as the american crowd will travel around and won't be necessary on their keyboards. Also, if folks from Asia/Pacific

Re: [bitcoin-dev] Improvement on Blockbuilding

2021-05-29 Thread Antoine Riard via bitcoin-dev
Hi Mark and Clara, Great research, thanks for it! Few questions out of mind after a first read. > This approach enables block building to consider Child Pays For Parent (CPFP) constellations. I think that's a really interesting point, it's likely that such transaction graphs with multiple

[bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-05-27 Thread Antoine Riard via bitcoin-dev
Hi, This post is pursuing a wider discussion around better fee-bumping strategies for second-layer protocols. It draws out a comparison between input-based and CPFP fee-bumping techniques, and their apparent trade-offs in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-05-28 Thread Antoine Riard via bitcoin-dev
> Unfortunately, ACP | SINGLE is trivially pinable [0] (TL;DR: i can just attach an output paying immediately to me, and construct a tx chain spending it). We are using ACP | ALL for Revault, > which is the reason why we need a well laid-out pool of fee-bumping UTXOs (as you need to consume them

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-07-11 Thread Antoine Riard via bitcoin-dev
overlapping though you might still have to be careful about siphoning ? Something you should already care about if you use SIGHASH_SINGLE and your x's amount > y's value. Le ven. 9 juil. 2021 à 21:47, Anthony Towns a écrit : > On Fri, Jul 09, 2021 at 09:19:45AM -0400, Antoine Riard via bitco

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-07-09 Thread Antoine Riard via bitcoin-dev
On Thu, May 27, 2021 at 04:14:13PM -0400, Antoine Riard via bitcoin-dev wrote: > This overhead could be smoothed even further in the future with more advanced > sighash malleability flags like SIGHASH_IOMAP, allowing transaction signers to > commit to a map of inputs/outputs [2]. In th

[bitcoin-dev] L2s Onchain Support IRC Workshop

2021-04-23 Thread Antoine Riard via bitcoin-dev
Hi, During the lastest years, tx-relay and mempool acceptances rules of the base layer have been sources of major security and operational concerns for Lightning and other Bitcoin second-layers [0]. I think those areas require significant improvements to ease design and deployment of higher

Re: [bitcoin-dev] [Lightning-dev] L2s Onchain Support IRC Workshop

2021-04-23 Thread Antoine Riard via bitcoin-dev
Hi Jeremy, Yes dates are floating for now. After Bitcoin 2021, sounds a good idea. Awesome, I'll be really interested to review again an improved version of sponsorship. And I'll try to sketch out the sighash_no-input fee-bumping idea which was floating around last year during pinnings

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

2021-04-23 Thread Antoine Riard via bitcoin-dev
Hi Luke, For the records and the subscribers of this list not following #bitcoin-core-dev, this mail follows a discussion which did happen during yesterday irc meetings. Logs here : http://gnusha.org/bitcoin-core-dev/2021-04-22.log I'll reiterate my opinion expressed during the meeting. If this

Re: [bitcoin-dev] L2s Onchain Support IRC Workshop

2021-04-27 Thread Antoine Riard via bitcoin-dev
policy, > but perhaps it could be helpful to expose a configurable RPC (e.g. #21413 > <https://github.com/bitcoin/bitcoin/pull/21413>) to test a range of > scenarios? > > Anyway, looking forward to discussions :) > > Best, > Gloria > > On Fri, Apr 23, 2021 at 8:51 AM

[bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core

2021-02-10 Thread Antoine Riard via bitcoin-dev
Hi, I'm proposing to stop the processing of unrequested transactions in Bitcoin Core 22.0+ at TX message reception. An unrequested transaction is one defined by which a "getdata" message for its specific identifier (either txid or wtxid) has not been previously issued by the node [0]. This

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

2021-03-01 Thread Antoine Riard via bitcoin-dev
Hi John, > I think a good counter-argument against simply using `fRelay` for this > purpose is that we shouldn't reuse a protocol feature designed for one > function to achieve a totally different aim. However, we know that nodes > on the network have been using `fRelay` to disable transaction

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

2021-03-03 Thread Antoine Riard via bitcoin-dev
> I believe this is what BIP 60 does, or did you have something else in > mind? Right, it achieves the first goal of dissociating `fRelay` from BIP37 but it doesn't document Core specific behavior of disconnecting peers for raw TX messages reception from outbound block-relay-only peers, as

Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core

2021-02-12 Thread Antoine Riard via bitcoin-dev
Hi Jeremy, If I understand correctly your concern, you're worried that change would ease discovery of the node's tx-relay topology ? I don't scope transaction origin inference, if you suppose the unrequested-tx peer sending is the attacker it must have learnt the transaction from somewhere else

Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect

2021-09-09 Thread Antoine Riard via bitcoin-dev
Hi Jeremy, Answering here from #22871 discussions. I agree on the general principle to not blur mempool policies signaling in committed transaction data. Beyond preserving upgradeability, another good argument is to let L2 nodes update the mempool policies signaling their pre-signed transactions

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-10 Thread Antoine Riard via bitcoin-dev
Hi AJ, Thanks for finally putting the pieces together! [0] We've been hacking with Gleb on a paper for the CoinPool protocol [1] during the last weeks and it should be public soon, hopefully highlighting what kind of scheme, TAPLEAF_UPDATE_VERIFY-style of covenant enable :) Here few early

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-12 Thread Antoine Riard via bitcoin-dev
Sorry for the lack of clarity, sometimes it sounds easier to explain ideas with code. While MERKLESUB is still WIP, here the semantic. If the input spent is a SegWit v1 Taproot output, and the script path spending is used, the top stack item is interpreted as an output position of the spending

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-18 Thread Antoine Riard via bitcoin-dev
logically equivalent subtree embedded in the modifying tapscript. If you have multiple modifying scripts and you can't predict the order, I think the tree complexity will be quickly too high and grafroot-like approaches are likely better Le mer. 15 sept. 2021 à 02:51, Anthony Towns a écrit :

Re: [bitcoin-dev] Proposal: Package Mempool Accept and Package RBF

2021-09-19 Thread Antoine Riard via bitcoin-dev
Hi Gloria, > A package may contain transactions that are already in the mempool. We > remove > ("deduplicate") those transactions from the package for the purposes of > package > mempool acceptance. If a package is empty after deduplication, we do > nothing. IIUC, you have a package A+B+C

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-09 Thread Antoine Riard via bitcoin-dev
I'm pretty conservative about increasing the standard dust limit in any way. This would convert a higher percentage of LN channels capacity into dust, which is coming with a lowering of funds safety [0]. Of course, we can adjust the LN security model around dust handling to mitigate the safety

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-10 Thread Antoine Riard via bitcoin-dev
> As developers, we have no control over prevailing feerates, so this is a problem LN needs to deal with regardless of Bitcoin Core's dust limit. Right, as of today, we're going to trim-to-dust any commitment output of which the value is inferior to the transaction owner's `dust_limit_satoshis`

Re: [bitcoin-dev] Proposal: Package Mempool Accept and Package RBF

2021-09-23 Thread Antoine Riard via bitcoin-dev
> Correct, if B+C is too low feerate to be accepted, we will reject it. I > prefer this because it is incentive compatible: A can be mined by itself, > so there's no reason to prefer A+B+C instead of A. > As another way of looking at this, consider the case where we do accept > A+B+C and it sits

Re: [bitcoin-dev] Proposal: Package Mempool Accept and Package RBF

2021-09-26 Thread Antoine Riard via bitcoin-dev
Hi Gloria, Thanks for your answers, > In summary, it seems that the decisions that might still need > attention/input from devs on this mailing list are: > 1. Whether we should start with multiple-parent-1-child or 1-parent-1-child. > 2. Whether it's ok to require that the child not have

Re: [bitcoin-dev] Proposal: Package Mempool Accept and Package RBF

2021-09-29 Thread Antoine Riard via bitcoin-dev
re only allowed to use confirmed inputs > and have many channels (and a limited number of confirmed inputs). > Otherwise you'll need node operators to pre-emptively split their > utxos into many small utxos just for fee bumping, which is inefficient... > > Bastien &

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-22 Thread Antoine Riard via bitcoin-dev
> Hmm, I'm reading C5 as "If an oracle says X, and Alice and Carol agree, > they can distribute all the remaining funds as they see fit". Should be read as an OR: IF 2 2 CHECKMULTISIG ELSE 2 2 CHECKMULTISIG ENDIF <> 2 IN_OUT_AMOUNT The empty vector is a

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

2021-12-19 Thread Antoine Riard via bitcoin-dev
; -- > @JeremyRubin <https://twitter.com/JeremyRubin> > <https://twitter.com/JeremyRubin> > > > On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi, >> >> I'm writing to pro

Re: [bitcoin-dev] death to the mempool, long live the mempool

2021-10-27 Thread Antoine Riard via bitcoin-dev
Hi Lisa, Network mempools constitute a blockspace marketplace where block demand meets the offer in real-time. Block producers are acting to discover the best feerate bids compensating for their operational costs and transaction proposers are acting to offer the best feerate in function of their

Re: [bitcoin-dev] A fee-bumping model

2021-11-30 Thread Antoine Riard via bitcoin-dev
Hi Darosior, Nice work, few thoughts binding further your model for Lightning. > For any delegated vault, ensure the confirmation of a Cancel transaction in a configured number of > blocks at any point. In so doing, minimize the overpayments and the UTxO set footprint. Overpayments > increase

Re: [bitcoin-dev] A fee-bumping model

2021-12-09 Thread Antoine Riard via bitcoin-dev
Hi Gloria, For LN, I think 3 tower rewards models have been discussed : per-penalty on-chain bounty/per-job micropayment/customer subscription. If curious, see the wip specification : https://github.com/sr-gi/bolt13/blob/master/13-watchtowers.md > - Do we expect watchtowers tracking multiple

Re: [bitcoin-dev] A fee-bumping model

2021-12-09 Thread Antoine Riard via bitcoin-dev
Hi Antoine, > It seems to me the only policy-level mitigation for RBF pinning around the "don't decrease the abolute fees of a less-than-a-block mempool" would be to drop the requirement on increasing absolute fees if the mempool is "full enough" (and the feerate increases exponentially, of

Re: [bitcoin-dev] Bitcoin Legal Defense Fund

2022-01-13 Thread Antoine Riard via bitcoin-dev
> One question I have is how you might describe the differences between what BLDF can accomplish and what e.g. EFF can accomplish. Having been represented by the EFF on more than one occasion, they are fantastic. Do you feel that the Bitcoin-specific focus of BLDF outweighs the more general (but

Re: [bitcoin-dev] Thoughts on fee bumping

2022-02-14 Thread Antoine Riard via bitcoin-dev
> In the context of fee bumping, I don't see how this is a criticism > unique to transaction sponsors, since it also applies to CPFP: if you > tried to bump fees for transaction A with child txn B, if some mempool > hasn't seen parent A, it will reject B. Agree, it's a comment raising the

Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations

2022-03-07 Thread Antoine Riard via bitcoin-dev
Hi Jeremy, > I've seen some discussion of what the Annex can be used for in Bitcoin. For > example, some people have discussed using the annex as a data field for > something like CHECKSIGFROMSTACK type stuff (additional authenticated data) > or for something like delegation (the delegation is to

Re: [bitcoin-dev] CTV vaults in the wild

2022-03-07 Thread Antoine Riard via bitcoin-dev
Hi James, Interesting to see a sketch of a CTV-based vault design ! I think the main concern I have with any hashchain-based vault design is the immutability of the flow paths once the funds are locked to the root vault UTXO. By immutability, I mean there is no way to modify the

Re: [bitcoin-dev] Improving RBF Policy

2022-03-17 Thread Antoine Riard via bitcoin-dev
Hi Mempoololic Anonymous fellow, > 2. Staggered broadcast of replacement transactions: within some time > interval, maybe accept multiple replacements for the same prevout, but only > relay the original transaction. If the goal of replacement staggering is to save on bandwidth, I'm not sure it's

Re: [bitcoin-dev] CTV vaults in the wild

2022-03-10 Thread Antoine Riard via bitcoin-dev
Hi Zeeman, > Have not looked at the actual vault design, but I observe that Taproot allows for a master key (which can be an n-of-n, or a k-of-n with setup (either expensive or trusted, but I repeat myself)) to back out of any contract. > > This master key could be an "even colder" key that you

Re: [bitcoin-dev] CTV vaults in the wild

2022-03-10 Thread Antoine Riard via bitcoin-dev
Hi James, > I don't really see the vaults case as any different from other > sufficiently involved uses of bitcoin script - I don't remember anyone > raising these concerns for lightning scripts or DLCs or tapscript use, > any of which could be catastrophic if wallet implementations are not >

Re: [bitcoin-dev] Thoughts on fee bumping

2022-02-18 Thread Antoine Riard via bitcoin-dev
While I roughly agree with the thesis that different replacement policies offer marginal block reward gains _in the current state_ of the ecosystem, I would be more conservative about extending the conclusions to the medium/long-term future. > I suspect the "economically rational" choice would be

[bitcoin-dev] A Dive into CoinPool : Bitcoin Balances for Billions

2022-02-21 Thread Antoine Riard via bitcoin-dev
Hi, We (Gleb+ me) would like to present the following of our research on payment pools [0]. Abstract: CoinPool is a new multi-party construction to improve Bitcoin onboarding and transactional scaling by orders of magnitude. CoinPool allows many users to share a UTXO and make instant off-chain

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-21 Thread Antoine Riard via bitcoin-dev
Hi Zeeman, > To reveal a single participant in a TLUV-based CoinPool, you need to reveal O(log N) hashes. > It is the O(log N) space consumption I want to avoid with `OP_EVICT`, and I believe the reason for that O(log N) revelation is due precisely to the arbitrary but necessary ordering. AFAIU

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-18 Thread Antoine Riard via bitcoin-dev
Hi Zeeman, > After some thinking, I realized that it was the use of the > Merkle tree to represent the promised-but-offchain outputs of > the CoinPool that lead to the O(log N) space usage. > I then started thinking of alternative representations of > sets of promised outputs, which would not

Re: [bitcoin-dev] Improving RBF policy

2022-01-31 Thread Antoine Riard via bitcoin-dev
> Is it still verboten to acknowledge that RBF is normal behavior and disallowing it is the feature, and that feature is mostly there to appease some people's delusions that zeroconf is a thing? It seems a bit overdue to disrespect the RBF flag in the direction of always assuming it's on. If

Re: [bitcoin-dev] Improving RBF Policy

2022-01-30 Thread Antoine Riard via bitcoin-dev
Hi Gloria, Thanks for this RBF sum up. Few thoughts and more context comments if it can help other readers. > For starters, the absolute fee pinning attack is especially > problematic if we apply the same rules (i.e. Rule #3 and #4) in > Package RBF. Imagine that Alice (honest) and Bob

Re: [bitcoin-dev] Scaling Lightning With Simple Covenants

2023-09-11 Thread Antoine Riard via bitcoin-dev
Hi John, Thanks for the proposal, few feedback after a first look. > If Bitcoin and Lightning are to become widely-used, they will have to be > adopted by casual users who want to send and receive bitcoin, but > who do > not want to go to any effort in order to provide the infrastructure for

Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

2023-09-11 Thread Antoine Riard via bitcoin-dev
Hi Zeeman > What we can do is to add the actuary to the contract that > controls the funds, but with the condition that the > actuary signature has a specific `R`. > As we know, `R` reuse --- creating a new signature for a > different message but the same `R` --- will leak the > private key. >

Re: [bitcoin-dev] Concrete MATT opcodes

2023-09-15 Thread Antoine Riard via bitcoin-dev
cient to avoid being attacked in this way. > > The addition of most forms of covenant does not assist any of these > attacks afaict because they already make assumptions rendering them invalid. > > > Symphonic > > --- Original Message --- > On Monday, August 14th, 20

Re: [bitcoin-dev] Concrete MATT opcodes

2023-09-15 Thread Antoine Riard via bitcoin-dev
Hi Salvatore, Thanks for the additional insights. > At this time, my goal is to facilitate maximum experimentation; it's safe to open Pandora's box in a sandbox, as that's the only way to know if it's empty. > Concerns will of course need to be answered when a soft-fork proposal is made, and

[bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

2023-10-16 Thread Antoine Riard via bitcoin-dev
(cross-posting mempool issues identified are exposing lightning chan to loss of funds risks, other multi-party bitcoin apps might be affected) Hi, End of last year (December 2022), amid technical discussions on eltoo payment channels and incentives compatibility of the mempool anti-DoS rules, a

Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

2023-10-16 Thread Antoine Riard via bitcoin-dev
Todd a écrit : > > > On October 16, 2023 6:57:36 PM GMT+02:00, Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >(cross-posting mempool issues identified are exposing lightning chan to > >loss of funds risks, other multi-party bitcoin

Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

2023-10-19 Thread Antoine Riard via bitcoin-dev
> As the CLTV > delta deadline approaches, the fees in case 2 may be 50%, 80%, even > 100% of the HTLC value under such a scorched earth policy. A replacement-cycling attacker can afford to pay 100% of the HTLC value under the defender scorched earth policy and still realize an economic gain.

Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

2023-10-19 Thread Antoine Riard via bitcoin-dev
Hi Matt, This mitigation is mentioned in the attached paper (see subsection 3.4 defensive fee-rebroadcasting) https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf As soon as you start to have a bit of a mempool backlog and the defensive fractional fee

Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants

2023-10-19 Thread Antoine Riard via bitcoin-dev
Hi Bastien, Thanks for your additional comments. > Yes, they can, and any user could also double-spend the batch using a > commit tx spending from the previous funding output. Participants must > expect that this may happen, that's what I mentioned previously that > you cannot use 0-conf on that

Re: [bitcoin-dev] The Pinning & Replacement Problem Set

2023-11-03 Thread Antoine Riard via bitcoin-dev
Hi John, I think lightning and other second time-sensitive layers being hit by safety issues whenever the blocks are full is common knowledge as the issue is being described in the paper under the "forced expiration spam" issues arising spontaneously within an environment with high block space

  1   2   3   >