Re: [bitcoin-dev] Merkleize All The Things
On 2022-11-07 23:17, Salvatore Ingala via bitcoin-dev wrote: Hi list, Hi Salvatore!, I have been working on some notes to describe an approach that uses covenants in order to enable general smart contracts in bitcoin. You can find them here: https://merkle.fun I haven't yet been able to understand everything in your post, but I'm wondering if you can describe how your proposal significantly differs in application from [1]? E.g., you write: 1. Alice posts the statement “f(x) = y”. 2. After a challenge period, if no challenge occurs, Alice is free to continue and unlock the funds; the statement is true. 3. At any time before the challenge period expires, Bob can start a challenge: “actually, f(x) = z”. That looks to me very similar to Gregory Maxwell's script from[1] (comments and variable name changes mine): # Offchain, Alice posts the statement f(x) = y # Offchain, Bob provides Ex, an encrypted form of x that can be proven in zero knowledge to satisfy both f(x) = y and sha256(x) = Y OP_SHA256 OP_EQUAL OP_IF # Bob provided the preimage for Y, that preimage being the solution, so he can spend the funds now OP_ELSE # The challenge period ended, so Alice can reclaim her funds OP_CHECKLOCKTIMEVERIFY OP_DROP OP_ENDIF OP_CHECKSIG Thanks and apologies if I'm missing something obvious!, -Dave [1] https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
--- Original Message --- On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev wrote: > I mean, if you think the feedback is wrong, that's different: maybe we > shouldn't care that zeroconf apps are in immediate danger, and maybe > bitcoin would be better if any that don't adapt immediately all die > horribly as a lesson to others not to make similarly bad assumptions. I've been following this discussion, and I wonder if there isn't a third solution outside of "leave lightning vulnerable to pinning by non-RBF translations" and "kill zeroconf by introducing full-RBF" - specifically, adding a form of simple recursive covenant that "all descendant transactions of this transaction must use opt-in RBF for x blocks after this transaction is mined". This could be introduced either as a relay/mempool policy like RBF, or in a full-fledged softfork. Based on my admittedly not all-encompassing understanding of the bitcoin transaction format, there are several unused bits in nSequence, which is already used to flag RBF, that might be repurposed to flag the duration of this lock. Say if two bits were used for this, that would be enough to flag that the restriction is not used, or active for 100, 1000 and 1 blocks. I'm sure there may be other and potentially better ways of enabling this type of covenant, but I'll leave that to the people who actually live and breathe the bitcoin transaction format. -- Regards, ArmchairCryptologist ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
technically, all we need is for *miners* to consistently mine "full
rbf"
There's another important point I think:
technically, all we need is for *miners* to consistently mine the
highest fee-rate transaction (or the one with the most incentive).
Miners could probably be incentivized to mine transactions that double
spend a previous transaction that isn't rbf, also.
Cheers,
-Yancy
On 2022-11-03 14:32, Erik Aronesty via bitcoin-dev wrote:
actually, peter makes an important point here
technically, all we need is for *miners* to consistently mine "full
rbf"
as long as they do, businesses that accept 0conf will have to adjust
their risk accordingly, and the problem of misaligned incentives is
resolved
i don't think it matters what non-mining users do nearly as much
On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev
wrote:
Hi Peter,
tl;dr: I'm broadcasting full-RBF replacements paying extremely high
fees to reward miners that turn on full-RBF. I'm starting small, just
~$100/block in times of congestion. Miner and pool profit margins are
pretty small, on the order of $1k/block in many cases, so I know it
doesn't take that much more money to make a difference.
I appreciate this effort and perhaps this was all that was needed in
addition to Bitcoin Core's inclusion of full rbf support. Making it
default right away or enabling preferential peering with service
flag in a bitcoin core release was unnecessary.
If you'd like to donate to this effort, send BTC to
bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
Sorry, I don't trust you based on some of the things you support on
Twitter. Hopefully, others will donate and help this bounty.
/dev/fd0
Sent with Proton Mail secure email.
--- Original Message ---
On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via
bitcoin-dev wrote:
I'm now running a full-RBf bounty program for miners.
tl;dr: I'm broadcasting full-RBF replacements paying extremely high
fees to reward miners that turn on full-RBF. I'm starting small, just
~$100/block in times of congestion. Miner and pool profit margins are
pretty small, on the order of $1k/block in many cases, so I know it
doesn't take that much more money to make a difference.
Why should you do this? Full-RBF/zeroconf has been discussed to death.
But tl;dr: You'll earn more money, and help transition Bitcoin to a
more secure mempool policy based on economic incentives rather than
trust.
If you're a miner and want to participate, the easiest way to so is to
use the mempoolfullrbf=1 option in the upcoming Bitcoin Core v24
release (eg the 24.0rc3 tag), or use the mempoolreplacement=fee option
in Bitcoin Knots.
You can also just modify the code yourself by removing the opt-in RBF
check. For example against the v23.0 tag:
$ git diff
diff --git a/src/validation.cpp b/src/validation.cpp
index 214112e2b..44c364623 100644
--- a/src/validation.cpp
+++ b/src/validation.cpp
@@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args,
Workspace& ws) // check all unconfirmed ancestors; otherwise an opt-in
ancestor
// might be replaced, causing removal of this descendant.
if (!SignalsOptInRBF(*ptxConflicting)) {
- return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
"txn-mempool-conflict"); + // return
state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
"txn-mempool-conflict"); }
ws.m_conflicts.insert(ptxConflicting->GetHash());
Once you've enabled full-RBF, you need a full-RBF peer. I'm running a
few of them:
cup.nop.lol
mug.nop.lol
jar.nop.lol
jug.nop.lol
These nodes run a preferential peering patch
(https://github.com/bitcoin/bitcoin/pull/25600) to ensure that full-RBF
nodes are interconnected to each other and replacements can easily
propagate. Also feel free to contact me if you'd like to peer with a
private node.
If you'd like to donate to this effort, send BTC to
bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
...and yes, I'm well aware that miners could collect this bounty in
other ways, eg by raising minimum fees. Doing that also breaks
zeroconf, so I'm not too concerned.
--
https://petertodd.org 'peter'[:-1]@petertodd.org [1 [1]]
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
--
[1] http://petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
--
[1] http://petertodd.org___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On mempool policy consistency
Bob has staked liquidity in a payment channel with Alice who later double spends the same inputs (at a very low feerate) resulting in a stalemate where neither can spend the UTXOs. I just realized I made a mistake. RBF will always mine the higher fee transaction, so in this case, full-rbf would prevent a transaction from being pinned. On 2022-11-08 15:54, yancy via bitcoin-dev wrote: Peter, It sounds like there are two attack vectors; neither of which require full-rbf (correct me if I'm wrong). 1) Bob has staked liquidity in a payment channel with Alice who later double spends the same inputs (at a very low feerate) resulting in a stalemate where neither can spend the UTXOs. The TX that creates the payment channel with Bob will never be mined since the mining pool sees the double spend? 2) Alice spams the network with a double spend wide enough that the double spend makes it into a block before the remainder of the network sees the first spend. In that case of 1), what if Bob required a opt-in rbf? Wouldn't that solve the issue? Bob could just create a replacement transaction with enough fee to get back his UTXO? For 2) it seems to me that neither full-rbf or opt-in rbf resolves this, although it's a probabilistic attack and requires spamming many nodes. Cheers, -Yancy On 2022-11-07 15:32, Peter Todd wrote: On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev wrote: AJ/Antoine et al What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to solve that problem if they have only opt-in RBF available? Assuming Alice is a well funded advisory, with enough resources to spam the network so that enough nodes see her malicious transaction first, how does full-rbf solve this vs. opt-in rbf? First of all, to make things clear, remember that the attacks were talking about are aimed at _preventing_ a transaction from getting mined. Alice wants to cheaply broadcast something with low fees that won't get mined soon (if ever), that prevents a protocol from making forward progress. With full-rbf, who saw what transaction first doesn't matter: the higher fee paying transaction will always(*) replace the lower fee one. With opt-in RBF, spamming the network can beat out the alternative. *) So what's the catch? Well, due to limitations in today's mempool implementation, sometimes we can't fully evaluate which tx pays the higher fee. For example, if Alice spams the network with very _large_ numbers transactions spending that input, the current mempool code doesn't even try to figure out if a replacement is better. But those limitations are likely to be fixable. And even right now, without fixing them, Alice still has to use a lot more money to pull off these attacks with full-rbf. So full-rbf definitely improves the situation even if it doesn't solve the problem completely. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime
On Mon, Nov 07, 2022 at 05:55:59PM -0500, Antoine Riard wrote:
> 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 would replace
> > transaction(s)
> > attempting to exploit Rule #3 pinning (note how the package limits in
> > Bitcoin
> > Core help here).
>
> From my understanding, there are many open questions to such a
> pre-signed high-fee solution aiming to address Rule #3 pinning.
> Determining the high-fee to guarantee replacements with high odds. I
> think it should be superior to current top network mempools sat/vb *
> MAX_STANDARD_TX_WEIGHT, otherwise an adversary can pin the multi-party
> funded transaction on the ground of Core's
> replacement rule ("The replacement transaction's feerate is greater
> than the feerates of all directly conflicting transactions''). Though
> note the difficulty, the sat/vb is an unknown fact at time of
> signatures exchange among the multi-party funded transaction
> participants. Solving this issue probably requires from then to
> overshoot, and adopt a historical worst-case mempool feerate.
First of all, since this is a punishment scenario, overshooting in general is a
good thing provided that the bad actor is the one paying for the overshoot.
I may be mistaken on this point. But IIRC rule #6, "The replacement
transaction's feerate is greater than the feerates of all directly conflicting
transactions.", refers to the overall package feerate including all
transactions that would need to be mined.
This is relevant as we have two scenarios for pinning that could try to exploit
rule #6 while pinning, and neither works:
1) A large, low fee rate, transaction is spent by a high fee rate transaction.
In this case the package fee rate of the second tx is still low, because the
low fee rate tx would need to be mined first.
2) A small, high fee rate tx, is spent by a large low fee rate tx. In this case
the second low fee rate tx is irrelevant, because the high fee rate tx will get
mined soon, breaking the pin and costing the attacker money.
Now, if my understanding of rule #6 is incorrect, obviously we should fix that!
It's incentive incompatible to reject a high fee rate replacement that overall
pays more in fees (rule #3), on the basis that we expect a *different* miner to
mine the low fee rate tx it spends. Because unless we're expecting the
transaction to somehow get mined by someone else in the near future, why aren't
we mining what pays more money now?
> This "historically-worst" sat/vb introduces two new issues, first I
> think this is an economic lower bound on the funds that can be staked
> in the collaborative transaction. Second I believe this constitutes a
> griefing vector, where a participant could deliberately pin to inflict
> an asymmetric damage, without entering into any fee competition. This
> griefing vector could be leveraged as hard as being triggered by a
> miner-as-participant in so-called miner harvesting attacks.
>
> Further, I think this solution relying on nLocktime doesn't solve the
> timevalue DoS inflicted to the participants UTXOs, until the
> pre-signed high-fee transaction is final. If participants prefer to
> save the timevalue of their contributed UTXOs over operation success,
> a better approach could be for them to unilaterally spend after a
> protocol/implementation timepoint (e.g LN's funding timeout recovery
> mechanism).
>
> A more workable solution I believe could be simply to rely on
> package-relay, an ephemeral anchor output, and a special replacement
> regime (e.g nVersion=3) to allow the multi-party funded transaction
> coordinator to unilateral fee-bump, in a step-by-step approach. I.e
> without making assumptions on the knowledge of network mempools and
> burning directly the worst amount in fees.
Note that if you are considering miner harvesting attacks as part of the threat
model, it's not clear to me that the v3 rules that depend on miners arbitrarily
rejecting transactions from their mempools are actually sufficiently incentive
compatible to work.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Merkleize All The Things
On Tue, Nov 08, 2022 at 03:34:32PM -0800, Bram Cohen via bitcoin-dev wrote: > Another probably unhelpful bit of feedback I have is that Bitcoin should > probably be taking verkle trees seriously because those can have > substantially lower size/cost/weight than merkle trees. That doesn't just > apply to this proposal, but to Bitcoin in general, which doesn't seem to > have any serious verkle tree proposals to date. Verkle trees only reduce proof sizes by a factor of 6-8, and they introduce significant implementation complexity and new cryptographic assumptions. Better to let other crypto-systems get a few more years of experience with them before adding them to Bitcoin. Particularly since even having merkle trees in Bitcoin is arguably a mistake: they allow for degenerate, weak, security modes like SPV that aren't clearly good for Bitcoin as a whole. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
