Here's a whale playing with the concept:
https://blockchain.info/tx/29926a5316e59348ea7de95a5966b9e565de42c44f3bd79ba7142b7035b62e7e?show_adv=true

Oooh, lotsa (half-)bitcoins! Much wow!

Um, yes-ish, but not quite in the way you probably mean. First of all, software development always takes ten times longer than you think, so I was making slow progress anyway. (And my life got complicated in various other ways that didn't help.) But now, something new has happened. Peter R has proposed a new standard for launching alt-coins: "Spin-offs: bootstrap your alt-coin with a bitcoin-blockchain-based initial coin distribution". I'm very impressed with this launch style, and I think it's the right way to launch Splash.

Unlike the proof-of-work way of minting XSP, though, I'm not claiming any special insight into the technical details of getting "Splash as a spin-off" done. (Even in the proof-of-work case, I wasn't really claiming that stunning an insight anyway. Essentially just a syntax for XSP-birth transactions that mentions only work and not money [XSP amount]; which simplifies how they can be baked into the consensus, without having to pick and choose among them if there's lots of them, and yet without ever exceeding the desired XSP asymptotic total, no matter how many of them are floating around.) So, "Splash as a spin-off" would really better be done by other people who may like to give it a go, rather than by me.

With that in mind, it's grand announcement time! I hereby relinquish the name "Splash", the slogan "Ripple without the pre-mine", and the currency abbreviation "XSP" to whoever is first to fork Ripple in spin-off style, i.e. starting with the Bitcoin UTXO-set - or, to be precise, the subset that translates into the rather impoverished Ripple address syntax (no multi-sig, no scripts, just single pubkeyhashes). - Or they could do it in Counterparty's style, with XSP minted by BTC being burned. Basically I relinquish to whoever is first to do a Ripple fork without an allocation by software special-case fiat to the developers, or to any other special cases. (That even includes doing it in my originally intended way, namely, XSP birth by proof of work. As I say, I'm no longer so enamoured myself of that way of doing it, but it certainly qualifies as not privileging the developers or other special cases, so... if a team doing it that way is first, they can grab my names and slogans. )

OK let's hope Splash in some recognisable form comes into existence! Let me summarize by putting it like this: I've given up my own personal involvement, but I haven't given up the dream.

One thing people will have to watch for, as they spend their spin-off coins, is privacy implications. If you have a bitcoin address A, replicated to various spin-offs, then each time you notice you have a non-zero balance in some spin-off and decide to spend it, new spendings from address A go out into the public domain. (It might not be called "A" in the spin-off's preferred widely-promulgated syntax - which might use a different prefix, error-correcting suffix, etc. than bitcoin's - but the underlying pubkeyhash must, of necessity, be the same.) The effect is the same as if someone working entirely within one coin accumulated multiple txouts to one address and then spent them to different recipients on different occasions. Blockchain-watchers can learn a lot from this, which is why it's not recommended. Well, with spin-offs, they can learn the same sort of things.

Naturally, coinjoin and the like will spring up in the various spin-off communities, and people who know what they're doing can mitigate the privacy dangers. There is, though, the worry that any particular spin-off might have a rather small community, and not really support good coinjoin mixing.

Having said all that, I must say I'm really impressed with the whole spin-off concept. So much so, that after dithering for a while, I've decided to abandon my "Splash: Ripple without the pre-mine" project, and leave it to someone else to fork Ripple in spin-off style, i.e. starting with the Bitcoin UTXO-set - or, to be precise, the subset that translates into the rather impoverished Ripple address syntax (no multi-sig, no scripts, just single pubkeyhashes).

So, grand announcement time: I hereby relinquish the name "Splash", the slogan "Ripple without the pre-mine", and the currency abbreviation "XSP" to whoever is first to do this. (Or they could do it in Counterparty's style, with XSP minted by BTC being burned. Basically I relinquish to whoever is first to do a Ripple fork without an allocation by software special-case fiat to the developers, or to any other special cases.)

So there you are! You can tell I'm really taken with the spin-off idea, can't you? But please, everybody, bear those privacy aspects in mind!

Would it help if the protocol was changed so that, from a certain future block onwards, all transactions must identify any previous transaction they're spending one or more outpoint(s) of, not by the hash of the whole previous tx, as is required today, but instead just by the hash of the core parts of the previous tx? (its inputs/outputs/values, not its signatures.) After all, the purpose of a txid is merely to identify a tx, not to "bless" it as valid. That blessing has already happened when either the free-floating transaction was checked (including signature-checked of course!) and accepted into one's mempool, or a block containing the transaction was checked and found to be valid, or both.

This has the wonderful consequence of rendering unnecessary the endless "arms race" of finding sources of malleability and shutting them down one by one - inventing endless new rules (relay ["standardness"] rules or, eventually, validity rules) about how to write an integer, how many OP_DROPs to put here or there, what syntax to use for ECDSA signatures, etc etc ad nauseum. None of this would matter any more. The new-style txid would stay the same.

Validating nodes would need to do a re-indexing of their UTXO database as the switch moment approached, re-labelling all entries as "outpoint #n of [new-style txid for that tx]" rather than "outpoint #n of [old-style txid for that tx]", in order to be ready to do quick lookups from the switch moment onwards. However, this is a purely private matter for each node, to help with its efficiency. Publicly, the stream of new transactions and blocks would simply, seamlessly, switch to using the new-style txids.

Does this break anything?

Ah, sorry, I maybe didn't explain things very well. I'm not intending to use PoW universally, as anti-spam in every transaction; although that's certainly a future possibility, for both Ripple and Splash to consider, if the existing regime of charging a small fee that escalates on signs of "spamminess" proves insufficient. For now, the existing charging regime seems to be working fine, in Ripple, and I intend to simply use it unaltered in Splash.

My usage of PoW will be technically far more humble (and yet, philosophically, quite pivotal): namely, as the unique way the native asset (XSP) is ever born. Once born, though, it then behaves just like the XRP in Ripple: it moves around via ordinary (non-PoW) transactions, acts as a path shortener in order book matching etc, and is the unique unit for denominating reserve requirements and anti-spam fees. And none of that activity will involve PoW at all.

About possible mixed systems: yes, it would certainly be possible to have a Ripple fork with both an "XRP" (either owned entirely by the fork's developers at launch, or snapshotted from Ripple at the fork moment) and an "XSP" (born gradually by PoW). I'm not sure that path-shortening or anti-spam would really be helped much by having two native assets rather than one; but I suppose if some people philosophically prefer the one kind of native asset and other people the other, they can express their preferences in their holdings while still all being members of the one giant mixed system. (And thus able to trade with each other.) My own development preference is to build a "clean slate" self-contained system. But other people can fork Ripple (or indeed Splash!) any way they please. I hope, if they do, they choose to document their development adventures in this forum, or some other prominent place on the web.

(I'm intrigued by your mention of BTC or similar as a possible native asset. I presume you don't mean an IOU that happens to be spelt with the letters B,T,C? Do you mean some sort of crossover protocol, where burning of blockchain BTC causes something called "[non-IOU] BTC" to appear in Ripple shortly afterwards? [There'd be no crossing back of course. Not unless the Bitcoin developers, ah, got the Ripple bug. ] Or do you mean something else entirely? Apologies for sometimes being slow to understand things. - Again, whatever your exact meaning, this would be for someone else to try: I'm going to try a clean slate.)

And now, finally, as I've said in my edit of my "(reserved)" post up at the top, I'm afraid I'll be away from the net for a fortnight. So don't be alarmed at my falling silent after this message. Rest assured, I definitely plan to conduct my development process in the open... probably on GitHub I'd imagine. - I should confess right away, here and now, that I'm still a novice at the management of a really large, heterogeneous body of code. Put it this way: I still haven't got Ripple to compile yet on the machine I'm using, so I'm nowhere near ready to start tweaking it! But even if Ripple forking defeats me utterly, I'll still aim to put pseudo-code on my wiki page, with the hope that someone else has a go at turning it into a real, working fork.

Thank you for wishing me luck - I'll need it! See you all in a fortnight.

That's an interesting thing to think about. I've been wrestling with the proof of work choice for a while now. (I didn't think specifically of BOINC or similar grid projects, but I thought of things like memory-hard functions over the whole ledger history - things that would be helpful if ever proof of work did move to ledger [validation] level after all.)

In the end, I'm planning at the moment to just stick with one of the two best-known "intrinsically pointless" hash functions, namely SHA256 or Scrypt. I know this will disappoint you, and I'd better say at least a few words to justify my choice. The main criterion is that verification must be utterly simple and unambiguous. Everyone who's in any doubt that a ledger history might be suspect in some way, must be able to establish beyond doubt that the hashes are valid solutions to a problem of the required difficulty.

As I understand things, the various scientific/medical grid@home projects - BOINC, SETI, folding... - all publish problems, ask people to work on them, and then say "scientists will get back to you (and at least congratulate you, put you on the fast track to fame, maybe offer a money reward in some of the projects... whatever) when they're happy you've found a worthy solution to a worthy problem". And there's the rub. How can a validating node, listening in on someone else's reported proof-of-work triumph, know the triumph really means anything? What if it's not a BOINC-approved protein that was being folded, but a similar-looking one that a protein expert could have told you was much easier to fold? The software would need web-interrogating interfaces to "BOINC HQ" or whatever, to check that BOINC at some earlier time "blessed" the problem just solved as a hard one. You see why I'm worried that this is all just too much for a software system to cope with.

For now, then, I'm planning to go down the well-worn "pointless work" route. - Probably Scrypt in preference to SHA256, since many people will only aspire to mine a one-shot, small, "bootstrapping" amount of XSP - just enough to set up a few orders and trust lines and the like, with a view to then acquiring and holding and spending other [IOU-type] assets. Such people will have no intention of thinking of themselves as miners in any long-term sense; they certainly won't want to buy an ASIC. They'll just want to leave an "ordinary" CPU/GPU running overnight or over a weekend, and wake up to discover they've successfully created a few tens of cents' worth of XSP, which is enough to let them start interacting with gateways, etc etc. (If serious miners were meanwhile using ASICs, then they'd out-compete the casual folk, who'd wake up to discover they'd mined nothing, rather than a reserve-and-a-few-account-lines quantity of XSP.)

I'd be delighted to be proved wrong on this choice. If there's a decentralized way of knowing a just-solved scientific problem was hard for the solver - i.e. a way not involving "chatting to BOINC HQ" or the like - then by all means let's go for it, in Splash or elsewhere! But for now, Scrypt is my likely choice. (I'll naturally try to write modular code, isolating the choice of proof-of-work task from the rest of the code, so that any breakthroughs in "decentralizing meaningful science" can be seamlessly switched to as and when they happen.)

Oh, and one final thing which might cheer you up: in your last paragraph you mentioned mining software being a difficult beast to master. Well, the good news is that moving proof-of-work from ledger (block) level to transaction level makes mining code vastly simpler. The reason is, rather pleasingly, it doesn't need to keep up with the ledger chain, or even be online! In the casual scenario above, where someone's trying to open a brand new Splash account (address) with a modest XSP balance, they just need to pass their currently-unfunded Splash address to their mining software, along with their rough target XSP amount to try and mine, and two public facts they can collect from any reputable "ledger explorer" site: the current (or reasonably recent) network difficulty figure, and the current (or, again, reasonably recent) ledger hash. The mining software can then chug away without even needing a net connection; and a day or two later, when it strikes lucky with its proof of work, it can proudly output its transaction for broadcasting on to the network. (Perhaps as a QR code - the transaction will be small.)

(The quid pro quo for this implausible-sounding miracle, of the mining software being able to be offline, is that when the transaction is broadcast and absorbed into a ledger it may not create precisely the stated target quantity of XSP. In practice the variation is unlikely to be more than a few percent. So if it's absolutely vital to you that you start your Splash adventures with 70XSP, it would in practice be enough to say to your mining software "I want to aim for 80". And then you might end up with 70 or 75... or 85 or 90.)

In the corresponding "professional" scenario, where a serious miner wants to keep topping up the same Splash address with ever more freshly-mined XSP, the software would need to be told a third and final public fact: how many times that address has had successful mining done on it already. (This is to avoid a certain kind of network spam, known as work re-use.) Even that small additional fact doesn't really need to be "told" in so many words, so long as you're only running one instance of your mining software, and it has read/write access to persistent memory of some sort (disk space, a browser cookie,...). (Because then it can jolly well count the number of mining events itself! That is, add 1 to its persistent-memory counter on each finding of a work solution, ready for its future self to be solving the right future work problem.)

Sorry if this all seems a bit cryptic - eventually I'll be describing, in full technical detail, my transaction-level mining protocol, but I'm not ready for that just yet - but I hope I've whetted your appetite for now, and teased you with the possibility of Splash mining software being simple enough that it can be installed with the same ease and panache as BOINC! I hope that's at least some consolation!

The world has certainly had its fair share of IOU scams, yes! In fact my original conception of Splash was to be "Ripple with nothing but the pure currency" (the XRP). (And, of course, without the pre-mine.) This would then act as a testing lab to see just how well the consensus algorithm works, especially under DDoS attacks, Sybil attacks, etc.

However, in the end I decided to leave the full IOU-managing functionality in place. I had two motives: (1) it's there for those who want it, and it can simply be ignored by anyone who doesn't want it - they can choose to only ever use the pure currency (the XSP); and, uh, (2) you'd be amazed how long editing other people's code takes... it's easier to leave it in than to take it out!

If, after Splash is up and running, someone wants to fork it to "mini-Splash", with nothing but XSP, created purely by proof of work, and ledgers managing the XSP, created purely by the Ripple consensus algorithm... then yes, that would be an interesting experiment too.

(If they took it just one step further, and changed the consensus algorithm to a find-chain-with-most-work algorithm... then they'd have pretty much reinvented Bitcoin. )

(reserved for further updates etc.)

NOTE 2013-12-18: I'll be away from the net for a fortnight, and rather busy even after getting back online. I'll likely not be settling down to proper Splash development till mid-January. (yeah, maybe my late February launch date is a tad optimistic... time will tell...) Please don't think badly of me if I'm not very responsive, in this thread or elsewhere. I'll probably still be lurking, and thinking carefully about everything everyone has to say.

EDIT 2014-05-04: I'm throwing this open to the community, since I have to concede large software development defeats me. It always takes ten times longer than you think, so I was making slow progress anyway. (And my life got complicated in various other ways that didn't help.) But now, something new has happened. Peter R has proposed a new standard for launching alt-coins: "Spin-offs: bootstrap your alt-coin with a bitcoin-blockchain-based initial coin distribution". I'm very impressed with this launch style, and I think it's the right way to launch Splash.

Unlike the proof-of-work way of minting XSP, though, I'm not claiming any special insight into the technical details of getting "Splash as a spin-off" done. (Even in the proof-of-work case, I wasn't really claiming that stunning an insight anyway. Essentially just a syntax for XSP-birth transactions that mentions only work and not money [XSP amount]; which simplifies how they can be baked into the consensus, without having to pick and choose among them if there's lots of them, and yet without ever exceeding the desired XSP asymptotic total, no matter how many of them are floating around.) So, "Splash as a spin-off" would really better be done by other people who may like to give it a go, rather than by me.

With that in mind, it's grand announcement time! I hereby relinquish the name "Splash", the slogan "Ripple without the pre-mine", and the currency abbreviation "XSP" to whoever is first to fork Ripple in spin-off style, i.e. starting with the Bitcoin UTXO-set - or, to be precise, the subset that translates into the rather impoverished Ripple address syntax (no multi-sig, no scripts, just single pubkeyhashes). - Or they could do it in Counterparty's style, with XSP minted by BTC being burned. Basically I relinquish to whoever is first to do a Ripple fork without an allocation by software special-case fiat to the developers, or to any other special cases. (That even includes doing it in my originally intended way, namely, XSP birth by proof of work. As I say, I'm no longer so enamoured myself of that way of doing it, but it certainly qualifies as not privileging the developers or other special cases, so... if a team doing it that way is first, they can grab my names and slogans. )

OK let's hope Splash in some recognisable form comes into existence! Let me summarize by putting it like this: I've given up my own personal involvement, but I haven't given up the dream.

(...or "pre-non-mine", or whatever it should be called exactly).

EDIT 2014-05-04: I'm throwing this open to the community, since I have to concede large software development defeats me. I'm recommending Peter R's "spin-off" concept as the best style for Splash, but anyone who wants to do it my originally intended way is welcome too. See message immediately following this one for my grand announcement putting the Splash names / slogans up for grabs.

(original message resumes here...)

I'm currently developing a fork of Ripple which may be of interest to readers of the alts section of the forum. I call it "Splash: Ripple without the pre-mine".

There's been a lot of talk recently about possible forks of Ripple - in particular, is it possible to do without the built-in ripples (XRP), and have only IOUs with counterparties, denominated in external currencies? Well, maybe that's possible, and if someone wants to have a go, it should be an interesting experiment. But for myself, I quite like the existence of XRP. It has useful path-shortening and anti-spam functionality, which would be difficult to achieve with only externally-defined IOUs. And it's nice to have something counterparty-free in the system.

The thing I don't like about Ripple's XRP, though - and I know I'm not alone in this! - is that it's "pre-[non-]mined": created by software fiat in one big bang at the start, and allocated to accounts controlled entirely by RippleLabs. RippleLabs then starts behaving something like a central banker, introducing it into circulation as it sees fit. All users must play guessing games about just how fast or slow they'll be in doing this.

It would be so much more in keeping with our community's traditions if XRP could instead come into existence gradually, by proof of work mining, asymptoting towards a ceiling quantity on a fixed schedule everyone knows in advance - i.e. like Bitcoin.

The Ripple folks have stated that their consensus algorithm is not compatible with proof of work. Well, I'll take their word for it - and in Splash I'm leaving the Ripple consensus algorithm alone: I'm not trying to introduce proof of work there.

The exciting news is: I've found a way to introduce proof of work at transaction level, rather than ledger (block) level. Thus, barring any unexpected hitches in the development process, I hope to unleash Splash on the world soon.

Splash will be just like Ripple in its core user functionality - it'll have both a built-in pure cryptocurrency ("splashes", XSP), and the ability to manage IOUs with counterparties, denominated in other, external currencies. All the Ripple trading and order book features will be present unchanged. The difference will be that no XSP will exist initially. All XSP will be born by decentralized, anonymous miners submitting a special kind of transaction to the network: one with proof of work embedded in its syntax, which, when accepted by the Splash consensus algorithm into a ledger, causes new XSP to be born at whatever address the miner chooses.

I'm hoping to launch around late February 2014. In the meantime, I've put a Splash page on the wiki: https://en.bitcoin.it/wiki/Splash (still very introductory for now). I'd be delighted if any Ripple gateway folk would be interested in running a Splash gateway too. For example, perhaps the good folks at DividendRippler (https://dividendrippler.com/) might like to run a "DividendSplasher" too?

This is, as I say in the title, not so much an ANN as a pre-ANN. I hope to say more as development progresses, either here or on the above wiki page (or both). Wish me luck!

One from me, so it's not famous, but maybe it'll become so:

"Bitcoin interprets know-your-customer legislation as damage and routes around it."

blockchain.info seems to have hard-forked itself about an hour and a half ago. My local bitcoind is up at block 237307 (hash 00000000000000dd3d053fa66aa7e336e0f8339b0a2297cdc446743d3c88bf06); blockchain.info is stuck at should-be-orphaned 237298 (hash 000000000000002bcaf84854f751e9e6d85f54a308faa12e26c84875c54d9e86). What's going on?!

If it helps: the winning chain's 237298 (hash 00000000000001045defb8087b606cae318d02a0b04403ba11a484cb1487e9d0) is the point of first disagreement, i.e. 237297 before it (hash 000000000000005baf99bd1784a0ea57bf5da1f974b3d0dd0bfcdfe68772f0b4) is the point of last agreement. Also, the two competing 237298's arrived [at my local node anyway] within seconds of each other. (Which, of course, should not be a problem.)

EDIT: All is now well! But that does still leave the question: how did such a well-connected node as blockchain.info fall so far behind in the first place?

rDsMi9hkqsaMYNEfTRkvxvoYK3M8yje8UC

I wonder if it might be possible to decentralise the validation process itself, in a way that lets the blockchain become much bigger, but with spotting when rules are being violated remaining cheap?

I'm thinking of mathematical proof-of-correctness tools. (Disclaimer: I don't know much about the contemporary details of such beasts. I played with one called "Lego" a long time ago... there are probably better ones now.) The idea is, a future giant blockchain would be distributed (peer-to-peer torrented) in the syntax of a giant theorem: "THEOREM 0. Under rule-set R, the genesis block is valid. PROOF: blah blah blah. THEOREM 1: Under rule-set R, if block 0 is valid then block 1 is valid. PROOF: blah blah blah. THEOREM 2: Under rule-set R, if blocks 0 and 1 are valid then block 2 is valid. PROOF: blah blah blah. (and so on)"

The proof syntax would have the "wrongness is locally detectable" property (achieved by bounded fan-in and fan-out of the dependency of parts of it on other parts). That is, if any part of the proof was wrong, either by incompetence or malice on the part of a "super-miner", the community could detect this wrongness without any one member of the community having to parse their way through the whole thing. Sceptical community members would simply point their mathematical proof-of-correctness tool at any randomly chosen part of the giant proof object; and it only takes one person to strike lucky, and alight upon the invalid part, for the wrongness to be detectable (and exhibitable to others) extremely cheaply. The news would of course then spread like wildfire. (Through Tor-like channels, if necessary in some societies.)

The consequence once the news had spread? Blocks later than the point of invalidity would then be rejected by everyone following rule-set R, even though no one of them had (within their own node) the resources to parse the whole thing from beginning to end single-handedly.

I don't know if this would meet the "self-ownership" requirements of the OP. (There might, for example, be a worry along the lines of "How do I know that this giant proof object is a proper translation of the raw blockchain, and not an imposter?". Hopefully, though, the translation process itself would be of a "wrongness is locally detectable" character.) And I wouldn't like to try and judge if this is feasible with today's proof tools - they do have a reputation for being rather slow and clumsy in their main application, proof of correctness of code (or of chip architectures). Others more knowledgeable than me might care to comment on feasibility. At any rate, I offer this idea as something for people to think about!

Your new one is definitely superior. The first thing people do with the old one is squint hard at it and try to visually read off the dates and circulation amounts at the kink-points. Your new one gives it all on a plate! Keep up the good work!

Re comparison with proof of stake: I've posted a brief overview of the economic implications of switching to proof of burn on Peter Šurda's "Economics of Bitcoin" blog. Basically it turns coin-holders into de facto shareholders in the future stream of fees (minus miners' supporting costs) - just like proof of stake does - but with the interesting extra feature that the coin-holders don't have to become miners to realise their share of these "de facto dividends". (Of course, that could be argued to have its downside - less incentive to become a miner perhaps? - but the potential upside is a really solid strengthening of the coin's value, helping make various attacks more expensive all round.)

Re the earlier work: no, I hadn't come across that, thanks for the reference to it! I've added a link to it on the Wiki page - though I do warn readers that the earlier work is of a centralised nature (the "trusted entity" business), and not directly comparable to decentralised proof-of-burn mining. But yes, it's still interesting that coin-burning was "in the ideasphere" already!

Readers of this section of the forum may be interested in my proposal for a new core mining protocol for cryptocurrency, "proof of burn" - a potential alternative to proof of work and proof of stake (though perhaps closer in spirit to the latter), with many interesting properties and economic consequences.

        https://en.bitcoin.it/wiki/Proof_of_burn

Comments and feedback welcome.

Just sent them 1BTC (plus my name in alphanumeric trailing satoshis). If ever there's a site worth donating to, it's this.

lovely!

put a donation address in your youtube blurb, and I'll pass you 1BTC!

Well! This thread has certainly got us all thinking about the robustness or lack thereof of various cryptocurrency designs! Cunicula's opening post paints (possibly provocatively or tongue-in-cheek?) a central bank's hypothetical successful 51% attack as a good thing. I think most of us on this forum would disagree. We want our cryptocurrency to stop any would-be central bank / central planner from saying "you can only spend your coins in a style approved by our macroeconomic policies". (In just the same way as we want it to stop a present or future PayPal from saying "you can only buy what we think you ought to buy, and donate to who we think you ought to donate to". - Or, more precisely, they can say it, but we can reply "we don't need you any more".)

That's what we want. How do we get it?

For attacks falling short of 51%, there's some mileage to be had in changing the "proof-of-..." choice from one thing to another. Proof-of-work, proof-of-stake, proof-of-activity... they all have interesting advantages and disadvantages and are all debated vigorously in various corners of this forum. Indeed, I'm planning to add to the list myself real soon now, with something I call "proof-of-burn". But they all crumple under a 51% attack. (That includes my proof-of-burn too! It's not immune!) So, when facing an adversary wealthy enough to acquire and use 51% of whichever "proof-of..." resource is being measured by the network - hashing work, stake, burn rate, signature activity, you name it - we need new techniques to stand up to such an attacker.

I think the good news here is that a 51% attacker's chain has to behave visibly strangely when excluding "technically fully sensible but politically unapproved" transactions, such as the "no, I'm not going to pay your coin-year-demurrage level of fees!" transactions Cunicula's example central bank would like to exclude. Such transactions sit in every node's memory pool. Then, every time any such transaction gets into a block (mined by an honest miner who's perfectly happy with its "ordinary" competitive-mining-market-clearing level of fee), the winning chain always ends up building on the previous block, orphaning the honest block and orphaning the transaction back into the memory pool. Whereas, every time no such transactions get into a block, the winning chain always ends up building on that block - it being a block produced by the 51% attacker (or by an honest miner who happens to have inadvertently followed the attacker's policy by happening not to have included those transactions for whatever mundane reason).

This behaviour is visibly strange in a statistical sense. It may not seem strange the first time, or the second time, or the tenth time, but as the politically-unapproved transactions hop in and out of everyone's memory pool more and more often, it becomes ever more absurd to ascribe their exclusion to bad luck.

(Contrast this with an attack whose motive is double-spending, rather than political control of the cryptocurrency. In the double-spending scenario, the network has no real opinion about which of the incompatible transactions ought to succeed and which ought to fail. An attacker can choose whichever one profits them and hurts the recipients[-until-later-reversed] of its double-spending sibling(s). Recipients just have to learn to wait long enough that even the attacker loses interest in further reversing their own chain - their own reversal-attack upon some earlier apparently winning chain - to that block-depth extent. But in the transaction-excluding scenario, the network's honest users do have an opinion about which treatment of the single [no double-spending siblings] transaction ought to succeed and which ought to fail. Namely: the transaction's presence is what ought to succeed, and its absence is what ought to fail!)

This visibly strange behaviour opens up the possibility of a "heuristic defence". I'm certainly not claiming I have such a defence in polished form ready to implement; but in broad outline, nodes would try to compute a "probability (or plausibility) rating" for each new block they encounter. How long has an in-again-out-again transaction been in (and out and in...) my memory pool? What fraction of my network neighbours agree it's been stuck like this for ages? (And recursively, can they report the statistics of their neighbours' opinions, in cheap aggregated form?) If it's ever more obvious that essentially the whole network knows about it, it becomes ever more ridiculous (exponentially so, I'd suspect) to believe that a whole sequence of miners can have not heard of it. Even more so, since it was sitting there inside an expensive object to produce - namely, a later-to-be-orphaned block produced by an honest miner - and a thousand websites could spring up, listing (unfakeably! the orphaned blocks are expensive things to produce!) all the transactions therein that are compatible with, but mysteriously excluded for ages by, the current winning chain.

The naive height-strength (difficulty or its proof-of-whatever equivalent) of a block would then be multiplied by that probability or plausibility rating, and it would be the sum of such plausibility-adjusted height-strengths, not the sum of the naive strengths, which would be used to judge a winning chain.

Yes, this does have the danger that different nodes would compute somewhat different plausibility ratings to multiply naive strengths by; and network consensus convergence could be placed in jeopardy if their opinions were too divergent. So, one would not want to be too eager to deprecate a block by a large factor. Still, in really extreme cases (say down into one-in-a-million territory for a transaction to have been excluded by bad luck - the power of exponential shrinkage means we get down there quite fast!), a sizeable deprecation becomes sensible (e.g. if we deprecate by the sixth root of plausibility, the attacker's blocks are deprecated by a factor of 10 in the one-in-a-million example - enough that 10% honest miners win out over a 90% attacker).

So... there's hope for us yet! Even with a billionaire central bank as adversary!

(A final note: who's running those "thousand websites" [or tor-sites... whatever] listing the suspiciously excluded transactions? Well, anyone can set one up; and serious, big full nodes, such as those run by serious professional miners, should be eager to subscribe to such sites, for a micropayment or subscription fee or the like if necessary. After all, if you're a miner, and you know that other nodes are going to deprecate your block if you don't make an effort to include that gaggle of suspiciously excluded transactions, that's a powerful incentive to keep yourself up to date with the general state of play! - And yes, we should of course aim for the network itself to achieve such functionality, without external sites' involvement. Perhaps nodes could report to their neighbours a standardised-mathematical-language set of reasons why they attached such-and-such a deprecation factor to such-and-such a block? The challenge would be to handle one's neighbours' reasons-descriptions in a way that, while stopping short of naive slavish agreement therewith, still encourages a helpful consensus to emerge.)

lol @ bubbly bubbly bubble graph on page 26

bubbles blowin' down into negative USD/BTC territory... bubbles reaching back in time just by, uh, being circular... this graph deserves a PRIZE for inscrutability