I don't know if I'd go quite as far as trust, but you make a fair point.

We (the bitcoin devs) asked Gavin a number of questions in the immediate aftermath of his endorsement of Wright.

Gavin went unresponsive when we asked for details about when he started communicating with Wright.  So good luck finding out anything there.

He said in media interviews that he was absolutely convinced before ever seeing any proof.

Certainly, in none of Wright's communication that I've ever seen has he sounded at all like Satoshi for any span of more than a few words-- maybe a sentence at most... except where he was just quoting Satoshi.

And yet, as we are today Gavin has still never fully retracted his endorsement. He left it at an 'I'm not sure what happened, maybe I was fooled. It doesn't matter anyways'-- something which wright's promoters continues to use to promote wright's legitimacy.

Probably the most significant thing I can say on this subject is that *none* of the core-devs upon hearing Gavin endorsed the guy thought this was at all evidence of the claims-- even before seeing the publication of the obviously faked signature.  The idea that Gavin was hacked, was being coerced, was being paid off, was a scammed idiot, or was attempting a desperate attempt at taking over Bitcoin after he was unable to convince people through the merit of his arguments were all considered serious possibilities. We discussed the possibility that wright got his hands on of an early block private key that was mined by someone other than satoshi, and was planning on exploiting the ambiguity about who mined what-- and that Gavin fell for that because of one of the might have fallen for it due to the aforementioned reasons. The only people that thought his endorsement was persuasive were people that hadn't worked with him on technical matters. The people who would know best how to weigh the evidence of that endorsement didn't find it remotely persuasive. And in the aftermath, when Wright's public signature turned out to be fake Gavin's response wasn't to adopt complete transparency and help take out and protect the Bitcoin community from the guy that had supposedly conned him. Take that for what you will.

I think in general the pattern we've seen from Wright is that he isn't particularly convincing or persuasive, but rather he exploits the fact that people are usually unprepared to deal with such an audacious liar.  ... the sort of person who will go literally red faced screaming at you that NO, IN FACT THE SKY IS GREEN NOT BLUE THE SKY IS GREEN.  When faced with behaviour like that some people just start wondering if maybe its legit because they'd personally never act that way unless they were telling the truth and were absolutely sure of it.

I've *never* seen wright repeat a true fact about Bitcoin that he couldn't have learned just reading some posts here or the mailing list. Instead, I've seen him repeat many false claims that you can find posted on the internet which anyone involved early in bitcoin would know.

The obvious conclusion is that since he is perpetrating a multi-million dollar fraud and identity theft he spent a little time doing homework, but as his school records show he is utterly terrible at performing any kind of intellectual work at all... and so he didn't do a good job of it.  He produces so much evasion, obfuscation, and outright bluster -- literally screaming FUCK YOU at people who challenge his technobabble, that he manages to fool more than a few people who aren't following closely.

If you want to make guesses as to why he would assume Satoshi wouldn't out him... first, why would he need to assume that?  He could continue to rake in money from victims until that time-- the scam has to end eventually after all, it might as well end that way.  second,  there were a long sequence of false Satoshi claims before him and Satoshi didn't show up to debunk those either so it's a safe bet that wright could get away with it for a long time.

Finally, wright's activities have caused more fixation on satoshi than ever.  It would be bad for everyone for satoshi to show up in light of that.

If you thought wright couldn't top the last dozen absurd lies and idiotic baseless legal threats he's issued... you have a surprise in store for you:

https://web.archive.org/web/20200210203809/https://medium.com/@craig_10243/ccbe22f2637e

He is now claiming his stole identity entitles him to complete ownership of the Bitcoin system.

Craig picked those addresses very likely without knowing of cypherdoc at all-- it was simply one of the higher value addresses on the chain at the time as were the other addresses he picked-- which is how he managed e.g. to pick that mtgox hacker address too.

It might not have occurred to them to do it (until now).  It might be time to start making popcorn.

Want to hear the most amazing thing about those addresses?


This is cypherdoc's (Marc Lowe) addresses.  Cypherdoc is a big promoter of Wright/BSV today.

I guess doc has graduated from getting paid thousands of BTC in kickbacks from promoting scam bitcoin miners to promoting Wright's identity theft scam... since it has become hard to believe he's just a bamboozled victim given that wright was claiming doc's own address!

You'd think that someone who testified in court of being the Lebron James of Bitcoin could find a less humiliating ways to make a quick buck...


This one is Roger Ver's address. Ver was a Wright promoter for years and I tried countless times to get him to clue up and publish a signature refuting wright's claims... he finally did but only after having an unrelated business falling out with wright. Even after the fallout he continued implying wright was or could be Bitcoin's creator for months.


$ ./bitcoin-cli verifymessage 16cou7Ht6WjTzuFyDBnht9hmvXytg6XdVT 'G39S6i4XsfQnixN5ePMjVPboWvGXdnW8xFFAXiwEriZFCclflbD7umP58u3Sl+dvvXC5BxBrRNkTMNf92O1UIXw=' "Address 16cou7Ht6WjTzuFyDBnht9hmvXytg6XdVT does not belong to Satoshi or to Craig Wright.
Craig is a liar and a fraud."
true

If checking yourself, be sure to get the line-break right

Of course they can be compared.  Indeed, aggregating the across the entire block gets more gains, but the majority of the savings are achieved by aggregating within transactions, so the returns are diminishing and aggregating more widely has costs including adding new radically different strong assumptions... particularly so because you can get arbitrarily large aggregation in one transaction by coinjoining interactively.

You misunderstand the material. I've implemented BLS aggregation (see the earliest thread on the subject), so I'm pretty confident that I do understand it.

Ah, no. If that were the case it would be much easier.  The 'division' in this case is just the algebraic notation.  That's like saying that generating a public key is trivial because multiply a 32bit integer is a single cycle instruction and pubkey generation is just multiplication.  In fact pubkey generation is _algebraically_ represented as a multiplication, but the implementation is much more complex and slow than "just multiplication" would imply.

It's not cosmically expensive, but it's a lot more expensive than a hash table lookup.

All hardness assumptions are inherently open problems in cryptography, that's what a hardness assumption is called an assumption.

OMDL is a pretty unassuming elaboration on DL: It says if a challenger give an attacker N random group elements and they're permitted to make N-1 queries to a magic black box that will give the discrete log of an arbitrary point they provide, they cannot use this provide the discrete logs of all N elements (only N-1, at most).  If anything it's more surprising that OMDL is not simply equivalent to DL.

But musig doesn't rely on OMDL: there was an earlier version of the paper that proved a two round version under OMDL but the proof was flawed. The current version of the paper only has the three round version which has a security proof that uses a plain DL hardness assumption. (The 'rounds' only come into play when you're aggregating with third parties.)

Cheers,

The doubling down is polarizing.  If you thought wright wasn't satoshi it makes you more sure of it, if you thought he was it also makes you more sure of it.

For a scammer this is a great move:  The people who are eligible victims become more vulnerable from their increased belief and the non-victims get further away and less likely to disrupt the scam.


He's made enough false claims of patent infringement, copyright infringement, etc.  (not to mention general defamation like claiming specific people fund terrorism or support child porn) that he's really set himself up to be targeted with a lawsuit seeking a declaratory judgement against his random legal threats... only missing component is that the few people with the time and money to bother consider him much of a real threat-- or even a real irritation.  But it'll could take take one more case of him harassing or threatening the wrong party before attitudes on that change.

God knows when justice will come for this fraudster but if/when it does I expect it'll ramp up quickly-- he's basically built his entire life in a fleet of oily-rag filled dumpsters.  I'll only take one match.

The computation w/ BLS aggregation isn't proportional to the size. It's proportional to the number of signed message and number of pubkeys.

You've got that totally backwards. Schnorr aggregation is not slower than non-aggregated validation and has absolutely zero negative effect on caching. Validation aching simply continues to work without any modification because the unit of aggregation is also the same as the unit of inclusion/non-inclusion: a whole transaction.


You misunderstand the text, it saying that it doesn't destroy caching completely.

In Bitcoin today and with schnorr aggregation script validation consists a single hash table lookup for each transaction in the block.  "Is this transaction in my already validated cache? Yes? Good. Its scripts are valid. Done."

This requires an cryptographic operation per already included signature, the cost of that is more similar to a schnorr verification than it is to a hash table lookup, sadly. Keeping the data around to be divided out is also an additional overhead. This is why I said earlier that ' also has complications with validation caching' and that the caching interaction has its own tradeoffs, particularly around worst-case performance. As I said, non-insurmountable but just another way that it isn't a totally free lunch.

It has been, it's the subject of the musig paper (which is cited by the one you linked...).


As mentioned you are simply incorrect there. I can't fathom how you ended up incorrect. Can you help me understand how you came to believe there was any negative caching interaction with cross input aggregation at all?

I heard Wright replied he complying with the latest requests from the court because aliens impregnated him with his <s>courtier's</s>courier's goat-baby.  ... or something like that?

Anyone have any details?

Seems unlikely, ECDSA is effectively not supported by specialized circuits today (okay, on RF powered smart cards or whatever it is, but not by anything useful for or use in Bitcoin)... and the parameter selection for pairing keeps changing because of improving attacks.

That sounds like a meaningless handwave to me.


The best way to make CPU the bottleneck would be to introduce operations which are 40x as expensive per byte... which BLS does.  For almost all hardware sold as a full node in use in the developed world their sync speed is already CPU bottlenecked. For faster hardware or nodes outside of the places with fast bandwidth that isn't the case.

You also run into problems with sticking slow operations in the block propagation critical path as you cannot _completely_ cache the validation, as is done today.

Most of the savings already result from schnorr aggregation. So the marginal increase isn't that tremendous compared to the performance.

There are other cool advantages, but they seem difficult to weigh against the weaker security and considerable CPU time increase.

You might want to call your effort something else, there is a sketchy altcoin called nano which also promotes its low resource costs (IIRC because it just doesn't validate chain history...), so it might be easily confused.

Unfortunately, advances in technology for consumer devices are mostly pouring into reducing power usage and size and improving portability... and to the extent there is surplus, it is in competition for other uses in bitcoin like increased privacy or increased transaction capacity.

The gini coefficient of computing performance is increasing.

Not to say that I think it's a non-starter, but it's not so obviously a huge win, particularly when due to decenteralization we shouldn't care about the fastest computers but about the speed of the most widely deployed or inexpensive ones.

Maybe instead just go look at the prior threads on the subject?

You could at least pretend to have read the links already in this thread. The first five paragraphs of my above link from 2016 are about BLS signatures and their limitations. The whole point of the post was "we knew we could do this with BLS but the tradeoffs made it less exciting, but it turns out we can also do it with schnorr signatures."

They allow a non-interactive aggregation which is really cool, but interactive aggregation can already give most of the benefit. Their cost is new strong security assumptions (in fact, had they been deployed back in 2016 they'd have to be deprecated now because new attacks lowered the security of the groups that would have been used, and now most things doing pairing are using a 384 bit group as a result, and there are arguments for 460+ bit), and that they are quite slow... even worse than that 2016 thread suggests because of the necessity of increasing the size to keep ~128 bit security (At practical sizes for cryptography, ECC computation time is roughly cubic or worse in the size of the group). Cross transaction aggregation also has complications with validation caching and relay that are probably surmountable but present their own trade-offs.

You mean "massively worse":  IRC was a single system that you had to stay connected to when you were online to get returned by it. If it filtered the view you got, then that's the view you got.

The dnseeds don't require any connectivity to it, and there are a bunch, so any one can't rig your view of the network.  Your ISP's recursive resolver hides your IP from the DNSseeds and can cache requests so the seeds may not see your request at all. Plus, now adays, it only uses them if it doesn't have its own info and/or is failing to get connected.

The IRC server started tampering with the results too-- they had some weird justification for it, but that was a major factor in moving to the dnsseeds.

The main problem for cross input aggregation is that normally you can just soft-fork in new signature types (e.g. including new sighash types) just by creating a new checksig operator (or having a pubkey of a different length).

But a new signature type added in a backwards compatible softfork couldn't be aggregated with other signatures even if the underlying crypto is the same.  This is especially relevant because there is a current interest in adding some new sighash types, also graftroot which is also effectively a new sighash type.

Aggregation could have been done for basic taproot alone, and then any new types would have to be separately aggregated... but probably along the way we'd come up with different optimizations in how aggregation works, and then the consensus rules would have two implementations of aggregation. Worse, if taproot originally has aggregation people will probably upgrade slowly to a later tapgraftroot since mixed transactions would have higher overhead from the inability to aggregate them both, and fungibility would be hurt by the slow upgrade.

There are also some ideas that could allow for better backwards compatibility.  In particular,  if a new witness-like p2p extension were made that allowed transmitting the concrete sighash values as witness data to old nodes that don't know how to generate those sighashes (but otherwise not keep them in blocks),  then aggregation could be preserved even with future softforked in sig hashes.   But witness-like p2p extensions are a real pain to design and deploy, and no one seemed particularly eager to do that work right now. If one is done it should probably pick up some other improvements other than just backwards compatible aggregation.

So essentially, aggregation is conceptually ready but there are very strong incentives to deploy it in combination with other features which are not currently ready.  Trying to do everything at once is just too big an engineering project to pull off safely, and we're likely to learn a lot from actual usage of taproot which would help improve the design of other features (particularly of graftroot/g'root).

Right now I don't think the current amount of engineering interest in Bitcoin is particularly healthy.  Many long time contributors, including myself, have essentially stopped contributing for a variety of reasons (including uncertainty around political disruption of deploying even fairly boring new consensus changes, concern that too much bitcoin hashpower is controlled by bitcoin adversarial parties who would attempt to block protocol improvements, etc. on top of more generic factors).  Lightning is also easier, faster, and often more interesting to work on and so it has diverted a lot of new blood.

Consensus rules set how things are hashed not how they're communicated.

If you wanted to store or communicate (to compatible software) headers using a compact int you're free to do so... but it would be a mostly pointless savings (two byte? meh. and even then only if you weren't representing current common numbers which have higher bits set, or using an alternative compact int format).

The size of them going into a hash is pretty irrelevant, because unless you reduce the compression function run count the hash takes essentially the same time.

The bytes of prev which are forced to be zero because of this block's difficulty are a much more sensible thing to save, particularly because as difficultly increases the amount of nonce you need increases proportionally... so it would have been logical to use the zeros for additional nonce and to have made the separate nonce field just 8-bits. With that and updating time to be current no one would need extranonce.

The fact that witnesses are push only makes the witnesses for many common scripts non-malleable, but you're correct for other scripts.

One of the motivations for annex in taproot is being able to later add a field that sets the weight of a transaction (which must be greater than or equal to the actual weight) which gets covered by a signature to address the point you were thinking of, among other reasons.

The Bitcoin protocol shouldn't be specified by invitation private meetings.

Typical consensus rule changes usually take a couple years to mature.  By trying to fast track things you are doing exactly what hearn did with bloom filters.  I hope Bitcoin has matured to the point that when someone overloads proposal bandwidth the response is just "no" rather than letting it happen.

Bitcoin development right now barely has the bandwidth to be even minimally responsive to basic bread and butter stuff.

There is a *single* proposal.  It has three parts, for engineering/review reasons.  You can't separately implement the different parts and you wouldn't want to if you could.  By themselves each of the parts is not very useful, its their combination that makes them very useful. Sort of like how a car has many parts which can be separately engineered and analyized, but the drive shaft in isolation isn't useful.

Segwit was split across 4 BIPs (5 if you count the later bc1 address stuff).