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...
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
> 2. Whether it's ok to require that the child not have
> 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
> 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
<> 2 IN_OUT_AMOUNT
The empty vector is a
> A package may contain transactions that are already in the mempool. We
> ("deduplicate") those transactions from the package for the purposes of
> mempool acceptance. If a package is empty after deduplication, we do
IIUC, you have a package A+B+C
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 :
Sorry for the lack of clarity, sometimes it sounds easier to explain ideas
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
Thanks for finally putting the pieces together! 
We've been hacking with Gleb on a paper for the CoinPool protocol 
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
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
> 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
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 . Of course, we
can adjust the LN security model around dust handling to mitigate the
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
On Thu, May 27, 2021 at 04:14:13PM -0400, Antoine Riard via bitcoin-dev
> This overhead could be smoothed even further in the future with more
> sighash malleability flags like SIGHASH_IOMAP, allowing transaction
> commit to a map of inputs/outputs . In th
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 <
> 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
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
> That might work for current LN-penalty, but I'm not sure it works for
Well, we have not settled yet on the eltoo design but if we take the later
proposal in date , signing the update transaction with
SIGHGASH_ANYPREVOUT lets you attach non-interactively a single-party
> 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
> It's a big
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
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
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
>>> OP_CHECKSIGADD(p2-fee-bump-key, ) OP_2
>>> 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
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
fee bumping without DoS or pinning attacks but hopefully I
> have demonstrated that this class of solutions also exists.
>  https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
> On Fri, 28 May 2021 at 07:13, Antoi
> 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,
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
I think that's a really interesting point, it's likely that such
transaction graphs with multiple
> Unfortunately, ACP | SINGLE is trivially pinable  (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
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
Following-up on the workshop announcement , 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
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
> (Note this isn't a vulnerability in Bitcoin Core; BIP125 is strictly a
> matter, not part of the consensus rules and never safe to r
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 ?
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
Bip 125 specification describes the following
> 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
> Anyway, looking forward to discussions :)
> On Fri, Apr 23, 2021 at 8:51 AM
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
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
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 . I think those areas require
significant improvements to ease design and deployment of higher
> I believe this is what BIP 60 does, or did you have something else in
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
> 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
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
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 .
Thanks for starting this thread, that's a really relevant discussion
> * 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
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
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
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
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.
> Sponsor Vector TXIDs must also be
> in the block the transaction is validated in, with no restriction on
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
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
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
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
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
(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)
Lightning security model relies on the
> 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
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
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
Well your deeclipser is already WIP ;)
See my AltNet+Watchdog proposals in Core:
It's almost covering what you mention, a driver framework to plug
alternative transports protocols : radio,
> (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
> * At the same time, it retains your-keys-your-coins noncustodiality,
because every update of a Lightning channel requires your keys to sign off
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
> > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> > email@example.com> wrote:
> >> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> >>> Trust-minimization of Bitcoin security
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
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
may have multiples options:
>> * halt the wallet, wait for human intervention
>> * fallback connection to a trusted server, authoritative on your chain
>> * invalidity proofs?
>> Now I agree you need a wide-enough, sane backbone network to build on
> As a result, the entire protocol could be served over something like
HTTP, taking advantage of all the established CDNs and anycast serving
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
> 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
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
I didn't trust myself and verify. In fact the  is the real .
Le mar. 5 mai 2020 à 06:28, Andrés G. Aragoneses a
> Hey Antoine, just a small note,  is missing in your footnotes, can you
> add it? Thanks
> On Tue, 5 May 2020 at 18:17, Antoine Riard
(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
> 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
That's an interesting idea, but an attacker can create a local conflict in
and then send the preimage tx to make hit recentRejects
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 , but what
we found is you
can _reverse_ the scenario, where it's not the
> 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
> 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
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 <
Coinjoins interceptions seem to raise at an increasing pace. Their onchain
fingerprint (high-number of inputs/outputs, lack of anti-fee snipping,
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
> 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
> likely to extract a rent from you as "ransom" for properly closing your
> (or in other words, in a contested close the value of the
Mail list logo