There is a shitty/scammy ethereum ICO thing right now giving people shares in exchange for testnet btc, this is totally screwing up the usability of testnet and also causing antisocial dickwads to waste all our time begging for testnet coins without disclosing that the only thing they want them for is to make a quick buck.

I will be editing posts in this thread to remove any testnet addresses people paste.

I don't think it's *that* concerning. If they set the feerate to zero the txn won't confirm.. but they could also just take their service down.

If they set the feerate very high-- well in most cases they could just substitute the JS/app or guess the user's usually-weak password and simply take their coins directly.

Not by much: only to the extent that they increased the fee of transactions that weren't making it into blocks.

E.g. Say you add 1MW/block of transactions paying 0.001 BTC / WU in fees -- this would have the same effect on Core's estimator as if you added 1MW/block of txn paying 0.1 BTC/ WU in fees.  All that matters is that they were high enough to push things out... it's the feerate of the things that were actually delayed (and which were later confirmed) which drive the estimator.

It appears to me that they already bid pretty high too, enough that increasing their high fee would have no effect on what bitcoin-qt pays, and increasing their low fee would do no more than switching their users all from low to high would.

Are there even any open source mesh protocols which are viable and maintained,  searching for a bit left me with a lot of stuff that hasn't changed in 4+ years.

My post makes more sense read forwards rather than backwards.   The satellite is an additional feed that helps you get the benefit of diversity without a monthly fee.

By itself it's a single connection, as you say.

Meh, it's not wrong of someone to ask. Of course, everyone said no.  Plus, he had gotten bad advice from people who misleading represented themselves as authorities.

Bitcoin has smart contracts-- that is what script is.

This is why lightning can exist.

This is why escrow transactions exists (which weren't just proposed by satoshi, but are used by users!)

This is why multisig exists and is extremely widely used.

Bitcoin script is only less expressive than ethereum in there respect that access to transactions and the blockchain data is limited, that a few opcodes were disabled due to dos attacks and that there is a reasonable bound on execution resources.

The reason you may have an impression otherwise is a direct result of intentional fraud perpetuated by the creators of Ethereum, breathlessly hyping some "World Computer" nonsense early on to sucker people into buying coins from their 72 million coin (17 billion dollars at current prices) pre-mine.  Many of the things they marked (replacement for Facebook!) were obvious nonsense, and much of what wasn't nonsense was already possible in Bitcoin but their hype made it sound like it wasn't.

That said: every time you create a new smart contract what you are actually doing is creating a novel bespoke cryptosystem.  That should be ringing alarm bells for you because almost always when someone-- even an expert-- cooks up a new cryptosystem the result is broken from top to freeking bottom.  Creating secure cryptosystems is among the most challenging domains of engineering.

Ethereum throws up a javascript like interface to enable maximum YOLO by the people least familiar with infrastructure engineering, they don't give a damn about the resource impact and have utterly obliterated the scalability of their system through poor design decisions (as a result the minimum hardware to keep up with Ethereum while it's doing *fewer* transactions than bitcoin, is literally orders of magnitude more-- and as a result  most businesses blindly trust consensys or another third party to give them access to a node).

But ignoring all those constraints doesn't make easier to write _SAFE_ smart contracts: experience has show that over and over again virtually all smart contracts on ethereum are absurdly vulnerable.  A smart contract to enable multisig there (functionality that bitcoin had widely deployed half a decade earlier) written by the authors of one of the most popular ethereum nodes was destroyed by someone simply sending it a command to delete itself-- instantly destroying two hundred and eighty million dollars of other people's coins.

Worse, very few "smart contracts" in ethereum have any reason to exist at all.  The vast majority of them are completely controlled by the decisions of a key holder (or sometimes a multisig of key holders).  The only purpose those smart contracts exists is decentralization theatre-- where people engage in something which is an unambiguous violation of securities law (and usually an outright fraud too) but then pretend it's okay because they falsely claim it's totally trustless and decentralized. Outside of those the next most common are trivial automated ponzi schemes and the like.

On the rare event where people want to actually do something interesting and worthwhile that doesn't just reduce to hiding a trusted third party the astronomical resource costs of doing in inside the EVM directly make it infeasible-- even in an exploration beta-test sense-- and instead they need to convince the operators of ethereum to hardfork the network to embed their critical inner-loop functionality in ethereum as a "precompiled contract".

Of course, Bitcoin can also be extended with new logic and much more simply and compatibility because it doesn't need to be hardforked:  OP_CSV, CLTV, P2SH, and Taproot are all examples of this.  (in fact, Bitcoin could provide an entirely new virtual machine in a softfork).

The issue isn't environment specific either.   It turns out that creating a centralized service is a LOT easier than creating a decentralized autonomous one, and while there is an easy way to monetize a centralized service a truly decentralized autonomous service is almost impossible to monitize-- so it's difficult to justify paying for all that extra effort. ... this makes the actual demand for real smart contracts fairly low which is why you haven't seen more done there.

I'd love to see an interesting neutral database (e.g. not created by some breathless eth pumper) that attempts to catalogue actually useful and interesting ethereum smart contracts to the limited extent that they exist.  Some of them are likely possible in Bitcoin currently, others would be possible with the addition of an opcode here or there.   A number of years ago I assigned someone working for me at blockstream to conduct such a study-- hoping to mine it for useful operations, and they mostly came up empty. I'm fairly sure that this wouldn't be the same today.

One of the things bitcoin developers have struggled with when it comes to adding opcodes is that while there is a multitude of interesting things that could be added, it is exceptionally difficult to justify sticking something in the consensus rules under a conjectural "maybe this will be useful".  There is a *lot* of functionality there which is essentially never used already. But this creates a bit of a chicken and egg situation because there probably is functionality that could be easily added, which people would use if it existed, but people don't develop the uses because it isn't there already.

So that's why you see that taproot creates a massive efficiency and privacy improvement for various multisig schemes and for some things like lightning-- which already have widespread use but it doesn't do much for other kinds of usage: it just isn't clear what that other kind of usage would need but it's clear what would benefit existing and related uses.

Another factor is that when something is sufficiently developed, you call it what it is, not the underlying technology.  People call lightning, lightning, they don't call it smart contracts just like someone calls a chess engine a chess engine (or its name like, stockfish) rather than "artificial intelligence".  The generic names are reserved for vaporware and stuff that doesn't really work but you hope it will someday.

Yep.


But there is a useful thing you can do-- have a diverse network connection.


One great option is to use the blockstream satellite feed: it's available most of the world and has no ongoing cost.

Another useful thing you can do is run tor and connect to peers over hidden services, functionally it's like having a second network connection riding over the first. At least any bitcoin-specific tampering with your network connection wouldn't work.


Aside, -- I wouldn't exactly call any of the mesh things I've seen *secure*-- generally they hardly work even when there is no attacker!

SPV clients don't verify transactions-- they can't because they don't have access to scriptpubkeys.   This means that I wouldn't expect SPV clients to already contain the relevant code.



Yucky for the spec to be described in terms of those flags which are presumably not adequately documented.

But the behaviour they signify has to be handled correctly to use generic Bitcoin addresses to process messages.

The strategy there should be to operate with a dummy, and the spec should be describing it that way.


That sounds like just falling into the same trap of only supporting an absurdly narrow subset of keys users use which then stands in the way of new use cases.  I think that's just a total waste of time, and actually harmful for the industry.

For example, there have been users that refused to change to multisig-- when they could have otherwise used it,  because they couldn't signmessage with it and they'd adopted some workflow that required them to signmessage with their addresses.  The old signmessage format has turned out to be a boat anchor that has actually slow the adoption of new techniques and better security in Bitcoin.  In hindsight, I think we made a mistake in ever implementing it in the first place.

There is certainly a place in the world for message signing systems that are simpler and less -- well-- weird than Bitcoin script but for those you should use something like PGP or signify.

And I don't intend to defend the BIP322 specifics -- only the general motivation of using script so that you can sign with arbitrary addresses.

It's not done that way because the authors wanted to use some bitcoin core internals, it's that way because its intended to be a generic mechanism that works for _every_ address, unconditionally, even ones that aren't widely in use right now-- and can be easily extended as bitcoin's consensus rules are. The easiest way to do that is to use a bunch of bitcoin internals, but it sounds like it's currently resulting in an unclear spec. -- apparently unclear enough that it didn't make its motivation and justifications clear enough.

Inherently though, anything generic is going to be more work to support for something that doesn't actually support verifying bitcoin signatures.  There really isn't any way around that-- but fortunately no one is required to implement it!

I think you're mistaken.

If you want something that signs messages in general use GPG.  It would be an extremely bad practice to come up with some novel cryptosystem just to sign messages when established audited and mature alternatives exists.

Bitcoin uses a novel cryptosystem for signing transactions called Bitcoin Script which allows all sorts of complex constraints on the signatures.  It's why with Bitcoin you can do multisig-- but for GPG and whatnot, you can't really (technically it could be done, but would need complex MPC crypto which no one implements).

Sometimes you want to sign messages with bitcoin addresses, e.g. to have the operator of an address attest to something.

If you're going to do that and support all addresses, then you need to use Bitcoin script to do it. In doing so, you pick up some of the structure that goes around script-- some of which may not be as useful outside of the blockchain.

So I don't think anyone particularly wants to use the bitcoin core code base-- but rather they want a signmessage that works for all Bitcoin addresses.

I'm not sure, but I could speculate:

Because that's how signing works in Bitcoin so it should make it simpler for existing code. Also signatures generally must commit to their public keys or weird vulnerabilities crop up where you think you're signing with one key, but you're really signing for a related key.

I think your post supports my position.

A change in the P2P protocol would require or at least enable a behaviour change by a remote peer. Only one of these PRs do that. (Ideally they'd enable new functionality, though not always)

Almost all those commits in the recent change you listed are implementation optimizations, local behaviour changes, or refactorings and don't change the P2P protocol-- many don't change the externally visible behaviour at all.

I would generally characterize more recent activity as being extremely biased towards making changes that appear have generally no effect on behaviour  (if not absolutely no effect), which allows people to feel more confident that they don't break anything and makes the changes simpler because they don't require rewriting any unrelated tests.  This isn't to say that I don't think the changes are good, I think almost all of them are, but I would also say that only a couple of them accomplish anything a user might care about.


So there is only one thing that I would consider an actual change to the P2P protocol, and it's the realization of a protocol written in 2017.

In the context of this thread-- the question was observing stale blocks.  The idea of adding a P2P message to allow relaying their headers has been suggested many times probably going back to 2012. It came up more often post 2017 or so when it became clear that block relay improvements were making it extremely hard to observe stale blocks.  It would require a new P2P announcement since the existing headers message is a statement that you have the block-in-question available for getdata.

But no one is working on that. Now, if it had happened and been in your list I would have described it as an unimportant feature that wouldn't improve life for end users (though it would significantly improve developers ability to gauge the health of the network)-- given that and as you sample there are have been few recent changes that change the protocol, I really don't expect it to happen soon unless something changes.

Things aren't completely stagnant, e.g.

I've seen some activity towards revising ADDR messages. The current addr message are incompatible with v3 TOR hidden services, which have existed since 2017 and have much better properties. If this work is not completed and deployed within a year hidden services will stop working for Bitcoin users. Given the normal release and deployment timelines as well as the fact that the revised version is not merged or apparently merge-ready, I think it is now extremely likely that onion-peer support will be disrupted for users, in practice. Work on this began two years ago but didn't make progress for a long time.

There has also been some activity towards wtxid based transaction relay and the related erlay change.  There was some noise again on p2p encryption but it seems to not be particularly active.

But these changes are all moving extremely slowly, to the point where-- personally-- I forget everything about them between updates to them and don't find it interesting to contribute to them. Especially as I've found the testing framework makes it extremely tedious to work on any P2P behaviour change, because behaviour changes tend to break a wide assortment of unrelated tests, that people are slow to review or comment on them, and that their patches are continually broken by changes which are fast moving because they don't actually change behaviour.

Given that there isn't (yet) a fire behind p2p protocol updates required to keep onion peers working. I don't think it's unfair to characterize things as stagnant from the perspective of the p2p protocol itself and I really can't see purely instrumentation changes like stale-header-broadcast happening any time soon. (And I wouldn't recommend it: I'd recommend efforts be focused on addrv2 and other user-impacting changes like taproot!)

It would be more accurate to say: These addresses don't use mixed case, enabling MUCH faster and more accurate transcription via writing or speaking and support 256-bit payloads which are important for providing adequate security especially when addresses are created with input from multiple parties, both at the expense of being longer.

BC1 addresses actually spend slightly fewer bits on error detection (30 instead of 32), but the error detection is designed to be much more effective for common errors (which corrupt only a few characters).

Perhaps go ask your altcoin questions in an appropriate place, and if that altcoin doesn't have a community that can answer questions perhaps thats a sign that you shouldn't run it.  It's not a sign that you should pretend that the extremely outdated altcoin software is extremely outdated bitcoin software in order to vampire questions off the bitcoin community.

Not possible-- of course it's always possible for people to talk in private but things have to be made public to have an effect.

I don't think it's good but I don't think it's particularly bad either.  There are a lot of improvements that would be useful, but at the same time Bitcoin works okay without them, and it's better things not be done than done poorly or thoughtlessly.

That is certainly my impression.

problem with franky1 isn't that he posts his stupidity once, but he flooded the thread out with his endless multiposted stupidity, constantly bringing the discussion back to his deranged theory. I have him on ignore, and only look at his posts if other people have started responding to them.

We've already had something which is almost that happened. Craig submitted to the court a huge list of early blocks that he claimed he "satoshi" mined,  it got made public, and wham 145 signatures calling Craig a fraud.

Wright just claimed he was hacked and the keys were stolen -- never mind that the coins those keys controlled have never been moved.  Of course his followers believed it, BSV price didn't even go down. Shit, even the fucking media repeated the lame excuses as if they were credible!

So I think we know exactly what would happen in your hypothetical, and it wouldn't put a stop to wright.  The media has already shown with wright that they're happen to ignore extremely strong cryptographic evidence (e.g. wrights earlier forgeries or these recent signatures)-- and Joe Sixpack is going to go along with whatever the media is selling.  And that is good enough for wright to continue his con in perpetuity.

The problem with Franky1's fan fiction isn't what he thinks Wright wants-- that may actually be what Wright wants, or at least what Wright is selling as his plan to some of his sucker-victims. There has been no evidence that Kleiman wants that too, but lets go ahead and pretend he does.  The problem is more fundamental and based on Satoshi's lack of applicable intellectual property rights:  Satoshi doesn't have and couldn't have any relevant rights to important Bitcoin "IP"-- e.g. after Satoshi published bitcoin without applying for patents, he perpetually lost any ability to do so because Bitcoin itself became prior art--, so a conman can't gain such rights by successfully pretending to be Satoshi.

That would be like me trying to claim that I own your home because I'm really Elvis. ... Even if I successfully impersonated elvis and tricked all the courts, I still couldn't get ownership of your home that way because the actual Elvis has no right to your home.  Franky1's theory is predicated on a misunderstanding of patents.

If Wright wants to patent troll, he'd falsely claim that Bitcoin recently incorporated something that he patented prior to Bitcoin's use, avoiding the problem of Bitcoin's publication itself constituting prior art-- but for that, there is no benefit to claiming to be Satoshi.  Wright's ability to make baseless patent claims isn't amplified by his Satoshi act, in fact it's hurt by them because his constant dishonest antics will make it hard for him to get taken seriously and has a established a track record as an unrepentant liar.

That said, even though it would be misguided and pointless "pretend to be satoshi to gain patent right over Bitcoin" could still be his plan. He's had plenty of other really dumb plans and his target audience might well even believe it, after all they're stupid enough to believe that Wright is Satoshi (and even franky1 isn't falling for that).  If so, that's good news for all of us since his incompetency ultimately limits the amount of harm he can cause.  If he tried to bring lawsuits claiming patent rights based on his claim of being Satoshi, they'd get easily dismissed.


As usual, franky1 is gaslighting.  He's referring to this.

Basically, Blockstream open sourced any patents it had or would later obtain.  This helped make sure that blockstream's efforts couldn't later be abused to harm or disrupt the bitcoin ecosystem (e.g. if the company failed and its rights were acquired by some dirtbag). The DPL is one of the components of that, and wasn't created by blockstream-- contrary to Franky1's claims, which is presumably why he wouldn't explain when you asked.  There wasn't really potential for that to begin with, but better to be sure.

The situation is distinct from the original invention of Bitcoin itself because Satoshi published it without patenting it, for the first year there would have been a legitimate concern that Satoshi could have turned around and patented it, that the implied patent license created by the MIT license wouldn't be great enough, and so it wouldn't have been unreasonable for the community to ask for an explicit open patent license. But no one cared at the time and after a year the window for Satoshi applying for a patent closed, mooting the issue.

Right.  I don't know a way to use the endomorphism to get a speedup over a single compact interval-- and I somewhat doubt that it's possible.  If it were, then I think in the application of endomorphism to the multiexp it would be possible to recursively apply the endomorphism to decompose to smaller and smaller scalars, but it isn't.

The speedup over the set of three intervals is still potentially interesting:  e.g. imagine you have an elgammal encryption where the decryption leaves with with a point you need to take the discrete log. And you can arrange that the DL is in some small enough range that this isn't unrealistic, and could potentially support the sparse ranges.

This shows up in things like electronic voting or in confidential transactions. (In CT I avoided the need to solve a DL in the receiver by sneaking an encryption of it into a sidechannel in the range proofs).... or just for DL challenge bragging rights.

*All* SSL is extremely weak, on the borderline of snake oil.

Anyone who can MITM a HTTP request coming from almost any public CA to the target domain in question can obtain a valid certificate.  The only thing SSL provides meaningful protection against is MITM who are near the end user (e.g. their ISP or open hotspot, etc).

I haven't looked into detail of the above report, but generally you need to be careful with these auditing tools, because they often ding fairly harmless settings differences which are necessary for compatibility with older browsers and which don't make a practical difference for security. Sometimes following them too aggressively can actually lower the security in practice by forcing some users off HTTPS.

Given the generally low security of HTTPS, stuff like 4096 bit RSA vs 2048 bit is mostly security theatre.  Sure, why not, google doesn't ding sites as much anymore for having a slower connection due to HTTPS.  ... but it's not something that is worth basically any attention.

Man, I love these messages from Franky1 now. Chalk full of easily disproved lies.
Nope. Gavin received it tacked onto the end of the last email Satoshi sent him. Here is a picture.


Bitcoin development wasn't originally on github, Satoshi never participated there-- but you can happily see me participating before then e.g. on bitcointalk,  the mailing lists, or IRC. ... Mike Hearn didn't first show up on the Bitcoin github until June 2012.

That isn't technically true-- though you couldn't be blamed for not knowing it. After Bitcoin started using github Satoshi sent patches to other people that weren't submitted under his name.  For example, the transaction signature caching in Bitcoin was one of these email patches.


If you want to call Gavin a liar, by all means.  It's not a violation of the laws of physics for you to say something I agree with.

But you're not arguing with me here, you're arguing with gavin.


MIT license is a software license not a patent license (except to the extent a limited implied license may exist).  You used the term "IP" vaguely, which could mean patents, copyright, or trademark  (or a few other things in backwards freedom hating jurisdictions).  Satoshi wouldn't be able to create trouble for Bitcoin from a copyright perspective because of the MIT license. He wouldn't be able to create trouble from a patent perspective because of Bitcoin itself being prior art. And he wouldn't be able to create trouble from a trademark perspective due to abandonment (among other issues).  So wright, by pretending to be satoshi, would be in no better a position even if his con was successful (it wouldn't be).

Blockstream's patent licensing is like free software licensing, except for patents. Unlike Satoshi, blockstream worked on new things that could potentially have created licensing problems if they weren't freely licensed.

Wright hasn't contributed anything new to Bitcoin, so there isn't any risk for his contributions to be patented.

And if he did create something new and patented it and alleged Bitcoin used that thing, his claim would no in way be improved by claiming to be Satoshi.

Franky, why can't you just admit you were mistaken on something?  It's not a crime, it's not even embarrassing.   What is embarrassing is you arguing yourself into a loop arguing about a subject you're generally ignorant about with people who have real professional experience in it.