[bitcoin-dev] non-default ports for automatic connections in Bitcoin P2P network
## Using non-default ports for automatic connections in Bitcoin P2P network ISPs can block default port 8333 used by Bitcoin nodes. One example: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010798.html While it would still be possible for crawlers and scanners to know about bitcoin nodes listening on non-default ports using other methods, it can be helpful in lot of countries that use basic things to block: domain, port etc. In October 2021 a [pull request][1] was merged in Bitcoin Core in which lot of contributors agreed to allow non default ports for automatic connections. It did not implement everything, was limited to discussing the concept and allow AddrMan to support multiple ports per IP. It was followed by another [pull request][2] in November 2021 which is still open and makes most of the changes required for non-default ports to work with automatic connections. I could not find any major issues with the changes however had some nits including a discussion on mailing list which was even requested by a few other reviewers. ===Things that I found during my review, research and testing=== 1.One user had posted about issues with default port 8333 on [bitcointalk][3] in July 2010. VMWare server also used port 8333 so an option was requested to change port. This option was added in [May 2011][4] by Gavin Andresen. Gavin has discussed this option and related issues in detail with others on [bitcointalk][5]. 2.I tried running signet for 1 hour v22.0 and 1 hour PR branch with debug=net. v22.0 had only 38333 port with different IPs in debug.log for connections. PR branch had 2 feeler connections with non-default ports 38331 and 13833. Note: Default ports used in Bitcoin Core are 8333(mainnet), 18333(testnet), 18444(regtest) and 38333(signet) 3.Wrote a [PowerShell script][6] and tested it on v22.0 and PR branch which bans all peers every 100 seconds using default port. It works as expected and I could see one peer using port 3111 on signet. 4.I am not sure about the 'bad ports' list in Bitcoin Core added in PR #23542 8333 in leet becomes 'beee' in plain text. Not sure if this was considered by Satoshi to hardcode 8333 for Bitcoin. [1]: https://github.com/bitcoin/bitcoin/pull/23306 [2]: https://github.com/bitcoin/bitcoin/pull/23542 [3]: https://bitcointalk.org/index.php?topic=322.0 [4]: https://github.com/bitcoin/bitcoin/pull/221 [5]: https://bitcointalk.org/index.php?topic=589.0 [6]: https://github.com/prayank23/bitcoin-ps-scripts/blob/main/Scripts/Node/ban_default_peers.ps1 -- Prayank A3B1 E430 2298 178F ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] PathCoin
> Justice. Also, there's no incentive for the honest party to not punish - > presumably their software would automatically punish, and why go through any > effort to stop it? A 1 cent bribe certainly wouldn't be enough. Maybe a $10 > bribe might get someone somewhere to install hacked up software to be able to > fulfill such a bribe, but even then i think it would be a rare person that > would stoop to that. Were it to become a true negotiation, the cheater has > more to lose, and therefore the bribee has a lot of leverage. Justice isn't a strong enough incentive, it's too context-dependent, and in particular it's not something you could rely on if there is any financial incentive pushing the other way. Especially the ordering of events: if you have a counterparty who is malicious and they *take action* to steal, then they can present you with two alternatives one of which is more favourable than the other, if there is a bribe. It isn't *just* about logic I think, though the logic definitely matters. These arguments about whether we could use 'mutually assured destruction' approaches (burn in particular) to make contract enforcement work have been ongoing amongst Bitcoin enthusiasts for a decade, I've always felt strongly that they do not ultimately work and haven't seen anything to change my mind (I seem to remember convincing Manfred Karrer not to use it in Bitsquare in 2014/15, but there've been many other examples of people proposing it and it never really getting traction). > One thing I thought of regarding path coin, if there's ever a situation where > there are multiple choices in path, whatever punishment there is probably > needs to be able to handle the multiple of the number of paths. Right, I briefly alluded to setting up with multiple paths - general idea is instead of only a->b->c->d->e it's possible to setup the n-ary tree, so a can go to all of b,c,d,e etc., but the problem is the factorial blowup that you get even if you restrict to no-revisiting (or exponential otherwise). For the toy example of 5 participants though, it is entirely possible to build the matrix as illustrated in the gist, but it's an N^2 matrix duplicated for every change in the path, here's the simplest possible extension of the base case: path 1: A B* C* D* E* path 2: A B C* D* E* path 3: A B C* D* E* path 4: A B C D* E* path 5: A B C D E path 6: A C* B* D* E* path 7: A C B* D* E* path 8: A C B D* E* path 9: A C B D E* path 10: A C B D E The * would indicate pre-signs (and this whole list is branches in the taproot output of the pathcoin); this setup *only* allows one alternate path (second C instead of second B) for the coin. If A chooses to pay B (not C), then: instead of only giving B an adaptor on path1 and signatures on paths 2,3,4,5, A would also have to give B adaptors on paths 6-10 as well. So it's easy to see that if you kept adding branches for every possible spending path A->E with no revisits you have like n^2(n-1)! (maybe not exactly; something very similar). (Notice: though there are multiple paths via which A can cheat, they all reveal the same adaptor secret (and they're all the same coin) leading to the same forfeit of fidelity bond, see gist for the nice way you can always have it so that a single fidelity bond goes to the honest owner). All of this is predicated on the idea that the participants do *not* coordinate at all after the initial setup; only a data transfer from payer to payee. A pretty massive restriction, of course. Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, January 28th, 2022 at 15:27, Billy Tetrud via bitcoin-dev wrote: >> what is the incentive for the honest party to punish? > > Justice. Also, there's no incentive for the honest party to not punish - > presumably their software would automatically punish, and why go through any > effort to stop it? A 1 cent bribe certainly wouldn't be enough. Maybe a $10 > bribe might get someone somewhere to install hacked up software to be able to > fulfill such a bribe, but even then i think it would be a rare person that > would stoop to that. Were it to become a true negotiation, the cheater has > more to lose, and therefore the bribee has a lot of leverage. > >> my strong intuition is that it will never be properly stable. > > I'm curious what you mean by "stable". You had mentioned the game theory is > "fragile" and I'm wondering if there's more to this than just "what incentive > does the honest party have to burn?" > > To be clear, I'm not advocating for Sabu and I haven't done any deep thinking > about burn based incentives. > > One thing I thought of regarding path coin, if there's ever a situation where > there are multiple choices in path, whatever punishment there is probably > needs to be able to handle the multiple of the number of paths. The only way > around this i can imagine is to have some method of
Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
The hash would normally also cover the hash flags in use, and would be different in those two cases. But yes, it seems at the last minute I did include a suggestion to disable covering the flag themselves in the hash and appear to have accidentally allowed for recursive covenants (a common occurrence when designing opcodes). On Sat, Jan 29, 2022 at 12:01 PM Jeremy Rubin wrote: > > > >> Perhaps there is some misunderstanding. TXHASH + CSFSV doesn't allow for >> complex or recursive covenants. Typically CAT is needed, at minimum, to >> create those sorts of things. TXHASH still amounts to deploying a >> non-recursive covenant construction. >> >> > This seems false to me. > > txhash scriptpubkey> txhash equalverify > > Is that not a recursive covenant? With a little extra work you can also > control for amounts and stuff. > > > >> ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Perhaps there is some misunderstanding. TXHASH + CSFSV doesn't allow for complex or recursive covenants. Typically CAT is needed, at minimum, to create those sorts of things. TXHASH still amounts to deploying a non-recursive covenant construction. This seems false to me. txhash txhash equalverify Is that not a recursive covenant? With a little extra work you can also control for amounts and stuff. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
On Fri, Jan 28, 2022 at 10:14 AM James O'Beirne wrote: > > Technical debt isn't a measure of weight of transactions. > > Sorry, my original sentence was a little unclear. I meant to say that the > notion that CTV is just a subpar waypoint en route to a more general > covenant system may not be accurate if it is a more efficient way (in terms > of chainstate/weight) to express highly useful patterns like vaults. In > that case, characterizing CTV as technical debt wouldn't be right. > It only costs a few more weight units, on the order of 2 or 3, to use TXHASH in place of CTV. Notably, the reverse, using CTV in place of TXHASH, is much more expensive, requiring more than 32 weight units. > > Our only option here is to be mindful of the long term implications of > the design choices we are making today. > > Your points are well taken - I don't think anyone is arguing against > thinking hard about consensus changes. But I have yet to see a proposal for > covenants that is as efficient on-chain and easy to reason about as CTV is. > > I also think there's some value in "legging into" covenants by deploying a > simple, non-recursive construction like CTV that services some very > important uses, and then taking as much time as necessary to think about > how to solve more existential problems, like UTXO scalability, that likely > require a recursive covenant construction. > > There doesn't have to be mutual exclusion in the approaches, especially > when the maintenance burden of CTV seems to be so low. If we end up > deploying something that requires a wider variety of in-script hashing, it > seems likely that CTV's hash will be able to "free ride" on whatever more > general sighash cache structure we come up with. > Perhaps there is some misunderstanding. TXHASH + CSFSV doesn't allow for complex or recursive covenants. Typically CAT is needed, at minimum, to create those sorts of things. TXHASH still amounts to deploying a non-recursive covenant construction. With regards to CTV, in short my primary criticisms are (1) Push semantics is preferable to verify semantics, because simulating verify semantics from push is cheap, while simulating push semantics from verify is not particularly cheap. And (2) given Push semantics we ought to have parameters to support both CTV-style hashes and APO-style hashes (which in the presence of CSFSV gives us APO applications), and, while we are at it, as many other style hashes as we can reasonably devise so we don't have to go through yet another soft-fork process every time someone comes up with a new subset of transaction data they would like to be hashed for their application. I understand why CTV was designed with verify semantics: it would like to be NOP compatible. That certainly made sense pre-tapscript. I just haven't (yet) found the use cases for that compatibility to be compelling in a post-tapscript world. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
