Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols
>> "Can a V2 transaction replace a V3 transaction and vice versa?" > Circling back to my ACP point, this regime still allows pinning anytime you are sharing a transaction with someone else where you don't have control over *all* the inputs. So anytime you are doing a coinjoin-like transaction, someone else's inputs can be self-double-spent, requiring you to satisfy rule#3 when replacing theirs, if they're bip125-signaling. If they're not bip125 signaling, you'll have to somehow detect this and/or double-spend your input back to yourself. Talking with someone offline I realized we can un-pin coinjoins with V3 which I previously thought untenable. You "just" have to stage all utxos that are going to be mixed in separately into a timelocked utxo that is immediately spendable by all joining parties(or the person and the coinjoin coordinator who is trusted to not pin, they're taking fees usually anyways). Then once all utxos for a mix are staged, continue the coinjoin as before with V3. You only need a timelock long enough to stop pinning; not very long. If you do 2-of-2 with a coordinator, you can start the join whenever you think you have enough utxos staged. If using coordinator model, you can then do this in a chained fashion, doing mix after mix, with only one utxo setup step. Seems really obvious in retrospect, with the downside of one additional tx per mixing participant and less composability with other protocols. Just thought it important to point out in public, in lieu of a "real" fix like replace by feerate which hasn't been designed yet. Cheers, Greg On Fri, Sep 23, 2022 at 2:48 PM Greg Sanders wrote: > Hello Gloria, > > Great work on synthesizing so much feedback into a proposal like this! > > Death to carve-out rule. > > I'd like to elaborate on some caveats and give a few incomplete thoughts. > > There are basically two types of pinning in my estimation today: > > 1) rule#3 pinning: Make it uneconomical to replace whatever is in mempool > via large in size but low feerate junk that won't get mined anytime soon. > Replacing this with feerate-based policy seems apt, but fraught with DoS > risks. > > 2) package limit pinning: disallowing transaction propagation by package > limits being hit: size, ancestor count, descendant count. Today it is > mitigated by having all outputs be 1 csv timelocked, and having up to 2 > anchor outputs(1 without carve-out rule). > > Would kind of be nice if package RBF would detect a "sibling output spend" > conflict, and knock it out of the mempool via the other replacement rules? > Getting rid of the requirement to 1 block csv lock every output would be > quite nice from a smart contracting composability point of view. > > > "Does this fix Rule 3 Pinning?" > > As you likely know from previous discussions the biggest scenario this > does not fix in my estimation is ANYONECANPAY situations. If the parent > transaction can be "inflated" by tacking on additional inputs, this means > the total weight of the parent tx lowers the effective feerate of the > package. Due to this pinning attack there aren't many(?) deployed schemes > that use the signature type. > > To mitigate this we would likely have to opt into a more complex policy > scheme, committing in the annex to "total mempool package weight", which > would allow mempool package limits to be picked at signing time. > > Maybe ANYONECANPAY isn't a very useful paradigm in general, I cannot speak > to that, but it came up in eltoo-related designs using BIP118, which adopts > ACP-like signing behavior. This can be mitigated via straight forward > policy updates as well for BIP118 deployment, but off topic so will leave > it there. > > The other scenario it doesn't really fix is where HTLC/commitment-like > transactions are being resolved in a batch, but due to relative time > constraints, you may want to accelerate some and not others. Now you must > pay higher rates to replace all of the transaction bumps. This is a > "self-pin" and "get good at utxos noob" type problem, but it's something > that axing rule#3 in favor of a Replace-by-ancestor-feerate system would > get us. > > > "Can a V2 transaction replace a V3 transaction and vice versa?" > > Circling back to my ACP point, this regime still allows pinning anytime > you are sharing a transaction with someone else where you don't have > control over *all* the inputs. So anytime you are doing a coinjoin-like > transaction, someone else's inputs can be self-double-spent, requiring you > to satisfy rule#3 when replacing theirs, if they're bip125-signaling. If > they're not bip125 signaling, you'll have to somehow detect this and/or > double-spend your input back to yourself. > > > Finally, a couple suggestions I've already made elsewhere: > > 1) I do think that we should seriously consider allowing OP_TRUE to become > a standard script type as part of this policy update. If pinning is solved, > then there's no reason to require all those extra bytes for "binding"
[bitcoin-dev] CivKit Node v0.0.1 release - "Sic itur ad astra"
Hi Bitcoin Devs, Proud to announce the first release of CivKit Node, a basic Nostr relay with additional features to have a functional peer-to-peer market board, written in Rust [0]. This is a very raw release as since we published the paper back in April, we've been reached out by a bunch of folks asking how they could contribute by code, or start to integrate CivKit in their Nostr and Lightning peer-to-peer market clients [1]. Current release is CLI-only, just implementing basic NIP 01 support and is full of bugs and todos, has not been tested on a lot of platforms and still works as a local host for a lot of things [2]. There is a sample Nostr client binary joined for deployment and testing purposes and an utility binary to manage the node with a gRPC interface. Such an interface should lay the groundwork to build one or more GUI applications on top, as it's a recurring and consistent request from the community. There is an experimental integration with BOLT8 Noise transport (thanks to LDK), where one can connect to another CivKit Node has a peer, Idea is to unify the communication infrastructure between Nostr and Lightning, and as such have a single market of p2p service providers (watchtower, state backup, boards) benefiting from network law effect. Beyond sharing all the work between Lightning and Nostr ecosystem in terms of spamming mitigations, careful crypto engineering (e.g onion routing) and privacy-preserving monetary credentials [3]. With this released out, I think we'll go for sound onion routing support, BOLT12 offers, the set of fundamental NIPs like NIP-09, NIP-16, NIP-33 and others, and integration with a notary protocol (e.g Mainstay). Still, we would like to listen to our users and we'll plumber features in the function of relevant feedback collected from the community. One key lesson from years contributing on LDK, we do not want to stay in a "purist developer" ivory tower to avoid hard-to-integrate APIs, and make the "product management" of the project owned by the community to ensure we're building for the real-world of unstable and constrained mobile clients. Once we have communication infrastructure and hopefully credentials framework working, I think we'll start to have more serious development of the CivKit functionaries services themselves (e.g market bulletin boards, rank proof servers and moderation oracles in the paper parlance). Though again, if folks want to start more custom services on top of CivKit Node, we'll see what we can do, there is a brave new world to explore with Nostr and Lightning maturation. For the historical note, peer-to-peer market features were present in Bitcoin Core circa 2010 (in fact before the ref client was dubbed Core). Those features were removed by commit 5253d1ab "strip out unfinished product, review and market stuff" by Satoshi [4]. Retrospectively, it was a good insight as Core has evolved as a complex beast enough and careful layerization is one of the best learning from the 50 years of Internet history. Still, censorship-resistant and large-scale peer-to-peer markets sounds still one of the missing blocks of the Bitcoin protocol stack. Looking forward to growing the Bitcoin and Lightning internal economies by an order of magnitude or two with the CivKit Node, if the kharma is with us. All works are released under MIT/Apache licenses and we aim to bind to the best open-source development standards as set by Bitcoin Core and the Linux kernel communities and we're welcoming anyone strongly willing to build with passion and love. I think for the future, we'll do the announcement on its own communication channel, whatever a new mailing list, or something experimental on top of Nostr groups, Still, if we innove in terms of cryptography we're aiming to have things standardized under BIPs. "Sic itur ad astra" - Block 00053fd09a45f48e747f281122021edc2f7e97efcdd66248 Cheers, Antoine [0] https://github.com/civkit/civkit-node [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021556.html [2] Of course, there are gazillins of things to implement, please open an issue on the repository directly rather to yell something doesn't work. [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html [4] https://github.com/bitcoin/bitcoin/commit/5253d1ab ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
