Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
On Wed, Oct 12, 2022 at 04:11:05PM +, Pieter Wuille via bitcoin-dev wrote: > In my view, it is just what I said: a step towards getting full RBF > on the network, by allowing experimentation and socializing the notion > that developers believe it is time. We "believe it is time" for what exactly, though? (a) To start deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or 18 months; or (b) to start switching mainnet mining and relay nodes over to full RBF? As far as experimentation goes, I don't really see this option as being very likely to help: the default for this option is still false, so it's likely going to be difficult to get non-opt-in RBF txs relayed or mined anywhere, even on testnet or signet, no? (Maybe that's a difficulty that's resolved by an addnode, but it's still a difficulty) If experimentation's the goal, making the default be true for testnet/signet at least seems like it would be pretty useful at least. Meaningful experimentation is probably kind of difficult in the first place while fees are low and there's often no backlog in the mempool, as well; something that perhaps applies more to test nets than mainnet even. If we're trying to socialise the idea that zeroconf deprecation is happening and that your business now has a real deadline for migrating away from accepting unconfirmed txs if the risk of being defrauded concerns you, then enabling experimentation on test nets and not touching mainnet until a later release seems fairly fine to me -- similar to activating soft forks on test nets prior to activating it on mainnet. > So I have a hard time imagining how it > would change anything *immediately* on the network at large (without > things like default on and/or preferential peering, ...), but I still > believe it's an important step. If we're instead trying to socialise the idea that relaying and mining full RBF txs on mainnet should be starting now, then I think that's exactly how this *would* change things almost immediately on the network at large. I think all it would take in practice to be able to repeatedly defraud businesses accepting unconfirmed txs is perhaps 5% or 10% of blocks to include full RBF txs [0] [1], and knowing some IP addresses to addnode so that your txs relayed to those miners. And if core devs are advocating that full RBF is ready now [2], and a patch to easily enable it is included in a bitcoin core release, why wouldn't some small pools start trying it out, leading to exactly that situation? If most of the network doesn't relay your full-rbf txs, then that's annoying for protocol developers who'd like to rely on it, but it's fine for an attacker: it just means the business you're trying to trick has less chance of noticing the attack before it's too late, because they'll be less likely to see the conflicting tx via both their own node or public explorers. Cheers, aj [0] A few months ago, Peter Todd reported switching an OTS calendar to do non-opt-in RBF, and didn't observe bumped txs being mined, which seems to indicate there's not much hash power currently mining full RBF. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html [1] Also why I remain surprised that accepting zeroconf is safe enough in practice for anyone to do it. I suppose 5% of hashpower is perhaps $100M+ investment in ASICs and $900k/day in revenue, and perhaps all the current ways of enabling full RBF are considered too risky to mess around with at that level. [2] Antoine Riard's mail from June (that Peter's mail above was in reply to) announced such a public node, and encouraged miners to start adoption: "If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy." Presuming the IRC channel "##uafrbf" stands for "user-activated full rbf", that also seems in line with the goal being to socialise doing full RBF on mainnet immediately... https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html ___ 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
Hello Pieter, Thanks for taking the time to comment! I'll answer inline. On Wed, Oct 12, 2022 at 2:51 PM Pieter Wuille wrote: > I certainly recognize that adding the flag is a likely step towards, over > time, the full RBF policy becoming more widely adopted on the network. That is > presumably the reason why people are in favor of having the flag, even default > off - including me. I believe that policy's adoption is inevitable eventually, > but the speed at which that is achieved is certainly a function of > availability and adopted of software which provides the option. As stated in the original posting, I believe too that a full-RBF network is not only inevitable but also desirable. Miner incentives will eventually win, so we should address them before they fully kick in (ie. before transaction fees become a meaningful portion of the block reward). > So I have a hard time imagining how it would change anything *immediately* on > the network at large (without things like default on and/or preferential > peering, ...), but I still believe it's an important step. Notice that I'm not saying this changes anything immediately on the network at large. In fact, it is unlikely that the opt-in flag alone would be enough to migrate the network at large to full-RBF. There's a real possibility that, after deployment of the opt-in flag, either no meaningful hashing power adopts it or no connected component of transaction-relaying nodes adopts it. If that's the case, the deployment won't help nodes participating in multi-party funded transactions protect against the class of attacks described in [1] (which was, as I understand, the original intention of #25353). If that's not the case, it means that at least some meaningful hashing power adopted it and that there exist some connected components of transaction-relaying nodes that adopted it. This is certainly far from having wide adoption of full-RBF in the network at large. However, once we reach that minimal level of adoption in the mining and relaying layers, any node on a full-RBF connected component can send an on-chain payment to an application and then get a replacement mined. That is, applications that accept incoming on-chain payments from untrusted parties can be immediately exposed to full-RBF transaction replacements, even if they didn't opt into full-RBF in their nodes. In an adversarial setting, such as the one for zero-conf applications (as defined in the original posting), this increases the risk of an attack substantially, making the entire strategy moot. > In my view, it is just what I said: a step towards getting full RBF on the > network, by allowing experimentation and socializing the notion that > developers believe it is time. Those are worthy goals. I believe we can design a deployment strategy for full-RBF that takes them into account and, at the same time, gives a clear timeline for any affected application to adapt. This could be one such proposal: 1. We activate opt-in full-RBF on testnet now. 2. We commit now (in the code) to a block height in the future at which opt-out full-RBF will activate on mainnet. The first point will allow for experimentation and give a testing ground to all affected applications. The second point socializes the notion that developers believe it is time, giving a clear message and timeline for anyone affected to adapt. It also has the benefit that many more nodes will have upgraded by the time we reach the activation block height, making the transition to a full-RBF network much more predictable and easy to reason about. There's an argument to be made that the miner incentive incompatibility problem of a non-full-RBF network gets measurably worse at the time of the next halving. To fix this, we could choose any block height before that, giving a clear and predictable transition timeline. [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html On Wed, Oct 12, 2022 at 1:11 PM Pieter Wuille wrote: > On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns < > a...@erisian.com.au> wrote: > > > On Tue, Oct 11, 2022 at 04:18:10PM +, Pieter Wuille via bitcoin-dev > wrote: > > > > > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via > bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: > > > > > > > Thanks for the fast answer! It seems I missed the link to the PR, > sorry for the > > > > confusion. I'm referring to the opt-in flag for full-RBF from #25353 > > > > (https://github.com/bitcoin/bitcoin/pull/25353). > > > > It is not clear to me why you believe the merging of this particular > pull request poses an immediate risk to you. > > > > > > Did you see the rest of Dario's reply, bottom-posted after the quoted > > text? Namely: > > Oh, my mail client for some reason chose to hide all that. Dario, I'm > sorry for missing this; I see now that you were certainly aware of what the > PR under consideration did. > > Further comments inline. > > > On
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns wrote: > On Tue, Oct 11, 2022 at 04:18:10PM +, Pieter Wuille via bitcoin-dev wrote: > > > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev > > bitcoin-dev@lists.linuxfoundation.org wrote: > > > > > Thanks for the fast answer! It seems I missed the link to the PR, sorry > > > for the > > > confusion. I'm referring to the opt-in flag for full-RBF from #25353 > > > (https://github.com/bitcoin/bitcoin/pull/25353). > > > It is not clear to me why you believe the merging of this particular pull > > > request poses an immediate risk to you. > > > Did you see the rest of Dario's reply, bottom-posted after the quoted > text? Namely: Oh, my mail client for some reason chose to hide all that. Dario, I'm sorry for missing this; I see now that you were certainly aware of what the PR under consideration did. Further comments inline. > On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via > > The question then is whether an opt-in flag for full-RBF will have enough > > adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its > > objective of allowing nodes participating in multi-party funding protocols > > to assume that they can rely on full-RBF. If it is, then zero-conf > > applications > > will be at severe risk (per the logic in the initial email). > > > That logic seems reasonably sound to me: > > - if adding the option does nothing, then there's no point adding it, > and no harm in restricting it to test nets only > > - if adding the option does do something, then businesses using zero-conf > need to react immediately, or will go from approximately zero risk of > losing funds, to substantial risk > > (I guess having the option today may allow you to manually switch your > node over to supporting fullrbf in future when the majority of the network > supports it, without needing to do an additional upgrade in the meantime; > but that seems like a pretty weak benefit) I certainly recognize that adding the flag is a likely step towards, over time, the full RBF policy becoming more widely adopted on the network. That is presumably the reason why people are in favor of having the flag, even default off - including me. I believe that policy's adoption is inevitable eventually, but the speed at which that is achieved is certainly a function of availability and adopted of software which provides the option. That said, I think it's a bit of a jump to conclude that the only two options are that either the existence of the flag either has no effect at all, or poses an immediate threat to those relying on its absence. In my view, it is just what I said: a step towards getting full RBF on the network, by allowing experimentation and socializing the notion that developers believe it is time. So I have a hard time imagining how it would change anything *immediately* on the network at large (without things like default on and/or preferential peering, ...), but I still believe it's an important step. Cheers, -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Validity Rollups on Bitcoin
On Wed, Oct 12, 2022, at 9:28 AM, Greg Sanders wrote: > Is there a one page cheat sheet of "asks" for transaction > introspection/OP_ZKP(?) and their uses both separately and together for > different rollup architectures? We do not have this yet. Trey Del Bonis wrote a more detailed technical post about how those components would be used in a validity rollup, which was cited in my report and can be found here: https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html But it'll take more research and design work to suss out those details you asked for and put them into a nice cheatsheet. I like this idea though! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Validity Rollups on Bitcoin
Thanks for the writeup John, Is there a one page cheat sheet of "asks" for transaction introspection/OP_ZKP(?) and their uses both separately and together for different rollup architectures? On Tue, Oct 11, 2022 at 11:52 AM John Light via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > > Today I am publishing "Validity Rollups on Bitcoin", a report I produced > as part of the Human Rights Foundation's ZK-Rollup Research Fellowship. > > Here's the preface: > > > Ever since Satoshi Nakamoto first publicly announced bitcoin, its > supporters, critics, and skeptics alike have questioned how the protocol > would scale as usage increases over time. This question is more important > than ever today, as blocks are increasingly full or close to full of > transactions. So-called "Layer 2" (L2) protocols such as the Lightning > Network have been deployed to take some transaction volume "offchain" but > even Lightning needs to use _some_ bitcoin block space. It's clear that as > bitcoin is adopted by more and more of the world's population (human and > machine alike!) more block space will be needed. Another thread of inquiry > concerns whether bitcoin's limited scripting capabilities help or hinder > its value as electronic cash. Researchers and inventors have shown that the > electronic cash transactions first made possible by bitcoin could be given > new form by improving transaction privacy, supporting new types of smart > contracts, and even creating entirely new blockchain-based assets. > > > > One of the results of the decade-plus research into scaling and > expanding the capabilities of blockchains such as bitcoin is the invention > of the validity rollup. Given the observed benefits that validity rollups > have for the blockchains that have already implemented them, attention now > turns to the question of whether they would be beneficial for bitcoin and > existing bitcoin L2 protocols such as Lightning, too. We explore this > question by examining validity rollups from several angles, including their > history, how they work on a technical level, how they could be built on > bitcoin, and what the benefits, costs, and risks of building them on > bitcoin might be. We conclude that validity rollups have the potential to > improve the scalability, privacy, and programmability of bitcoin without > sacrificing bitcoin's core values or functionality as a peer-to-peer > electronic cash system. Given the "trustless" nature of validity rollups as > cryptographically-secured extensions of their parent chain, and given > bitcoin's status as the most secure settlement layer, one could even say > these protocols are a _perfect match_ for one another. > > You can find the full report here: > > https://bitcoinrollups.org > > Happy to receive any comments and answer any questions the bitcoin dev > community may have about the report! > > Best regards, > John Light > ___ > 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] Silent Payment v4 (coinjoin support added)
Hi woltx, Thanks for working on silent payments improving it in each version. 1) All inputs being used sounds good although I do not understand how it would benefit coinjoin. 2) New RPC command name is better. > I opened a new PR (#1143) to add a function to convert from x-only to > compressed public key with even y. Not sure about the concerns expressed by Andrew Poelstra in the pull request related to rogue-key attacks. > Tutorial updated: > https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875 > "warnings": "This address is not a new identity. It is a re-use of an > existing identity with a different label." I could not understand the warning in the output for `getsilentaddress` RPC when used with a label. /dev/fd0 Sent with Proton Mail secure email. --- Original Message --- On Tuesday, October 11th, 2022 at 12:32 PM, woltx via bitcoin-dev wrote: > Silent Payment v4 (coinjoin support added) > Changes: > > . Silent payments now use all inputs to create transactions. Previously, they > only used the first input. This change increases privacy and makes silent > payments compatible with coinjoin. > > . `getspaddress` RPC renamed to `getsilentaddress` for clarity > > . Added support for silent payment in PSBT via `walletcreatefundedpsbt` RPC. > > . Added a new index scheme (which stores the sum of input public keys for > each transaction). The previous index > `bitcoin/signet/indexes/silentpaymentindex` should be removed as it is no > longer compatible with this new version. > > For reviewers: > > Now, silent payments use the scheme `hash(i1*X + i2*X + i3*X + ...)*G + X == > hash(x*(I1+I2+I3+...))*G + X`, as described here: > https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs > > As inputs can be Taproot, this introduced a new issue as > `bitcoin-core/secp256k1` does not support x-only public key sum (perhaps due > to missing prefix byte). > > I opened a new PR (#1143) to add a function to convert from x-only to > compressed public key with even y. This is the solution being used by the > current silent payment implementation. > > Tutorial updated: > https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Wallet Fingerprinting with nLocktime and nVersion
Hi Bitcoin Developers, I did some research about nLocktime and nVersion used by some open source Bitcoin wallets. I have written a [blog post][0] co-authored with 'nothingmuch' and this is the first post for the privacy focused blog 'consent': Most wallets use nVersion 2. nLocktime for Bitcoin Core, Knots, Electrum, Sparrow and Specter is nearest block height. However, nLocktime for Bitcoin Core/Knots is zero by default if the transaction is created manually using RPC commands like createpsbt or createrawtransaction. Peter Todd had implemented nLocktime based on anti-fee sniping in [#2340][1] and [#24128][2] implements BIP 326 sequence based anti-fee-snipe for taproot inputs. '0xb10c' has written about wallet [fingerprinting with fee rate][3]. However, nLocktime and nVersion are also important. There may be other factors that might help if a fingerprint matches more than one wallet. Andrew Chow has build a [tool][4] to check if a transaction was created using Bitcoin Core or Electrum. ### Why is wallet fingerprinting important? Consider the following scenario: Alice is spying on Bob and Carol. She suspects one of them is participating in an activity based on a transaction, but she cannot confirm it. She recognizes that one of the wallets that claims to improve privacy was used for these transactions and examines the nVersion and nLocktime. This makes it simpler to identify Bob, who used Wasabi wallet for the transaction with version 1 and nLocktime 0. ### How to fix it? If more wallets have the same nVersion and nLocktime, it will be difficult to identify the wallets used for a transaction. nLocktime could be any nearest block height however version needs to be 2 as most of the wallets use it and it is used for transactions that follow new consensus rules. Please let me know if something incorrect is mentioned or anything important missing about wallet fingerprinting with nLocktime and nVersion. ### Acknowledgements - achow101 - 0xb10c - nothingmuch- RedGrittyBrick [0]: https://consentonchain.github.io/blog/posts/fingerprinting/ [1]: https://github.com/bitcoin/bitcoin/pull/2340 [2]: https://github.com/bitcoin/bitcoin/pull/24128 [3]: https://b10c.me/observations/03-blockchaincom-recommendations/ [4]: https://github.com/achow101/wallet-fingerprinting /dev/fd0 Sent with [Proton Mail](https://proton.me/) secure email.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
