Terminology danger!

Signature aggregation refers to the case where the verifier (the blockchain) knows a bunch of different pubkeys and you prove that they all approved a transaction using a single aggregated signature.  This is the often talked about thing that taproot doesn't include that would help make multi-input transactions much smaller.

Threshold signatures and _key_ aggregation are where some participants cooperate to produce a single key which some threshold of them can sign for, but which to the network just looks like a single party signing.  Taproot allows this, and it's what allows you to make multisig like usage which is indistinguishable from single key.

So taproot removes the distinction between single party spends and multisig too (which can include lightning input spends which don't actually use CSV/CLTV, even if they have it available).  Indistinguishable threshold signatures may not, however, be usable for all multisig usage because the threshold signature requires a little more interaction between signers and because in some cases you really want the public record to reflect which participants out of the threshold actually participated.


Yes, but almost always you can restructure a script as "[All the parties agree]  OR [Complicated script thing]". If you can do this, you can put an N of N pubkey at the top, and if the parties cooperate, the parties can cooperate and just sign and and the fact that "complicated script thing" exists at all will not be exposed.

The only time the existence of a complicated script would be exposed is if some parties don't cooperate (E.g. because they're offline).
 

I think that's not quite the case:  There is a privacy benefit in that single key, multisig, and channels will be less distinguishable, eventually improving the anonymity set for all transactions.  Specifically for coinjoins it means that you could have a single key and a multisig using party coinjoining and you couldn't distinguish them.

Though this is more of a long term benefit once the new style is the most common, initially privacy will be reduced somewhat through the proliferation of more address types.

You're absolutely right though that some people are confusing the aggregation benefits discussed previously with something taproot provides.

AFAIK the primary difference is that when Wright acted against Adam, Adam didn't make it public and give wright free publicity (I'm not faulting McCormack here-- he needed public support), and Adam appeared to be in a position to outspend Wright.  It's also the case that what Adam said made for a simpler and easily defended case, e.g. more squarely centred on the unambiguous fact that all of wright's "evidence" was fraudulent.  Otherwise, I think it was just a question of having multiple ongoing cases being an extremely poor legal strategy.  It may also be that wright realized that having to provide discovery to adam might end up exposing other actions by wright that he didn't want exposed.

Don't be so sure, a significant fraction of "nodes" are just lame sybils listening to other people's traffic in order to monitor users.  It seems that usually when someone makes one of these things that just have it emulate the nodes at the time and they seldom update them.

You likely need to be in a jurisdiction with terrible laws like the UK where it's even slightly possible that he could win through by assembling a critical mass of fraud. You probably also have to be a high enough profile person so that he can spin the prolonged lawsuit against you as some kind of proof that he's not the scammer he so obviously appears to be.

His UK attorneys appear to be total morons.

They eventually sent me some threatening note about my failure to respond to their demand to identify where I got some link ... to craig wright's public blog.  Two seconds googling showed that it was posted a day prior on reddit.  ... and this demand I supposedly failed to respond to?  They claimed to send it to a public mailing list, which I haven't been on for years ... and who's public list and moderation archives seems to show that the message was never received there.

They subsequently send some long list of demands that I admit to being various people (whom I am not), too funny. (And no, if you didn't get a message about me about it, you weren't one of them: Try harder. )

As far as I can tell they're either drooling idiots of the highest degree or they are knowingly and willfully complicit in the Wright/Ayre criminal enterprise.

Don't be so sure here, given how extremely awful UK libel law is, it is completely plausible that wright could win.  His lawsuits against other people were either tossed for jurisdiction issues or dropped because he was going to focus on McCormack. ... I'm guessing he chose to focus on McCormack because he gauged him to be the most financially vulnerable target.  My understanding is that UK will put the burden of the case substantially on McCormack, then wright will probably saturate him with endless thickets of forgeries, making the defence extremely expensive.

Plus, by failing to pay his court ordered judgement in other cases Wright is demonstrating that the endlessless attorneys fees he's racking up for the defence may still be unrecoverable even if wright loses and the other side is awarded fees.

I'd recommend if anyone did want to protect the public by calling out Wright's fraud more at the risk of a lawsuit, they should make sure they're in a pretty good jurisdiction for it.  California doesn't look bad-- residents in California are protected by state and federal law against UK libel suits specifically, and the criteria for libel under California case law (and the over-poweredness of anti-slapp) are pretty lax on the accused.

If you are in a place where he'll actually sue (like the UK) you're probably signing up for hundreds of thousands of dollars in expense.  There are probably much better ways to spend $100k to take out this conman.  For example,  hiring a lobby firm to put pressure on prosecutors (and the ATO) to take action against him might be an option.

Likely because those conversations didn't exist at all or at least not like described.  There is no particular reason to believe Cryddit was telling the truth, especially because a simple glance at the original release demonstrates that he was wrong about a lot.

See:
https://www.reddit.com/r/Bitcoin/comments/e9v48b/how_can_sirius_claim_to_be_bitcoins_2nd_developer/falysvv/

and later down the thread:
https://www.reddit.com/r/Bitcoin/comments/e9v48b/how_can_sirius_claim_to_be_bitcoins_2nd_developer/fam2aut/

I believe you will only be able to distinguish the lightning transactions if they are non-cooperative.  Openings and cooperative closures should be indistinguishable from ordinary single key payments.

[I say I believe because I'm not super well versed in lightning details, but this is indeed the idea.]

That would be really cool, but I dunno that it's almost certain.  One thing you can be certain of is that they'll be ready when they're released.

I said "no" but it's also not clear to me what the question means.

Last time I used USD to buy coffee instead of a card was probably over twenty years ago-- okay maybe I used some pocket change a couple times in between--  is USD a failure because of that?

USD is a worse money than Bitcoin from several different perspectives, so in general I try to get rid of it ASAP-- and that means spending it preferentially and preferring to be net short it (e.g. by having a zero interest rate credit card balance for a month). By comparison, Bitcoin is better so I prefer to spend it last unless its uniquely good properties are called on.

These days Bitcoin isn't a great match for spending a couple bucks on coffee-- and no I don't mean transaction fees (since obviously lightning is a good fit for that usage)-- but because it has disadvantageous tax treatment: spending time to account for and report cap gains for a $1 cup of coffee would be absurd.  But so what?


I think it's even simpler than DooMAD's answer:  For the most part they don't run nodes themselves (otherwise ... they probably wouldn't be big blockers!) and admitting that the absurd resource costs even at current load levels is a factor would crush their arguments, yet they're already suicide-pact committed to blocksize-go-up and so to resolve the dissonance they take the position that it doesn't matter how resource intensive it is because people shouldn't be running them.

I wonder if these companies are considering that this move may make them attractive targets for asset stripping in the future?

Bitcoin price goes up 20x... now most of the companies value is the bitcoin but their profits haven't increased...  take over the company just to strip it of the bitcoin.

Reducing the incentive to asset strip is one of the reasons public companies often prefer to return funds to investors ASAP and finance operations via debt.

This is how you advertise yourself. When you send the addr message to your peer it will (sometimes) pass it on to other hosts so that they learn about you.

Yes, they might know about it (or they might have just had it manually configured w/ an addnode), but even if they do their knoweldge doesn't serve the purpose of causing your address to get advertised to the network. For that to happen, you have to advertise it.

Worse, it's like putting dollars in shady sal's back alley bank and getting credited SalDollars in return, which can at most be redeemed 1:1 for real dollars, -- if you can track down Sal and convince him to do the redemption.

Foreign exchange could make you money or at least hedge a liability...  tokenized USD?  That's just fiat with extra risks. To the extent that there is any use for it at all, if you had a use you'd know it and wouldn't be asking about it here.

If you want to own Bitcoin (for its multitude of benefits) but are worried about taking on extreme losses,  you can buy put options to insure your bitcoin.

So for example:

Right now you can buy 1 BTC for $10708 and stash it safely in a secure wallet.  You could also buy 1 BTC worth of 12/18/2020 (roughly 3 months out) $7500 strike BTC puts for $278 on LedgerX.

If three months from now the BTC price holds steady or goes up, then your puts will expire worthless-- like when you pay for insurance on your house and it doesn't burn down. Then you buy new puts, dated 3 months out.  So you'd end up paying around thousand bucks a year or whatever for that level of crash protection.

If the BTC price crashes to $7500 or below then on the expiration date, you execute the put and get $7500 for your *whatever the current price is*.  So if the price drops to $5000.  You execute, you get $7500. If you wanted you could buy back the bitcoin and get 1.5 BTC.

If you get tired of holding the insurance -- perhaps you sell your bitcoin or feel less concerned,  you can sell your put contract for whatever its worth at the time.  (potentially more than you paid for it if BTC went down enough-- less if it went up or stayed stable).

You can pick the strikes and dates you want to adjust your risk tolerance vs what you're willing to pay for insurance.

Right now, 12/18/2020 puts at $5k are available at $148/btc,  7.5k at $278/btc, and 10k at $1200/btc on LedgerX.  Perhaps they'd trade at better prices if you left a standing ask.   LedgerX contracts trade in 1/100th of a Bitcoin increment.   If in the future bitcoin is less volatile it'll cost less to protect your position this way,  if it becomes more volatile it'll cost more.

If this makes sense for you depends on your particular finances and risk tolerance.  If you're assuming Bitcoin is going to go way up then you could imagine buying this protection is just throwing money away-- but if the fear of losing money is keeping you from owning Bitcoin at all, then the cost of hedging it may itself be a very good decision even if the prices do go up a lot.

Of course, doing this exposes you to some risk in using a centralized platform e.g. they could get goxed... but w/ this strategy you only have the put you bought there-- your Bitcoin can be safely stored privately, in your own possession, offline.

Personally, I'd take the other side of these sorts of trades because I'm not worried about Bitcoin volatility. But everyone's situation is different and I think it's completely reasonable for people to buy low-strike puts for hedging purposes.  Shuffling around risk to parties that are more tolerant is a natural economic win/win.

Maybe this is the start of what it's going to take for there there to be arrests over some of the more extremely scammy shitcoins.

Authorities will look the other way when it's all niche idiots ripping off other niche idiots.  Start defraud retail investors and eventually they'll hit someone with political clout and a taste for vengeance.

Depends on the part, the ASN1 parser stuff is and was extremely difficult to review. The basic cryptographic code OTOH is mostly fine, readability wise-- though there are a lot of different platform specific optimizations and different cryptosystems in there, so a lot of work to review.

A lot of the "readability" fixes that they did do were just running the entirely codebase through an autoformatter. I think this was a complete and utter disaster for reviewability-- it caused them to issue a 400k line diff (which they also mixed in with security changes).  Presumably they were also hiding undisclosed fixes in that massive change, but-- perhaps they also hid new vulnerabilities.  It's completely impractical to review that, so only history will tell.

If your "readability" problem was one that could be solved by mechanically adjusting formatting, you could have done that locally without any fear that something naughty was slipped in.


Libsecp256k1 should be roughly equally portable (in fact, in some respects it is more portable just because it's smaller and does less-- so any adjustments needed for a weird platform would be smaller).  I test libsecp256k1 back to GCC 2.95 (from 2001, which is extremely old by modern standards-- though OpenSSL originally worked with older toolchains I have no idea if they continue to test with anything that old).  Libsecp256k1's tests also pass when compiled to a 16-bit DOS executable (though a couple of changes are needed to the tests to keep them from exhausting the stacks).

Well there are orders of magnitude, even the worst parts of the OpenSSL code are much more reviewable than a binary.


It's always good to be a bit wary when someone is pitching that their reimplementation solves all the problems unsolved by the Standard Solution-- often it means that the reimplementation didn't understand the entire problem domain (or they did and are intentionally ignoring a big chunk).

Some of OpenSSL's awfulness is self-inflicted legacy baggage, but a good chunk is simply because of what it's being asked to do. Some of OpenSSL's flaws also appear to stem from interface decisions that cause callers to introduce flaws, -- and the drop in OpenSSL alternatives preserve those interfaces for compatibility.

To the extent that some of these alternatives have dropped support for older standards or weird platforms they might also have improved on the "being asked to do" front, ... if your usage is okay with those limitations.  As far as legacy baggage goes-- we remain in a state where virtually none of the folklore advice about code-smell has been backed by rigorous scientific study.  Programmers are often _extremely_ opinionated about "bad code" yet there are relatively few examples of widely code style differences which are uncontroversially and unambiguous causes of defect-- often complaints about "bad code" really just means "not my preferred style".  In so far as an alternative is only an improvement with respect to some person(s) subjective impression of "bad code" I am extremely wary,  the hardening that software gets from widespread use is commonly and easily undervalued-- if I had to pick between a widely deployed solutions with well understood weaknesses vs something new which is supposed to be subjectively better, I'd pick the former every time.  It seems the market agrees: OpenSSL is extremely widely used compared to some of the new alternatives.

For Libsecp256k1 in Bitcoin we switched not because subjective "code smell" sorts of reasons but because of more objective criteria like:

* Designed for consensus consistency: OpenSSL was provably not consensus consistent and was continuing to actively make changes which damaged consistency with little to no consideration of this class of concern or even adequate disclosure of the changes.

* Free of timing sidechannel secret leaks for secp256k1: OpenSSL's code for this curve wasn't even trying to be constant time. Ours was.

* Formal validation: Libsecp256k1 is partially formally validated, none of the parts of OpenSSL we were using are, to the best of my knowledge.

* Speed: libsecp256k1 was 5-7x faster than OpenSSL.

* Extensive testing: libsecp256k1 had many kinds of tests openssl didn't have at all, and has more now-- tests in libsecp256k1 found serious bugs in openssl, etc.

And sure I think the libsecp256k1 is a lot more readable and maintainable than the relevant code in openssl, and I hope those differences also help lower defect rates... but its all the items above that made it the right thing for Bitcoin to use vs something with a much longer track record, and not some formatting stuff which is inherently pretty subjective and may not actually make the software better.

Even putting aside suitability-to-application, OpenSSL's implementation of secp256k1 has significant secret dependant timing-- so it's not secure if an attacker can measure the time it takes you to construct signatures (potentially even over the internet).  I think that is pretty unfortunate!

This isn't the case for all the curves OpenSSL implements-- e.g. Their P224 and P256 at least attempts (I haven't personally reviewed them) to be constant time.  So you have yet another problem with big grab-bag systems like OpenSSL: the provided security properties are extremely uneven,  and you might think it is secure on the basis of someone's comments with respect to some configuration but find out the hard way that your own configuration is not sufficiently secure.

Then again, *other* than libsecp256k1 ... other implementations of secp256k1 out there, even ones claiming to be "high security" are not particularly free of secret leaking timing side-channels either.  Nor do they usually have tests beyond a couple static test vectors, etc.   From my perspective almost everything else is a joke, but no one cares because the limiting factor in user security is usually something else.  Attackers need not worry about triggering targets to sign a bunch of things on command and then performing complex mathematics to recover the private keys-- they can just spoof an email as the target company's CEO and tell someone to send over their wallet.dat and all too often they will.

Siphash's output is 64-bits and we needed fewer based on an analysis of collisions rates.  It didn't matter which bytes of the output got dropped, some just had to be picked.

It wasn't an option in Bitcoin, other than you could go modify the software to enable it-- which you could always do even if we'd never heard of the optimization. There is no case law that supports a conclusion that implementing something to test it in a non-commercial non-production scholarly manner is a patent violation: considering that the unequivocal case law in the US on the distribution of source code being a first amendment protected right, any attempt to block the scholarly evaluation of patented algorithms in this manner would be on pretty shaky constitutional grounds at best.  Plus how could you even decide if you wanted to implement something without actually trying it?

I can't make any sense of this statement.

This doesn't have anything to do with python. It's a 27% speedup.

Transaction relay is batched and relayed at random intervals because doing so greatly reduces bandwidth usage for relay (due to reducing overheads and due to reducing the number that are advertised both ways on links) and also because its important for privacy as otherwise it's much easier to tell where transactions came from based on when they showed up.  ... and also because there is no particular need for transaction relay to be extremely low latency: blocks are 10 minutes apart on average, after all.


Almost all the data in blocks has already been relayed and validated.  It only takes a 6 or so bytes per transaction on average to relay a block and the only processing needed is a bit of hashing.

pbies, please revise your message to not be acutely nasty.