Re: [bitcoin-dev] Bitcoin covenants are inevitable
I think Jorge's request for specifics is reasonable. I agree that we can raise the level of discussion. Each claim about how good or bad a specific BIP is should say why on the technical merits. Comments on prior claims may expose misinformation, expose "trust me" authority, or point out other fallacies. They should include a citation of the original source, a fair restatement of the problematic claim for current readers, and a short explanation of why it doesn't advance understanding technical consensus. There have been lots of mean comments. Some "Truth and Reconciliation" will come due, and it will be a huge amount of work. Another history book? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Packaged Transaction Relay
Hi Suhas/Gloria, Good questions. I've started a new thread because it became something else... Various ideas about packaging seem to be focused on the idea of an atomic message that is gossiped around the network like a transaction or block. From my perspective that seems to create a set of problems without good solutions, and it is not a proper analogy to those atomic structures. It may be worth taking the time to step back and take a close look at the underlying objective. The sole objective, as expressed in the OP proposal, is to: "Propagate transactions that are incentive-compatible to mine, even if they don't meet minimum feerate alone." Effectively producing this outcome with an atomic packaging approach while at the same time maintaining network invariants seems unlikely, if not impossible. Fees: A node knows what fee rate a peer will accept, and announces individual txs that satisfy peer.feerate. Similarly a node knows its own feerate, and SHOULD drop any peer that announces txs that do not satisfy node.feerate. Orphans: A node MAY drop a peer that announces txs that the node sees as orphans against its DAG. It SHOULD drop the orphan tx and MAY request missing ancestors. Presumably after some amount of time connected to peer, node does not expect to see any more orphans from that peer, so these choices could evolve with the channel. However, the design that can only consider each tx in isolation will continue to cause orphan announcements on the channel. A below peer.feerate tx does not get announced to peer, and later a descendant high peer.feerate does get announced to the peer - as an orphan. BIP133 (feefilter): "There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited." https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki Whether the problem is "small" or not depends on the disparity between node fee rates, which is not a matter of protocol. This is an existing problem that can and should be dealt with in packaging, as part of the above objective. Packaged Transaction Relay: One might instead think of packaging as a per-connection function, operating over its transaction (input->output) DAG and the feerate of its own node and that of the peer. Logically a "package" is nothing more than a set of transactions (optimized by announcement). Only a node can effectively determine the packaging required by each of its peers, since only the node is aware of peer.feerate. The only way to avoid dead-ending packages (including individual transactions, as is the objective) is for a node to package txs for each peer. The origination of any package is then just a wallet peer doing what a node does - packaging transactions that satisfy peer.feerate (i.e. that of its node). Current transaction relay (txB->txA): === Node0 txA.feerate > node.feerate, and not orphaned (accept txA) txA.feerate > peer1.feerate (announce txA to peer1) txA.feerate < peer2.feerate (do not announce txA to peer2) - txB.feerate > node.feerate (accept txB) txB.feerate > peer1.feerate (announce txB to peer1) txB.feerate > peer2.feerate (announce txB to peer2) Node1 Sees/accepts txA and txB. Node2 Never sees txA, sees/rejects txB (as an orphan). Packaged transaction relay (txB->txA): === Node0 txA.feerate > node.feerate, and not orphaned (accept txA) txA.feerate > peer1.feerate (announce txA to peer1) txA.feerate < peer2.feerate (do not announce txA to peer2) - txB.feerate > node1.feerate (accept txB) txB.feerate > peer1.feerate (announce txB to peer1) txB.feerate > peer2.feerate (do not announce txB to peer2) <== avoid predictable orphan txA.feerate + txB.feerate > peer2.feerate (announce pkg(A, B) to peer2) <= create minimal package Node1 Sees/accepts txA and txB. Node2 pkg(A, B) > node2.feerate (accept txA, txB) txA.feerate > peer3.feerate (announce txA to peer3) txB.feerate > peer3.feerate (announce txB to peer3) Sees/accepts pkg(A, B). Node3 Sees/accepts txA and txB. <= avoided unnecessary packaging Summary: In this design, any node that receives an announcement for a pkg (or tx) later determined to be less than node.feerate SHOULD drop the announcing peer. Unlike with existing tx relay, a node can become "current" and subsequently see few if any tx or pkg orphans, and MAY at some point decide to drop any peer that announces one. Notice that packages are created dynamically, and any package that doesn't need to be grouped gets trimmed down to individual transactions. Furthermore any tx that is "stuck" can be freed by simply sending another tx. The nodes at which the tx has become stuck will just package it up and relay it to peers. In other words, there is no impact on wallet implementation apart from raising the aggregate fee using a descendant
Re: [bitcoin-dev] Bitcoin covenants are inevitable
Who do you mean by "the non technical folks"? You don't include alicexbt or yourself as a "technical folk", do you? On Wed, Jun 8, 2022 at 8:38 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Wholeheartedly agree with you alicexbt. There are no technical issues that > have been shown that I'm aware of. Once the non-technical folks have time > to discuss it and realize that, I'm hopeful things will move forward. > Perhaps we can learn from this and figure out how to better catch the > attention of the larger bitcoin community for important changes without > alarming them. > > On Sun, Jun 5, 2022 at 2:48 AM alicexbt via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi Jorge, >> >> >> Misinformation is false or inaccurate information, especially that which >> is deliberately intended to deceive. A combination of 'misleading' and >> 'information'. Here are a few examples and I am sure I missed a lot of >> others but its difficult for me to keep a track of everything: >> >> >> 1) Sapio is open source and everything mentioned in tweet is false: >> https://web.archive.org/web/20220503050140/https://twitter.com/coinableS/status/1521354192434073602 >> >> 2) Personal attacks on author of BIP 119 with false information: >> https://nitter.net/s3cp256k1/status/1521238634111770624 >> >> 3) Andreas Antonopoulos shared false things about CTV and explained by >> Ryan in this email: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020414.html >> >> 4) Misleading things shared in these emails by Michael Folkson: >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020286.html >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020343.html >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html >> >> 5) Peter Todd and Zac shared misleading things about BIP 119, bitcoin and >> L2. I replied in this email: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020322.html >> >> 6) Social media influencers like Peter McCormack tweeted they don't >> understand BIP 119 but its an attack (this was even retweeted by developers >> like Peter Todd): >> https://nitter.net/PeterMcCormack/status/1521253840963653632 >> >> 7) Some misconceptions about BIP 119 cleared by Bitcoin Magazine: >> https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained >> >> 8) There were lies and misinformation about BIP 119 on social media >> according to this Bitcoin Magazine article: >> https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it >> >> 9) John Carvalho tweeting false things: >> >> https://nitter.net/BitcoinErrorLog/status/1468599535538745359 >> >> https://nitter.net/BitcoinErrorLog/status/1522652884218822658 >> >> https://nitter.net/BitcoinErrorLog/status/1442554615967354880 >> >> https://nitter.net/search?q=MIT%20(from%3ABitcoinErrorLog) >> >> 10) Greg Maxwell responding to misinformation related to BIP 119 but >> adding false things in the comments: >> https://www.reddit.com/r/Bitcoin/comments/uim560/bip_119/i7dhfpb/ >> >> >> I am not surprised by your email but it would be better if the people who >> are interested in reviewing BIP 119 could raise the bar and not share >> misleading information. >> >> >> /dev/fd0 >> >> >> Sent with Proton Mail secure email. >> --- Original Message --- >> On Sunday, June 5th, 2022 at 12:12 AM, Jorge Timón >> wrote: >> >> >> > "Some people say CTV is contentious, but they're spreading >> misinformation"? Really? Seriously?Come on, guys, we can do better than >> nina jankovich and the "fact checkers". >> > Please, rise the bar. >> > On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> > >> > > Note: This email is an opinion and not an attack on bitcoin >> > > >> > > Covenants on bitcoin will eventually be implemented with a soft fork. >> CTV is the easiest and best possible way OP_TX looks good as well. Apart >> from the technical merits, covenants will improve a few other things: >> > > >> > > - Developers can build interesting projects with real demand in >> market. >> > > - Students learn Sapio and not just solidity. >> > > - Better tooling could be available for application developers. >> > > - Maybe we see bitcoin developer hackathons in different countries. >> > > - Demand for block space might increase, it wont be just exchanges >> and coinjoin. >> > > - Funding of bitcoin developers and projects might improve. Wont need >> to convince a few people for grants. >> > > >> > > **Why covenants are not contentious?** >> > > >> > > Some people may write paragraphs about CTV being contentious, spread >> misinformation and do all
Re: [bitcoin-dev] Package Relay Proposal
Hi, Thanks again for your work on this! One question I have is about potential bandwidth waste in the case of nodes running with different policy rules. Here's my understanding of a scenario I think could happen: 1) Transaction A is both low-fee and non-standard to some nodes on the network. 2) Whenever a transaction T that spends A is relayed, new nodes will send INV(PKGINFO1, T) to all package-relay peers. 3) Nodes on the network that have implemented package relay, but do not accept A, will send getdata(PKGINFO1, T) and learn all of T's unconfirmed parents (~32 bytes * number of parents(T)). 4) Such nodes will reject T. But because of transaction malleability, and to avoid being blinded to a transaction unnecessarily, these nodes will likely still send getdata(PKGINFO1, T) to every node that announces T, in case someone has a transaction that includes an alternate set of parent transactions that would pass policy checks. Is that understanding correct? I think a good design goal would be to not waste bandwidth in non-adversarial situations. In this case, there would be bandwidth waste from downloading duplicate data from all your peers, just because the announcement doesn't commit to the set of parent wtxids that we'd get from the peer (and so we are unable to determine that all our peers would be telling us the same thing, just based on the announcement). Some ways to mitigate this might be to: (a) include a hash (maybe even just a 20-byte hash -- is that enough security?) of the package wtxids (in some canonical ordering) along with the wtxid of the child in the initial announcement; (b) limit the use of v1 packages to transactions with very few parents (I don't know if this is reasonable for the use cases we have in mind). Another point I wanted to bring up is about the rules around v1 package validation generally, and the use of a blockhash in transaction relay specifically. My first observation is that it won't always be the case that a v1 package relay node will be able to validate that a set of package transactions is fully sorted topologically, because there may be (non-parent) ancestors that are missing from the package and the best a peer can validate is topology within the package -- this means that a peer can validly (under this BIP) relay transaction packages out of the true topological sort (if all ancestors were included). This makes me wonder how useful this topological rule is. I suppose there is some value in preventing completely broken implementations from staying connected and so there is no harm in having the rule, but perhaps it would be helpful to add that nodes SHOULD order transactions based on topological sort in the complete transaction graph, so that if missing-from-package ancestors are already known by a peer (which is the expected case when using v1 package relay on transactions that have more than one generation of unconfirmed ancestor) then the remaining transactions are already properly ordered, and this is helpful even if unenforceable in general. The other observation I wanted to make was that having transaction relay gated on whether two nodes agree on chain tip seems like an overly restrictive criteria. I think an important design principle is that we want to minimize disruption from network splits -- if there are competing blocks found in a small window of time, it's likely that the utxo set is not materially different on the two chains (assuming miners are selecting from roughly the same sets of transactions when this happens, which is typical). Having transaction relay bifurcate on the two network halves would seem to exacerbate the difference between the two sides of the split -- users ought to be agnostic about how benign splits are resolved and would likely want their transactions to relay across the whole network. Additionally, use of a chain tip might impose a larger burden than is necessary on software that would seek to participate in transaction relay without implementing headers sync/validation. I don't know what software exists on the network, but I imagine there are a lot of scripts out there for transaction submission to the public p2p network, and in thinking about modifying such a script to utilize package relay it seems like an unnecessary added burden to first learn a node's tip before trying to relay a transaction. Could you explain again what the benefit of including the blockhash is? It seems like it is just so that a node could prioritize transaction relay from peers with the same chain tip to maximize the likelihood of transaction acceptance, but in the common case this seems like a pretty negligible concern, and in the case of a chain fork that persists for many minutes it seems better to me that we not partition the network into package-relay regimes and just risk a little extra bandwidth in one direction or the other. If we solve the problem I brought up at the beginning (of de-duplicating package data across peers
Re: [bitcoin-dev] Bitcoin covenants are inevitable
Wholeheartedly agree with you alicexbt. There are no technical issues that have been shown that I'm aware of. Once the non-technical folks have time to discuss it and realize that, I'm hopeful things will move forward. Perhaps we can learn from this and figure out how to better catch the attention of the larger bitcoin community for important changes without alarming them. On Sun, Jun 5, 2022 at 2:48 AM alicexbt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Jorge, > > > Misinformation is false or inaccurate information, especially that which > is deliberately intended to deceive. A combination of 'misleading' and > 'information'. Here are a few examples and I am sure I missed a lot of > others but its difficult for me to keep a track of everything: > > > 1) Sapio is open source and everything mentioned in tweet is false: > https://web.archive.org/web/20220503050140/https://twitter.com/coinableS/status/1521354192434073602 > > 2) Personal attacks on author of BIP 119 with false information: > https://nitter.net/s3cp256k1/status/1521238634111770624 > > 3) Andreas Antonopoulos shared false things about CTV and explained by > Ryan in this email: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020414.html > > 4) Misleading things shared in these emails by Michael Folkson: > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020286.html > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020343.html > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html > > 5) Peter Todd and Zac shared misleading things about BIP 119, bitcoin and > L2. I replied in this email: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020322.html > > 6) Social media influencers like Peter McCormack tweeted they don't > understand BIP 119 but its an attack (this was even retweeted by developers > like Peter Todd): > https://nitter.net/PeterMcCormack/status/1521253840963653632 > > 7) Some misconceptions about BIP 119 cleared by Bitcoin Magazine: > https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained > > 8) There were lies and misinformation about BIP 119 on social media > according to this Bitcoin Magazine article: > https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it > > 9) John Carvalho tweeting false things: > > https://nitter.net/BitcoinErrorLog/status/1468599535538745359 > > https://nitter.net/BitcoinErrorLog/status/1522652884218822658 > > https://nitter.net/BitcoinErrorLog/status/1442554615967354880 > > https://nitter.net/search?q=MIT%20(from%3ABitcoinErrorLog) > > 10) Greg Maxwell responding to misinformation related to BIP 119 but > adding false things in the comments: > https://www.reddit.com/r/Bitcoin/comments/uim560/bip_119/i7dhfpb/ > > > I am not surprised by your email but it would be better if the people who > are interested in reviewing BIP 119 could raise the bar and not share > misleading information. > > > /dev/fd0 > > > Sent with Proton Mail secure email. > --- Original Message --- > On Sunday, June 5th, 2022 at 12:12 AM, Jorge Timón > wrote: > > > > "Some people say CTV is contentious, but they're spreading > misinformation"? Really? Seriously?Come on, guys, we can do better than > nina jankovich and the "fact checkers". > > Please, rise the bar. > > On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > Note: This email is an opinion and not an attack on bitcoin > > > > > > Covenants on bitcoin will eventually be implemented with a soft fork. > CTV is the easiest and best possible way OP_TX looks good as well. Apart > from the technical merits, covenants will improve a few other things: > > > > > > - Developers can build interesting projects with real demand in market. > > > - Students learn Sapio and not just solidity. > > > - Better tooling could be available for application developers. > > > - Maybe we see bitcoin developer hackathons in different countries. > > > - Demand for block space might increase, it wont be just exchanges and > coinjoin. > > > - Funding of bitcoin developers and projects might improve. Wont need > to convince a few people for grants. > > > > > > **Why covenants are not contentious?** > > > > > > Some people may write paragraphs about CTV being contentious, spread > misinformation and do all types of drama, politics etc. on social media but > there are zero technical NACKs for CTV. We have discussed other covenant > proposals in detail on mailing list and IRC meetings with an open minded > approach. > > > > > > All the developers that participated in the discussion are either okay > with CTV or OP_TX or covenants in general. > > > > > > **How
Re: [bitcoin-dev] bitcoin-dev Digest, Vol 85, Issue 4
That sounds like an interesting mechanism to help measure consensus - and a good way to do that would help bitcoin significantly I think. I don't quite see what the similarity is between Trust Metric and bitcoin tho. How would you propose "building it into" bitcoin? >From my limited searching, it looks like trust metric is basically a graph of who trusts who, allowing you to quantify who's trusted among a particular set or subset of people. Is that right? I would think such a thing can be done completely separately from bitcoin, but used to answer questions about bitcoin. I'm curious to know specifically how the metric works and how its resistant to adversaries, specifically how its sybil resistant. In particular I'm curious what weaknesses it has that could be gamed. It seems sybil resistance might be there for a while, but I can imagine that it might be possible for a colluding set of users to farm aliases with higher and higher reputation until they could take over the network. In bitcoin, there are good ways of bolstering such sybil resistance, eg by charging fees for identities in some way, or by requiring proof of funds. On Sun, Jun 5, 2022 at 8:19 AM Luke Kenneth Casson Leighton via bitcoin-dev wrote: > (apologies i am subscribed digest) > > On Sun, Jun 5, 2022 at 1:00 PM > wrote: > > > Date: Sun, 05 Jun 2022 04:18:04 + > > From: alicexbt > > To: Bitcoin Protocol Discussion > > > > Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable > > Message-ID: > > > > protonmail.com> > > Hi Jorge, > > > > > > Misinformation is false or inaccurate information, especially that which > is deliberately intended to deceive. > > A combination of 'misleading' and 'information'. > > it's a classic technique that was refined by psy-ops well over > 60 years ago. it should come as no surprise at all that it is > being systematically deployed to undermine bitcoin. > (welcome to the party, all psy-ops teams reading this: i admire your > persistence and tenacity. you serve an extremely useful purpose > of detecting flaws in the resilience of bitcoin and its development.) > > a potential solution is Trust Metrics. the most successful open > source experiment in that regard was advogato.org by Raph Levien. > > i expanded it greatly so that any user could specify the "seeds" > whom *they* trusted, rather than being forced to utilise the fixed > hard-coded user ids in the advogato.org source code (this difference > is extremely important for de-centralisation) > > public declarations of trust, and their propagation through standard > Maximum-Flow Graph analysis, helps greatly to filter out the crap. > advogato deflected heavy systematic and sustained spam attacks > thanks to the simple expedient of users declaring publicly whom > they trusted. > > a more advanced version of the max-flow concept came up a few > years later called keynote (RFC2704) > > the similarity between trust metric evaluation and the bitcoin protocol > is so remarkable that i am, frankly, slightly stunned that it was not > added right from the start. > > it is ironic that the lack of integrated trust metric evaluation built-in > to the bitcoin protocol is now hampering developers from being able > to evaluate whom to trust when it comes to protocol development. > > l. > ___ > 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
