Re: [bitcoin-dev] bitcoin-dev Digest, Vol 91, Issue 5

2022-12-06 Thread Antoine Riard via bitcoin-dev
Hi John, Thanks for expressing your thoughts on the current state of `-mempoolfullrbf`, from the perspective of a merchant and zero-conf proponent. First and foremost, we're dealing with a nuanced and rich topic, implying not only the inner workings of Bitcoin Core mempool policy rules, the

[bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger

2022-12-02 Thread Antoine Riard via bitcoin-dev
Hi Daniel, >From my understanding of GAP600, you're operating a zero-conf risk analysis business, which is integrated and leveraged by payment processors/liquidity providers and merchants. A deployment of fullrbf by enough full-node operators and a subset of the mining hashrate would lower the

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

2022-12-02 Thread Antoine Riard via bitcoin-dev
Hi Daniel, >From my understanding of GAP600, you're operating a zero-conf risk analysis business, which is integrated and leveraged by payment processors/liquidity providers and merchants. A deployment of fullrbf by enough full-node operators and a subset of the mining hashrate would lower the

Re: [bitcoin-dev] Bitcoin Contracting Primitives WG 1st Meeting, Tuesday 15 Nov. 18:00 UTC

2022-11-15 Thread Antoine Riard via bitcoin-dev
Hi list, 1st meeting did happen this afternoon with like ~10 attendees, we browsed the covenant interests of everyone: state channels, universal settlement layer, transaction introspection covenants, vaults/self-custody, MATT covenants, logical label covenant like transaction inherited IDs,

Re: [bitcoin-dev] Bitcoin Contracting Primitives WG 1st Meeting, Tuesday 15 Nov. 18:00 UTC

2022-11-15 Thread Antoine Riard via bitcoin-dev
Message ------- > On Monday, November 14th, 2022 at 7:51 AM, Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Reminder: this is happening this _upcoming_ Tuesday. > > Looking forward to the first session, listening to everyone's thoughts >

Re: [bitcoin-dev] Bitcoin Contracting Primitives WG 1st Meeting, Tuesday 15 Nov. 18:00 UTC

2022-11-13 Thread Antoine Riard via bitcoin-dev
Reminder: this is happening this _upcoming_ Tuesday. Looking forward to the first session, listening to everyone's thoughts about what could be the scope discussed by this new community process: anyprevout, recursive covenants, introspection, new malleability flags, ZK rollups, new contracting

Re: [bitcoin-dev] Merkleize All The Things

2022-11-11 Thread Antoine Riard via bitcoin-dev
Hi Salvatore, Thanks for bringing forward this MATT proposal! Here my (rough) understanding of the protocol, the participants decompose the entire computation into a number N of steps, each assigned a tapleaf, each computation is a triplet (state_start, operation, state_end), the tapleaves are

Re: [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime

2022-11-07 Thread Antoine Riard via bitcoin-dev
Hi Peter, > We can ensure with high probability that the transaction can be > cancelled/mined > at some point after N blocks by pre-signing a transaction, with nLockTime set > sufficiently far into the future, spending one or more inputs of the > transaction with a sufficiently high fee that it

Re: [bitcoin-dev] Preventing/detecting pinning of jointly funded txs

2022-11-06 Thread Antoine Riard via bitcoin-dev
Hi AJ, Adding a few more thoughts here on what coinjoins/splicing/dual-funded folks can do to solve this DoS isse in an opt-in RBF world only. I'm converging that deploying a distributed monitoring of the network mempools in the same fashion as zeroconf people is one solution, as you can detect

Re: [bitcoin-dev] On mempool policy consistency

2022-11-02 Thread Antoine Riard via bitcoin-dev
Hi Suhas, >From my understanding, the main crux of the reasoning exposed in your post would be to solidify the transaction-relay paradigm we have been following during the last years, e.g introducing the carve-out rule specifically for lightning commitment transactions, or more recently version=3

[bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling

2022-11-02 Thread Antoine Riard via bitcoin-dev
Hi list, Reading Suhas's post on mempool policy consistency rules, and the grounded suggestion that as protocol developers we should work on special policy rules to support each reasonable use case on the network rather to arbiter between class of use-cases in the design of an unified set of

[bitcoin-dev] Bitcoin Contracting Primitives WG 1st Meeting, Tuesday 15 Nov. 18:00 UTC

2022-10-31 Thread Antoine Riard via bitcoin-dev
Hi list, After I have been asked offline the exact date when those meetings were actually starting, I'm proposing Tuesday 15th November at 18:00 UTC, i.e 2 weeks from now. Thinking about a monthly frequency for now (from my experience attending dlcspecs/lighnting specs meetings/core dev meetings

Re: [bitcoin-dev] On mempool policy consistency

2022-10-27 Thread Antoine Riard via bitcoin-dev
52, Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > Hi *, > > TLDR: Yes, this post is too long, and there's no TLDR. If it's any > consolation, it took longer to write than it does to read? > > On Tue, Jun 15, 2021 at 12:55:14PM -0400, Ant

Re: [bitcoin-dev] Analysis of full-RBF deployment methods

2022-10-23 Thread Antoine Riard via bitcoin-dev
Hi Dario, Thanks for providing more thoughts to the discussion! > Notice that #26323 (option 5 in the OP) has the advantage of getting us to a > reliable full-RBF network the fastest (in particular, much faster than the > current opt-in deployment) while not threatening zero-conf applications >

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

2022-10-21 Thread Antoine Riard via bitcoin-dev
> There is a long list of countermeasures that can be built to reduce these > attacks, but to be frank we've only implemented a small subset of these and > not had any issues, so even a lower level of security is more than fine > today to have basically zero abuse. If issues arise we could

Re: [bitcoin-dev] Analysis of full-RBF deployment methods

2022-10-21 Thread Antoine Riard via bitcoin-dev
Hi Dario, Thanks for this analysis of full-RBF deployment methods! The subject was widely discussed at today Bitcoin Core IRC meetings: https://gnusha.org/bitcoin-core-dev/2022-10-20.log Personally, I still think deferring full-rbf deployment, while it sounds reasonable to let existing services

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

2022-10-19 Thread Antoine Riard via bitcoin-dev
Hi Sergej, Thanks for the insightful posting, especially highlighting the FX risk which was far from being evident on my side! I don't know in details the security architecture of Bitrefill zeroconf acceptance system, though from what I suppose there is at least a set of full-nodes

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

2022-10-19 Thread Antoine Riard via bitcoin-dev
er results from a lack of communication of the Core project, I'm still wondering on those subjects. And note again, I didn't deny the option 3) approach as you laid out was zero-risk for 0conf operators. All that said, if we think as a project we should offer a "zero-risk" process towards 0co

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF against package limit pinning

2022-10-18 Thread Antoine Riard via bitcoin-dev
Hi Greg, Thanks for proposing forward the "ephemeral anchors" policy change. > In Gloria's proposal for ln-penalty, this is worked > around by reducing the number of anchors per commitment transaction to 1, > and each version of the commitment transaction has a unique party's key on > it. The

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

2022-10-17 Thread Antoine Riard via bitcoin-dev
Hi John, I hear your worry about RBF issuing concerns for 0conf acceptance merchants. I don't think it has been denied in the first communication of this opt-in rbf proposal back in June. Merchants/0confs builders have been invited to bring voices to the surface at that time [0]. So this new

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

2022-10-17 Thread Antoine Riard via bitcoin-dev
Hi AJ, > 1) Continue supporting and encouraging accepting unconfirmed "on-chain" > payments indefinitely > > 2) Draw a line in the sand now, but give people who are currently > accepting unconfirmed txs time to update their software and business > model > > 3) Encourage mainnet

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

2022-10-17 Thread Antoine Riard via bitcoin-dev
Hi Dario, Sorry for the latency in reply to the reaction about the full-rbf setting I've initially pushed in 0.24, TABConf week has been a busy one. >From my understanding, there is no disagreement from Muun wallet about the gradual deployment of full-rbf by Bitcoin Core nodes, this is more a

[bitcoin-dev] What has the Taproot Annex ever done for us ?

2022-10-10 Thread Antoine Riard via bitcoin-dev
Hi, Recent advances in the development of Eltoo Lightning channels have envisioned the usage of the Taproot annex as a transaction endpoint where to store specific protocol payload. [0] Further, during the past years, some use-cases such as SIGHASH_GROUP/SIGHASH_BUNDLE have been proposed that

Re: [bitcoin-dev] On a new community process to specify covenants

2022-10-07 Thread Antoine Riard via bitcoin-dev
Hi all, Following up my September's mail on the setting of a new decentralized, open and neutral community process dedicated to covenants R, a.k.a "Bitcoin Contracting Primitives WG", few updates. After collecting feedback on the adequate communication channel, a low access bar and pseudonymous

Re: [bitcoin-dev] Spookchains: Drivechain Analog with One-Time Trusted Setup & APO

2022-09-29 Thread Antoine Riard via bitcoin-dev
Hi Jeremy, Thanks for bringing back to awareness covenant-based drivechain designs again! I'm not super familiar with the thousands shades of sidechains, and especially how the variants of pegging mechanisms influence the soundness of the game-theory backing up the functionaries execution.

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

2022-09-25 Thread Antoine Riard via bitcoin-dev
Hi Gloria, Thanks for the progress on package RBF, few early questions. > 2. Any descendant of an unconfirmed V3 transaction must also be V3. > 3. An unconfirmed V3 transaction cannot have more than 1 descendant. If you're a miner and you receive a non-V3, second descendant of an unconfirmed

Re: [bitcoin-dev] More uses for CTV

2022-09-19 Thread Antoine Riard via bitcoin-dev
Hi James, Thanks to bringing to awareness the atomic mining pool thing, it's interesting. > I'm not a mining expert and so I can't speak to the efficacy of the > paper as a whole, but direct-from-coinbase payouts seem like a > desirable feature which avoids some trust in pools. One limitation is

Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet

2022-09-18 Thread Antoine Riard via bitcoin-dev
Hi AJ, Thanks to setup a new laboratory for consensus upgrades experiment! Idea was exposed during the last LN Summit, glad to see there is a useful fork now. While I think one of the problem particular in the current stagnation about consensus upgrades has been well scoped by your proposal,

Re: [bitcoin-dev] On a new community process to specify covenants

2022-09-16 Thread Antoine Riard via bitcoin-dev
Hi Buck, > First just wanted to thank you for taking the initiative to > put this together. I think that as the community and > ecosystem continue to grow, it's going to be an important > part of the process to have groups like this develop. Hopefully > they allow us to resist the "Tyranny of

Re: [bitcoin-dev] On a new community process to specify covenants

2022-09-16 Thread Antoine Riard via bitcoin-dev
Hi Devrandom, > Agreed, anything that requires a phone number makes it difficult to be > pseudonymous. > > I recommend Matrix, since it doesn't require any privacy invasive > information and has e2ee by default for 1-1 conversations. Yeah sounds like people are opting for either Matrix or IRC

Re: [bitcoin-dev] On a new community process to specify covenants

2022-09-09 Thread Antoine Riard via bitcoin-dev
Hi all, Following up on my July's mail proposing to setup a new community process dedicated to covenant R, after aggregating all the feedbacks received online/offline, I've started a repository to collect the use-cases and known design constraints:

Re: [bitcoin-dev] On a new community process to specify covenants

2022-08-30 Thread Antoine Riard via bitcoin-dev
Hi Billy, > I was actually not thinking one large central in-person meeting, but many smaller decentralized in-person meetings where no one has to travel far. The meetings can be used to foster communication that can then be summarized and/or brought online and discussed with the larger group.

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

2022-08-23 Thread Antoine Riard via bitcoin-dev
> I'd suggest doing that right now, without waiting for the patch to get merged, > as it improves the politics of getting the patch merged. Miners tend to run > customized bitcoind's anyway. Philosophically, I think we're better off arguing code patches free from a political framework and rather

Re: [bitcoin-dev] On a new community process to specify covenants

2022-08-09 Thread Antoine Riard via bitcoin-dev
Hi Billy, Thanks for your interest in a covenant working group. > place for this kind of thing to happen. I also agree with Ryan Grant's > comment about in-person cut-through (ie cut through the BS and resolve > misunderstandings). Perhaps every 3 IRC meetings or so, an in-person meetup > can be

Re: [bitcoin-dev] On a new community process to specify covenants

2022-07-26 Thread Antoine Riard via bitcoin-dev
if they're required building blocks of the use-cases. Le dim. 24 juil. 2022 à 14:23, Bram Cohen a écrit : > On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Indeed this range has grown wild. Without aiming

Re: [bitcoin-dev] On a new community process to specify covenants

2022-07-26 Thread Antoine Riard via bitcoin-dev
Hi Zeeman, So on the first concern of using an "economic simulation" or sidechains/other cryptocurrencies to gather feedback about interest of Script extensions, I wonder about the value transitivity of such a process to measure consensus. Namely, if you have asset X picked up in system A, it

Re: [bitcoin-dev] On a new community process to specify covenants

2022-07-26 Thread Antoine Riard via bitcoin-dev
elopment, especially w.r.t consensus changes, I'm curious about it. [0] https://github.com/bitcoin/bitcoin/issues/22806 Le dim. 24 juil. 2022 à 09:01, aliashraf.btc At protonmail < aliashraf@protonmail.com> a écrit : > --- Original Message --- > On Saturday, July 23rd, 20

Re: [bitcoin-dev] On a new community process to specify covenants

2022-07-24 Thread Antoine Riard via bitcoin-dev
progress and work will be carried out that moves us in > a positive direction. > > Thanks > Michael > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > --- O

Re: [bitcoin-dev] On a new community process to specify covenants

2022-07-23 Thread Antoine Riard via bitcoin-dev
Hi Ryan, > Certain human/organizational limitations prevent things being said in > logged channels that sometimes can be shared in person. Sometimes > people break through misunderstandings in person, through either > informal mingling or the use of Chatham House rules. So I would also >

[bitcoin-dev] On a new community process to specify covenants

2022-07-20 Thread Antoine Riard via bitcoin-dev
Hi, Discussions on covenants have been prolific and intense on this mailing list and within the wider Bitcoin technical circles, I believe however without succeeding to reach consensus on any new set of contracting primitives satisfying the requirements of known covenant-enabled use-cases. I

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

2022-07-09 Thread Antoine Riard via bitcoin-dev
> Point is, the attacker is thousands of UTXOs can also DoS rounds by simply > failing to complete the round. In fact, the double-spend DoS attack requires > more resources, because for a double-spend to be succesful, BTC has to be spent > on fees. I think I agree that effectively a

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

2022-06-21 Thread Antoine Riard via bitcoin-dev
a few mining node operators to advocate them with the new policy setting. Antoine Le lun. 20 juin 2022 à 19:49, Peter Todd a écrit : > On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev > wrote: > > For that reason, I believe it would be beneficial to the flourishing

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

2022-06-21 Thread Antoine Riard via bitcoin-dev
>> interactions with upper-layers and applications and to listen to feedback >> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I >> know there have been a lot of concerns about full-rbf in the past, however >> I believe the Bitcoin ecosystem has mature

Re: [bitcoin-dev] Package Relay Proposal

2022-06-17 Thread Antoine Riard via bitcoin-dev
Hi Gloria, Thanks for working on that, > Always overestimating fees may sidestep this issue temporarily (while mempool > traffic is low and predictable), but this solution is not foolproof > and wastes users' money. The feerate market can change due to sudden > spikes in traffic (e.g. huge

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

2022-06-17 Thread Antoine Riard via bitcoin-dev
ng to the PR author? Developers should > provide basic RBF policy options rather than attempting to define what > constitutes a good policy and removing the ability to disable something > when necessary. > > > /dev/fd0 > > Sent with Proton Mail <https://proton.me/> secure

[bitcoin-dev] Playing with full-rbf peers for fun and L2s security

2022-06-13 Thread Antoine Riard via bitcoin-dev
Hi list, Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable against the funding flow of any such

[bitcoin-dev] A small tweak to TLUV to enable off-chain cancellation of payment pool transactions

2022-05-16 Thread Antoine Riard via bitcoin-dev
Hi, Proposing a small tweak to TLUV to enable cancellation of an off-chain transaction among a set of pool participants. Namely, to give the index of the constrained output as an opcode item. Using CoinPool terminology, the Withdraw phase happens by a participant publishing an Update transaction

Re: [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories

2022-05-09 Thread Antoine Riard via bitcoin-dev
hout exposing the user to > hot-key vulnerabilities in that always-online system. Double spending is > prevented because the user can access their always-online system to get the > full payment pool state. > > So in short, while I think there may be no way to fundamentally not >

[bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories

2022-04-28 Thread Antoine Riard via bitcoin-dev
Hi, This post recalls the noticeable interactivity issue encumbering payment pools and channel factories in the context of a high number of participants, describes how the problem can be understood and proposes few solutions with diverse trust-minizations and efficiency assumptions. It is

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

2022-04-22 Thread Antoine Riard via bitcoin-dev
Hi Dave, I think the transitory idea is interesting, though I would say it would take far more thinking to capture the implications. > 1. It creates a big footgun. Anyone who uses CTV without adequately preparing for the reversion could easily lose their money. I think that downside should be

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

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

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] Thoughts on fee bumping

2022-02-11 Thread Antoine Riard via bitcoin-dev
Hi James, I fully agree on the need to reframe the conversation around mempools/fee-bumping/L2s though please see my following comments, it's far from simple! > Layering on special cases, more carve-outs, and X and Y percentage > thresholds is going to make reasoning about the mempool harder

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

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

[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

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

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

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

[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

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

  1   2   >