More public calls for exchanges to drop BSV (bitcoin scammers' version):  https://twitter.com/DanDarkPill/status/1353039875239362565

One comment there mentions coinmarketcap -- maybe even just as important as exchanges are these "market cap"  listing sites,  that end up listing BSV as #14 or whatever due to their illiquid clone-coin fraud... copy the bitcoin ledger then fall to a low enough value that most people won't be bothered generating risk moving the coins.  These presentations do a lot to falsely convince ignorant members of the public that this scam is credible.

Getting them to fix their market cap metrics to not count coins that will never move is probably not going to happen, but getting them to drop a scammy coin that is threatening the whole industry (-- as these sites will eventually be demanded to stop calling Bitcoin, Bitcoin) would be a good move.

It's not clear to me that many if any of those "small size" exchanges matter at all.  Their volume tends to be obviously fake, etc.

It would also act as a signal for exchange integrity:  If only scammy exchanges list BSV you get an additional quick check if an exchange is scammy.

The idea of avoiding him profiting from market manipulation is a good one, but when it comes to BSV there is just no way to stop him OTHER than to reduce the exposure noobs and suckers get to the scam asset.

Another possibility would be for exchanges to change their listing to "PRICE ONLY GOES DOWN" mode:  No order can be entered to trade if for higher than the last price...  exchange it all you want there, but you can never increase the price.

https://www.reddit.com/r/bsv/comments/l3peo2/punishment_of_god_wright_court_filings_expose/

Next project? digging a grave for BSV.

I think in that case it was a .bitcoin directory that included a locked wallet full of someone elses keys (and funds had been sent and swept). There is currently an amazon image with this too (or was as of a few weeks ago).

But the chainstate database/etc. aren't intended as external interfaces and I would be totally unsurprised if there was a way for malicious data in them to result in code execution.

For these questions the applicable time is not when it's activated-- it's when your wallet supports it which will be sometime after the activation.

After your wallet supports it, new addresses will use it.  Maybe in the first versions it will be optional and off by default but eventually it'll just be a default behaviour and you won't have to do anything to get it (besides request new addresses, which you should already be doing for each txn).

Unrelated,  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html

More than many altcoins BSV is an outright scam-- it's value depends on an obvious lie, it's authors are fraudsters.  If these idiots will threaten to sue bitcoin developers (who wrote much of the code their shitcoin depends on!) -- will the hesitate to ship a backdoored node? -- will that notice if someone submits one?

Clearly a lot of exchanges are fine with the ethics of selling fools gold to suckers, but BSV is just a liability.

A lot of the exchanges that list BSV appear to have clearly fake volume.  So which exchanges with BSV are the ones that matter?

It's worse than that... sha-256 has a 256-bit internal state bottleneck, and so that worst case deviation from uniform is likely massively larger than you estimate (though still extraordinarily tiny).

Basically you just consider your last block of input,  there is 512 bits of input text plus 256 bits of state from the prior block and outputs 256 bits.  Even if you model the 256-bit prior-state as totally uniform,  there is "only" 2^512 possible input values for each output value.

Still, according to this counting argument it's absurdly unlikely for there to be an unreachable output ... just not quite as much as your figures suggested.

Wow no, that analysis is just top to bottom full of errors.

"Papers by themselves aren’t licensed".  Not true.  Post Berne convention, any copyrightable work is copyrighted by default, and you cannot reproduce it without a license of some kind. (excepting some special cases like works of the US Federal government)  Papers often do specify licensing (unless they're all-rights-reserved: in which case you're just getting no license), specifying licensing is a universal requirement in academic publication (though sometimes you're not given a choice, you're just forced to assign copyright to the publisher or likewise).

"Open source documentation is also not copyrighted if it is given away in an open source license."  All licensed open source works are copyrighted.  The license permits you to do all sorts of stuff (if its an open source license), but it's still copyrighted and some rights are usually reserved (for example, even the most permissive licenses don't generally allow you to falsify attribution or strip licensing info).

"If the author or other owner claims ownership and registers it or uses (c), date and the copyright holder’s name at publication then it’s usually considered copyrighted."  post berne convention no copyright notice or registration is required for a work to be copyrighted. It's considered a polite practice, but is legally unimportant now.

In the US you need to register to sue in court, but that doesn't need to be done proactively in advance.

"the gift can’t be taken back and claimed as a copyright." The work is still copyrighted, so this sentence is just incoherent.  The licenses isn't revocable.

"If a copyright holder allows publication of a work by other sources and does not challenge this, the holder weakens its claim.", unlike trademark there is no duty to enforce in copyright.  Though there may be equitable defences in some situations (see mention in the letter) they are generally fairly narrow, and don't implicitly create a duty to enforce.

Providing actually false information doesn't help anyone, even if it's falsehoods used to cheer along a good cause.

Edit: After writing this, I found out that my partner, who is an attorney on the board of the Free Software foundation and is one of the authors of the CC-4.0 licenses independantly attempted to correct many of these and other errors earlier today and was just blown off.

I've updated this with a new most excellent section that was substantially contributed by Arthur Van Pelt using supporting documentation provided by xtraelv.

People have frequently asked what equitable defences means: https://en.wikipedia.org/wiki/Laches_(equity).

We Are All Satoshi

Except for Craig S. Wright.

Craig Wright definitely is not, but he would really like everyone to believe he is.

Satoshi Nakamoto authored the Bitcoin Whitepaper with the intention that it be shared widely, and Craig Wright’s takedown notices are fraudulent, but since he is a litigious jerk who has bankrupted people with his fraudulent legal claims in court, it is sometimes a wise strategic choice to avoid provoking him into suing, which is expensive and disruptive to a defendant even when they ultimately win.

But you might be in a good position to host this paper that Craig Wright so desperately wants taken down and kept under his exclusive control. And you might want to give notice to his attorneys, just to let them know.  Below is an example notice you can send to his attornies.

Warning: sending this makes you considerably more likely to become the target of a lawsuit by Craig Wright. You should think about whether you are prepared to be in that position before sending this letter.

(This is absolutely, positively, not legal advice, and you are strongly encouraged to consult with your own attorney.)



Old version:

That isn't a great way to reason about security. To give an example: Namecoin went with zero protection against stealing names for many years... and then suddenly a bunch were stolen at once.

A lack of attack so far doesn't mean something is secure.

Now-- bitcoin could probably lose hashpower and still be secure enough (esp because you could respond by just waiting days until you considered a transaction final...),  but I don't think you can conclude much from the lack of attack against some random low hashpower scamcoins.  A safer conclusion is that there is such a tiny amount of real economic activity behind them it just hasn't been worth the time and there are more profitable things to attack.

It's also security theatre because most of the coins in circulation are stored in addresses that have been reused.  "If you owe the bank $100 that's your problem. If you owe the bank $100 million, that's the bank's problem."  -- even if it did provide some protection to you (though I don't agree that it does, for the reason Carlton notes), it wouldn't matter because of everyone elses exposure.

I'm pretty confident that I started that whole meme that the hashing was protective,  I intended it as just a minor quip that it wasn't necessarily a pure waste of resources and might have some fringe benefit.  People have spun it into something I never intended, and I regret suggesting it.

Ah, that isn't quite correct-- unless I misunderstand you and we're just violently agreeing.  You can very easily make a program to prove other programs will halt. But it will have to sometimes output "I dunno".  On some programs it will output "Halts", others "Runs forever"-- but if it's deciding a turing complete language it will sometimes have to yield an "I dunno".

The ambiguity of English with respect to the meaning of "any" is annoying which is why the word arbitrary is important.  You can make a decider that decides if some programs will halt, but you cannot make a decider that will be able to decide all arbitrary programs without the possibility of returning that it can't tell. But users of smart contracts don't use arbitrary programs, they use specific ones and can restrict themselves to ones that can be decided.

An easy way to see this is so is to imagine that it simply looks for any loops or recursion and returns I dunno if they're *used*, in that example the language is Turing complete, but it checks if you use that ability.  Obviously that is a little limiting, so it can then allow them but only when it can prove how many times they'll execute at most.  So for example, if you have a program that does a for(int i=0;i<min(5,max(1,input));i++) and contains no other writes to i, then a program can prove the the loop will run only 1-5 times and thus will halt.

This kind of variable range analysis is something any moderately complex compiler already does already (e.g. it's needed for things like loop unrolling or to prove some code is dead so it can be eliminated).

A concrete example of this is the ebpf system in linux that lets you inject tiny programs into the kernel.  The ebpf language allows arbitrary jumps, but at load time the kernel performs an analysis and will not let you load an ebpf program that it cant prove will halt (in fact, there is even support now for loops like the one I describe above).  Sometimes you will write an eBPF program that absolutely will halt, but the prover in the kernel is just too stupid to reason it out and you'll have to use a different program.  Data-dependant-but-bounded loops are an example prior to the change I linked,  and you could usually work around that limit by always looping the maximum number of times and including conditions to make some of those loops do nothing, depending on the data.

Another really dumb example would be if the prover simply ran the program on all possible inputs, and if it was able to exhaust the input space with fewer than a million operations performed, it would return halt, if it detects (in fewer than a million operations performed) that the program reached a state that it had been in before *exactly* then it returns "runs forever", and if it runs into its million operation limit it returns "I dunno".   This is a dumb and inefficient example.  But it gives an intuition about how even though the problem of deciding is intractable by adding the possibility of returning "I dunno" it becomes tractable.

There is a whole field of formal validation which is all about reasoning about programs, including ones written for Turing complete languages, and proving their properties (including that they will halt).  All turing's thesis means is that it will always be possible to create programs that these systems cannot reason about, but that isn't a problem for a prospective user because they get to pick the programs will or won't use.

In any case, this is just pointing out that *users* can still safely reason about the programs they choose to use when they use a turing complete system, because unlike the turing decider program they don't have to work on all programs, just a subset of them and they can refuse to use any their tools can't analyize.

That's true (though it's overkill, one can protect the network with less potent means -- like how the linux kernel protects itself from rogue eBPF programs), but it's not relevant to the discussion here.  The DAO's faulty script wasn't a question of network protection, it was a question of users failing to protect themselves.  It only became a network issue because the corrupt administrators of ethereum had invested in the dao, weren't willing to take a loss in the name of principles, and had the level of control required to pull it off.

I actually don't think it's a actually trade-off: I believe that every program usefully expressed for a blockchain can be expressed without turing completeness: This is because validating the result of any NP language can be done in P time.   Blockchains don't need to actually compute anything (and ought not to): they can verify the computation performed by some user/host external to the consensus... and that's obviously what you want to do because operation inside consensus is absurdly expensive.

Eh. It was an implementation bug in the smart contract, not ethereum itself-- pretty similar to the DAO.  Perhaps it's better to note that fixing it wouldn't be stealing from anyone: the funds are just frozen.  Vs in the case of the DAO taking the funds back didn't just violate the smart contract, it unambiguously violated the human-language legal contract on the DAO website because it was all-caps unambiguous that even if the smart contract did something nuts, it was what governed the agreement.

Your question is underspecified. A bug in what?  In a smart contract their wallet uses?  That has happened before, tough "luck" for them.  There was even a case that people lost money due to a miner in bitcoin core, and it was just tough luck for them.

An example of this is that MTGox sent thousands of Bitcoin to an improperly encoded scriptpubkey, tough luck for them (and their customers-- which, incidentally included myself and may other long time well know bitcoiners).

The integrity of the system is almost its only reason to exist, and it's not something to be trifled with just because some users messed up.

If instead you mean some consensus bug that allowed, e.g. validation to be bypassed due to a flaw in Bitcoin itself. That's sort of issue can be softforked out -- not accepting the bogus spends -- without breaking the consensus.  And has been:  Originally a spending scriptSig could just toss in a OP_TRUE OP_RETURN and the spend would be accepted before the payer specified conditions were ever even evaluated.  Satoshi deployed a change that wouldn't admit transactions that used OP_RETURN at all (it would have been sufficient to deny it in only scriptSigs, but at the time the interpreter worked by concatenating the scriptpubkey onto the scriptsig so it wasn't simple to make this distinction).  This didn't disrupt consensus because nodes already have the unavoidable ability to decline to include transactions that are otherwise valid... and once more than half the hashpower was running this rule it could be enforced without any potential for a lasting consensus split.

(emphasis mine)

Ethereum blabbered on about "unstoppable code" but at the end of the day for ethereum it's just marketing blather  For whatever its other faults, Bitcoin exists for a reason higher than just making money for people... having principles means that you sometimes have to bite the bullet and take on an uncomfortable cost, because to fail to do so would moot the endeavour.

I agree that Turing completeness is unnecessary (I believe this is indisputable, in fact) and an unwarranted liability but I don't really agree that it is to blame for the dao drama.

Undecidability means you cannot decide if an arbitrary program will halt (and, as a consequence, you usually can't make strong statements about what an undecidable arbitrary program will or won't do, since you can't tell if it will or won't halt before an arbritary step).  But even though a language is Turing complete an enormous portion of programs you might want to run on it are decidable, if you limit yourself to only engage with decidable programs then it could be absolutely proven that they will or won't take certain actions.   One can also use Bitcoin insecurely-- for example you could publish your private key on Bitcointalk-- and that doesn't make Bitcoin itself bad.  So, similarly, "arbitrary" usage of Bitcoin is insecure, but sane users don't use Bitcoin in arbitrary ways: they use it in safe ways.

Even if script allowed recursion and or loops, you could easily write script -- including ones that *used* the recursion and loops-- which could automatically be proven to meet whatever safety property you desired.  An arbitrarily selected program would not be provable, of course, but it's easy to write ones that are.  The absence of recursion/loops/etc, instead, make it a lot easier to reason about the safety and stability of the consensus rules and reduce the risk of scripts that crash nodes or use unreasonable amounts of resources.

For the Dao Debacle and many other horrifying eth failures, the real issue in my view is that these smart contracts are in fact cryptographic protocols but the whole frequently-hopping-scam-spectrum business model of ethereum (basically cooking up crooked financial schemes faster than people can get arrested for them or the public can learn to not get ripped off by them) basically depends on ignoring this unfortunate fact.  Make a smart contract is not really different than inventing a new block cipher, secure communications protocol (like TLS), or zero knowledge proof.  As cryptographic protocols we should recognize that they are ABSURDLY brittle, and that even when designed and reviewed by the worlds foremost experts they can easily contain utterly devastating flaws that leave them completely without security and these flaws can go a long time before they're detected and suddenly exploited.  As such, an extraordinary level of diligence is required when creating them, justifying things like formal methods (e.g. techniques to prove properties of computer programs).

And the eth software stack and ecosystem is not particularly well suited to the required sort of diligence-- worse, their smart contracting functionality is primarily promoted as being extremely accessible and suitable for even relatively inexperienced UI developers.  This is a toxic mix with predictable results.

But faulty smart contracts are extremely common in ethereum and were common before the dao drama, and yet they did not result in editing the ledger to steal funds from the technically-correct-but-surprising execution of the smart contract-- violating the "Unstoppable code" headline promise of the ethereum crowd sale.   So the flaws in the dao contract and the ethereum ecosystem aren't really relevant to the drama because they don't distinguish it from 100 other events.  What does distinguish it is *who* lost money and the incredible control they wield over the system because they premined the vast majorty of its coins and continue to control billions of dollars worth of them, and the lack of integrity and self control exhibited by those persons.

Removing the 'overflow' transaction worked within the protocol and consensus systems.  Hashpower extended one chain rather than another, and eventually the network reorged.

If you were running old unfixed software you followed along just fine.

By comparison, in eth-- the rules of the idiot scam investment contract allowed someone to take the funds. Absolutely nothing malfunctioned in ethereum itself (for a change...), it worked precisely as it was supposed to. The webpages for this "investment" were abundantly clear in allcaps text: the programmed rules are binding and final.  Ethereum developers invested millions in the sketchy contract (and were in, fact, part of its operators as official advisers and key holders) and then when it didn't go their way they edited the ledger to restore the funds and forced users to upgrade, using the threat of withdrawing their support (which was significant, due to their massive premine).

Worse, when some users created a fork the ethereum corporation used an exploit on it to steal funds from the original attacker and then tried to dump them on the market ... but they got caught and ended up returning most of them.  Bitcoin wasn't made mutable in a way that it wasn't always mutable.

So by comparison:

Bitcoin itself malfunctioned in an obvious way where it couldn't continue since anyone being able to print billions of coins out of nothing is an obviously useless system.  Working *within* the consensus rules, using the fact that nodes follow the most-work-valid-chain the malfunctioning transaction was kicked out in a way where any transaction could have been kicked out.  Doing so created no winners or losers (Bitcoin simply couldn't continue under the broken rules)-- and absolutely no one complained about or disagreed with the change.  The developers/miners  that drove fixing it stood to gain nothing personally from the event, other than just keeping Bitcoin working at all.

Imagine that you reject the fix and want to keep running the original anyone-can-print-coins-out-of-nothing code.  You can do that. What chain are you on?  The current Bitcoin chain.

Even if you wanted to be an absolutist that we had to do what the code said-- the bug was actually triggering undefined behaviour in the C++ language.  It's not formally defined what happens when those signed integers overflowed.  Rejecting the transaction was as valid an action as accepting it, according to the C++ language.  Had it happened to be the case that a popular compiler saturated on signed overflow instead of wrapping or if popular ones crashed on signed overflow (some actually do, but didn't in this case), then what happened-- a chain without the txn gaining the most hashpower-- would have likely happened naturally without any human intervention at all, though it might have taken a while.

The "problem" in the case of Ethereum was that it worked exactly as designed and advertised. People with effective control didn't like the result, and edited the ledger to return funds to themselves. They manipulated the markets by demanding trading halts in secret (the logs of which have subsequently been leaked). When a competing chain was formed by users who disagreed with the ethics they attacked it technically and economically.  They personally benefited from this change, and in subsequent similar cases of flawed smart contracts -- including ones losing much more in terms of dollar value-- they declined to intervene (and opposed intervention) when their own funds weren't at risk.

I don't think it's remotely comparable:

Overriding the system (editing the ledger) vs Within the system (adding hashpower to a branch without the bad transaction)
Incompatible with prior software vs compatible with prior software (as a result of the above)
Clearly correct function (Ethereum) vs Objectively and indisputably incorrect function (Bitcoin)
Ethereum change just edited the ledger and made no fix to the system  vs Bitcoin change fixed the system without editing the ledger and the ledger fixed itself.
Personal profit vs No particular personal gains
Subsequently didn't aid in identical cases where eth admins had no losses vs no subsequent cases in Bitcoin (even though there were plenty of cases where bitcoin figures had losses)
Backroom dealing and pressure vs transparent communication
Acting to destroy peoples ability to disagree vs no one disagreeing

If you want to look at a similar event in Bitcoin's history-- go look at MTGox losing the customers funds.  No one (at least no one serious / high profile) even suggested editing the ledger to "fix" that-- even though many well known Bitcoin personalities would have theoretically stood to gain *enormously* if such a thing were done.

I haven't seen that.  Because Ethereum is massively premined (a windfall they're currently in the process of locking in by reducing the issuance again and then making it go exclusively to existing large holders), it's a centrally controlled system as was aptly demonstrated by the event in question.  It is whatever it's scamming owners want it to be, as you can see.

It was hard to convince people that it wasn't legit when so many people were promoting it, as a result of promotional deals.

Maybe some good resources here: https://behindmlm.com/companies/bitclub-network/bitclub-network-ditch-bitcoin-payments-for-bitcoin-cash/

If you want to recover anything, however, you'll probably have to chase down all the involved parties since the principles seem to have spent or hidden the funds well.

It may just take a  bit for the existing v3 peers to find out about you and bother connecting.

I don't think hacking to downgrade to v2 makes sense-- the tor network will be completely deactivating v2 in a couple months, so anything that hasn't migrated will just suddenly stop working.

Your node will work fine without any inbounds at all, and as more nodes switch over it'll be good that you're there providing capacity.

It's also likely the case that many of your prior connections were spies.  ... the spy companies tend to be really lazy and bad at their job (small blessings...), so I wouldn't be shocked if they didn't move off v2 until months after it was totally gone.  

I'm pretty doubtful that will work.

The data being sent isn't a set!  The order is needed.  The order could be guessed and a correction to the guess sent, but thats fairly complex.

GCS's savings come mostly from not encoding the permutation of elements. (Some savings comes from non-duplication, but when the 2^keybits is large compared to the number of entries, non-duplication saves very little.)

There are ways to make compact blocks smaller, much smaller in fact--  e.g. I had a prototype implementation that used minisketch which made typical compact blocks about 800 bytes.  But there seems to be littler reason to bother further reducing the size right now.

(This also required the above mentioned guess and correct ordering-- in my case I didn't implement correction and only supported it on blocks where the guess was 100% correct: ones where the miner didn't use prioritization, which is most of them)

Probably more important would be techniques from fibre that let blocks propagate unconditionally without round trips at all even when some txn are missing or some packets are lost.