They've regrouped to BitcoinEC already though. jonald's already laying the groundwork.


I'm seeing both this and the new ECcoin hard-fork as acceptance that they're moving on, they know that the sock puppet army and VPS nodes didn't fool anyone this time either. They'll desperately cling to the falsehoods ("community is and always was in favour of blocksize hard forks" etc) they've tried to argue with, just as they've done with BU this time around


Is no-one wondering when they will stop talking softly and pull out the big stick? I expect that to happen in a way that takes everyone by surprise, prepare yourselves (yes, prepping, lol)

      ^ >>> BU >>>>>>
      ^
>>>^       Shark


It's over

Could a 1.35 wallet be converted to the 1.35c format? Just for the sake of the half length key info. Sounds like a useful change.

Right, well I hate to resurrect previous sore points, but.....


We should begin to build support for this. If every iteration requires a soft fork, then either an additional soft fork can let us wind back to 100% SHA-2 (in the perhaps unlikely event of the uncooperative ASIC miners changing their minds), or we just carry on until 100% CPU mining is back in charge.

If we do not build support before the threat of external hard fork attacks (note the plural "attacks"), I fear we may get outplayed with lateral attacks via the internet infrastructure, the legal system, the dev team, all 3, or something I'm not even considering. It should be an obvious fact that international collaboration between those perpetrating this BU attack (at a minimum between some English speaking + Chinese interests) should indicate quite how seriously the unknown opponent is taking Bitcoin.


If the most balanced way to do this is by gradation, and I believe a good case has been made for that, then waiting for an emergency to occur could well cause the strategy to invite the opponent to produce their most potent attacks to stop it. Switching to 100% CPU mining in an emergency makes sense, switching to 5% over weeks or months does not.

I'm showing my age here

Perhaps OT, but is 1.35 ok for at least a few releases? And, that's the only practical difference between 1.35 and 1.35c, right?

I prefer the Flag Day approach, precisely because of the toxic political environment you're referring to (or at least I'm calling it toxic). But it's arguably UASF in a different guise, although "user activated" is a little of a misnomer for Flag Day activation.

Maybe even this guy couldn't have predicted the 51% attack would include such an elaborate social engineering component too.

The People's Republic of China are so desperate to protect their turf, they're willing to employ some seriously complex plausible deniability, not to mention an army of English speaking trolls. Anyone would think that the PRC aren't working alone here.... but that would be craaaazzzzzzzy talk, right? Surely the Chinese, American and/or the European establishment wouldn't be working together to kill Bitcoin, right? Right?

You scale On-Chain by increasing the rate of transactions, but keeping the amount of resources (i.e. blocksize) the same. It's not my definition, it's called mathematics.


Simple examples:

Schnorr signatures

~30% smaller than the ECDSA sig scheme Bitcoin uses now. That means ~ 30% extra space in the same blocksize.

Transaction encoding

Improve transaction encoding so it's more space efficient than the current system. gmaxwell talks about the details (with links to full detals) here:  https://bitcointalk.org/index.php?topic=1700405.msg17053119#msg17053119

Bitcoin was inherently political from the original Satoshi White Paper and the Genesis Block, Satoshi concetrated on code and engineering, but that code is a political statement in it's own right


In 2008, the Bitcoin White Paper stated that Bitcoin would take back freedoms that governments were gradually removing, if only for a few years


In 2009, the Genesis Block had a now well known plaintext message encoded, partly to establish proof it was created after a certain date, but the choice of text was about the politics of money "The Times 3/1/2009 - Chancellor Approves 2nd bailout for the banks", which is an indirect condemnation of Gordon Brown's (British Chancellor at the time) actions

Ah, wasn't aware that armoryd uses a different wallet format.

A balance is indeed needed.

Bitcoin's block reward schedule, as we know, lasts until a projected year of 2140. It's impossible to remove or inhibit on-chain transactions between now and then, as miners wouldn't be able to get their Lightning channels open without availability of any on-chain transactions, and any Lightning disputes can end up kicking BTC off the Lightning network, which needs an on-chain transaction, plus another on-chain transaction if the owner of the refunded BTC wants to put that back into a new Lightning channel.

TLDR: Lightning needs on-chain capacity to work at all.


Furthermore, Lightning cannot serve high trust transactions, or apparently even high value transactions (which I only discovered today thanks to this thread and Rusty's Medium article).


So it should be obvious really that a balance between on and off chain needs to be nurtured, yet I've never heard anyone say "let's move every transaction onto the Lightning network". I've heard scare stories like that though.

What will prevent the SHA256 miners orphaning the new hashing algo blocks? Would it not be better to start at 51% share to the new hash algo to prevent that, or would an exponential rise in blocks built on using the the new hash algo as it approaches 51% of the hashrate be acceptable?

No they haven't.


Users were given the opportunity to support the XT and Classic blocksize forks. And users didn't want that, both were rejected by users.

Creating an echo chamber of sock puppets is not a real majority, jonald




Your opinion is wrong, and so is that of the bigger blocks miners.


If transaction rate increases 1:1 with blocksize increases, that's not scaling by definition. You cannot refute this, because it's an unimpeachable fact

That's the maximum per transaction, not the fee

Did you not read the article?

Indeed.

And has the BU testnet simulated it's (now confirmed) intention to re-org/orphan attack the Bitcoin blockchain? I wonder why not

Fixed that for you, Andreas. Strong argument is now stronger


Think about it another way: "Can there ever be justice on stolen land?" KRS-One, The Sound of the Police

It would be there, if you're doing it right. You must be doing something wrong. "Print Paper Backup" is a very simple, long-term stable function in Armory, and it's very diffcult to get it wrong.

Explain in exhaustive detail exactly what you're doing to achieve the failure.

Been trying to explain this for months, but it gets drowned out in a sea of "you want mining to die, LN to send all transactions and centralise Bitcoin"

And you've been no help at all, d5000. But in fairness, I had no idea a cap on Lightning transaction amounts was being touted.



I hope you are also going to begin to understand that shrinking transactions is the only scaling paradigm possible (whereas you've been another voice in the crowd shouting about the un-scalable blocksize increase paradigm).



Changing to Schnorr signatures (instead of the current ECDSA sigs) and changing to a more efficient transaction encoding scheme could turn 300,000 tx/day into 400,000 tx/day on-chain. More can be done, there's plenty of true on-chain scaling ideas on the shelf.

That's the responsible way to do it, we can think about doing the high-wire dangerous blocksize increases once there's actually a safety net to break any falls.

The second key on your paper wallet backup is headed with the word "Chain Code". That key is the Chain Code, or extended public key in the BIP32 parlance.