Not so "automatically".  The reason why the devs like soft forks is that they can deploy the protocol changes without having to alert everybody to upgrade (and therefore to explain *why* the change is good for them).


What I meant is that big junk generating businesses can upgrade to exploit SW immediately, while the majority of the occasional clients will take months to do so.


Phew, for a moment I was afraid that Blockstream had relented and proposed SW as a way to increase the capacity and avoid congestion.  But with users inertia and a bit of help from junk generators, the "fee market" may still begin in six months or so. 

So everything is back to the status quo in diebus bello, and the Bitcoin Stalling Conference had the outcome that everybody expected.   

You seem to be assuming that the "fee market" will set in and space in blocks will be a scarce resource.  But, if a sizable fraction of the traffic adopts SW, the fee market will be delayed by another 2 years at least.  Large junk traffic generators like SatoshiDice can avoid paying higher fees by using the SW format, while miners and full non-mining nodes will see their bandwidth demands increase beyond the 1 MB mark, just as if the block size limit had been raised to 4 MB right now.

Yeah, having been called an idiot/troll/shill by the "1 MB is sacred" crowd for months did spoil my academic detachment, I confess. 

Will they? Miners still have to process and transmit the full data if they are to really validate the transactions that they mine.  The space and bandwidth savings will be realized only by simple clients and nodes who do not need to validate the signatures.  So why would the miners give discounts for transactions in the SW format?


IIUC, segregated witnesses requires a different signature format (achieved through a scripting hack to avoid hard forks) whereby the signatures are moved out of the tx body and are not included in the tx hash.  That allows the signatures to be sent and stored separately.  Regular transactions will still have to be stored in full in the blocks.  Wallets willnot be issuing SW trasactions until they upgrade, and (since it will be a soft fork) they will not be required to.

So, all that "concern trolling" about the terrible consequences of large blocks by Adam, Greg, and the rest of the Blockstream/Viacoin crowd was just bullshit, and they kew it. Segregated Witness will allow 4-5 MB blocks "soon"(because they will not wait for consensus, of course, but intend to deploy it in "stealth mode", aka "soft fork ).  And they are all euphoric about it.  

I wonder how the small-blockians who sincerely believed that bullshit are feeling now.  Betrayed and duped? Probably not: like that speaker from 1984, they will swicth in mid-sentence from "blocks larger than 1 MB will kill bitcoin" to "4 MB blocks are wonderful".  From "we need the fee market to support miners and push traffic to off-chain solutions" to "segregated witnesses is essential to let bitcoin to grow without running into saturation".

To be sure, Blockstreamers only now are coming to realize that an increase of the effective block size limit to 4 MB will have the unexpected and unwelcome consequence of increasing the effective block size limit to 4 MB.  So Luke has already proposed to keep the 1 MB limit for the total block size, including the segregated part. And Greg, in his characteristic straightforward and honest manner, has proposed to combine SW with Adam's 2-4-8 block size limit plan, but "scaled for the effect of segregated witnesses" -- which must mean setting the nominal block size limit to 0.5-1-2 MB.

But they should not worry, since the space savings will only occur if the clients start issuing transactions in the new SW format.  Which will not happen right away, if SW is deployed by soft fork.  And even after the clients have upgraded, the use of SW will be optional.  Will there be incentives for the clients to use it?

Are you worried that he may be haw?

When F2Pool "steals" the hash of B(N) from Kano in advance of the ful B(N), it can start mining an empty block B(N+1) on top of it, right away.  The head start gives F2Pool a greater chance to solve B(N+1), which protects B(N) against orphaning.

If Kano did not let F2pool get the hash of his B(N) in advance, some other miner might succeed in sending an alternative B1(N) to F2pool before Kano sends the full B(N). Then F2Pool would mine his B(N+1) on top or B1(N), rather than B(N); and so B(N) would run an increased risk of being orphaned by B1(N).

Therfore, it is in the interest of both pools to ensure that F2pool (and all other major pools) gets the hash as quicky as possible, and starts mining an empty block on top of it, without waiting to get the full B(N). 

It is in the interest of F2pool (but not of Kano) to download the full B(N) and replace his empty B(N+1) by a full one -- but only because of the tx fees.  If F2pool fails to do that, it is actually slightly better for all the other miners, because they will have a chance to get the tx fees that F2pool failed to get.

No contest about DoS threats.  But that point is not related to bitcoin. DoS is a violation of general *laws* that govern use of the *internet* -- so it can be objectively said to be wrong, and the victims have the right to seek appropriate legal action.

"Mining" while withholding (whatever that means) is fair game.  Once again, bitcoin cannot depend on miners being pressured to act "failrly" in any sense.  The design *assumes*  that they will do whatever is best for them; an that is what is notable about it.  The protocol does not even assume that they are holding their bitcoins, or that they care about what will happen to the price after their current equipment becomes junk.

Ditto for lying (*).  While no one likes liars, there is no law against lying per se, and -- once more -- bitcoin cannot depend on miners being honest.  Indeed, it assumes that miners will tell lies, if that helps their bottom line.

(*) What "lies" are you referring to? The fact that they put "v3" on their headers? That was not a lie.  Something else?

Even Greg, who coined the term "SPV mining", admitted that it was a bad name.  There are three things that go by that name:

• (A) The miner starts to mine an empty block B(N+1) as soon as it gets hold of the hash of B(N), before it has got the full B(N); and publishes that empty B(N+1) if he solves it before getting the full B(N).
• (A2) The miner does (A) even when he notices that B(N) was itself empty, because the other miner was doing (A) too.
  
• (B) The miner does not bother to dowload and check the full B(N) at all, once it got its hash.

Miners will do (A) and (A2) if they can, because the alternative is to let their equipment sit idle or turned off in the interval between receiving the hash of B(N) and the full B(N).  If that turns out to be bad for bitcoin, that is a flaw of the protocol; the miner is not to blame, because he was supposed to be greedy and do what is best for him.

(The protocol could be changed to prevent (A) and force the miners to wait for the full B(N); but then the useful hashpower would be less than the installed hashpower, so it is not clear that it would be better for the coin.)  

Item (A) is not an entirely bad thing, because the empty B(N+1) will still help secure B(N) against tampering.  The miner who mined B(N) *wants* to give its hash to all other miners, as quickly as possible, and *wants* them to do (A), because it helps secure his gain against orphaning.  Every miner *wants* to get the hash of other miners' blocks as soon as possible, and do (A).  

Item (A) is usually pretty safe for bitcoin, as well as for the miner of B(N+1), if he knows that the solver of B(N) is a known real pool: because that pool will lose lots of money and reputation if he sends a bogus hash out to its members.  Choosing to do (A) is a calculated risk by the miner, with a clearly positive expected payoff.  Last July (and in no other occasion that I know of) item (A) failed by magnifying the mistake of BTCNuggets from 1 block to 6 blocks, thus causing monetary loss to F2Pool and AntPool in addition to the loss suffered by BTCNugets.

Perhaps pools will modify their implementation of item (A) now that they know that the probability of other miners issuing invalid blocks is not negligible.  In hindsight, the Fork of July could have been just one or two v2 orphans, rather than a 6-block chain, if the miners had refrained from doing (A) or just (A2), for a couple of weeks around the BIP66 switch-on event; that would have avoided the loss incurred by F2Pool and Antpool (but not the loss of BTCNuggets).

As for item (B), it should not be in the miner's interest to do that, so there should be no need to nag those who do it.  But the expected loss from doing (B) is basically the transaction fees, so it is a weak deterrent.  That is a fault of the protocol and of whoever set the minimum fee so low -- not of the miners.

However, I recall that F2Pool admitted to be doing (B) in July.  They claimed that they had decided to do (B) after having one of their blocks orphaned.  I do not quite understand that excuse; but, anyway, they promised to stop doing (B).  But they also said that they would continue doing (A), for the reason above.  You cannot blame them for that decision.


Failing to check the version number of B(N) was F2Pool's mistake, but that did not happen because they were doing (A).  They easily could (and should) have checked the version when doing (A).  They did not bother to check it because they did not foresee the risk of other pools continuing to mine v2 blocks past the fork.  

That check would not have prevented Antpool from extending the wrong branch, because they mined on top of a v3 block header.  


Maybe not 5%, but the percentage of v2 miners was high enough for a v2 block to be issued just after the fork.

Why is everybody blaming F2pool for mining an empty block on top of that one, and no one is blaming BTCNuggets (and the other miner who did the same 20 hours later) for having produced that block in the first place?


Wait, you are not saying that there was plenty of time for 100% of the nodes to be among the first 95% to upgrade, are you?  

That is true.  However, to kill that "trash", it would be much better to just raise the minimum fee.  It would be a "centralized decision", true, but so is imposing an arbitrary size limit.


When the 1 MB limit was introduced in 2010, it was 100x the average block size at the time.  Until the "stress tests" of June 2015, there has been no "bloat-attack-vector": no one tried to create 1 MB blocks, not even in 2010 when they would have been more damaging than 8 MB blocks would be today. 

Quite probably, the stress tests would not have happened if the limit had been raised to 8 MB two years ago.  The stated goal of the first test was to create a 200 MB backlog of unprocessed transactions.  That was easy, because the clearance between the normal traffic (0.5 MB/block) and the effective capacity of the network (0.8 MB/block) was very small, so the "tester" only needed to issue more than 0.3 MB of transactions every 10 minutes to start building the backlog.  If the limit was 8 MB, the effective capacity may have been at least 6 MB/block, so the tester would have had to issue 5.5 MB every 10 minutes -- more than 15 times.

For the same reason, the 1 MB limit makes a real spam attack (with dynamic fees) much more likely, because it makes it much cheaper and easier to carry out.


Centralization of mining is one of the few real flaws of the protocol, that will require another genius idea to solve.  The "full but non-mining" nodes are a hack that attempts to get around to that problem.  However, they violate the spirit of bitcoin, they will not protect bitcoin from a miner cartel, and they will disappear anyway, because they are not rewarded (and they are not rewarded because they did not exist in Satoshi's design).

Sorry, but you got it wrong.  


And that is the point: miners should avoid those things because they are bad for them, not because they are bad for bitcoin.  

That is why it took 20 years to invent bitcoin.  If one could assume that the players would be good citizens who followed the rules, either to go to heaven or because of community pressure, bitcoin would have been invented 25 years ago.  If a misbehaving miner is hurting bitcoin, that is a flaw of bitcoin -- because its essential property, that made it the solution to the distributed ledger problem, is that it does not depend on miners being "good", only on a majority of them being "greedy".


You missed the point completely.  Miners were upgrading their code from v2 to v3.  Since the BIP66 change was programmed to be enabled immediately once 95% of was running v3, at that moment inevitably there would be 5% of the miners still running v2.  

A grace period of (say) 2 weeks after reaching the voting threshold would have allowed warnings to be sent out, and then those remaining 5% would have convert too -- because otherwise they would be wasting their work.  But the devs opted for zero grace period and zero warnings, thus ensuring that some miners -- those who were last to upgrade -- would issue invalid blocks and waste their work.  

Specifically, the 6-block bad branch started when BTCNuggets mined the v2 block after the forking block: not by their choice, not because F2Pool was SPV mining, but because the devs bungled it (and did not even apologize).

(Please don't tell me that the miners should have updated more promptly, so that 100% of them should have been among the first 95% to upgrade.)

Adam floated that 2-4-8 proposal a few months ago.  Sorry, but I can't believe that it is a sincere proposal. 

AFAIK, that proposal has no implementation yet, not even a BIP. (There are only two proposals with implementations: Gavin's BIP101 and my BIP99½  ).

I strongly suspect that Adam does not have any intention of implementing that plan, certainly not before the network gets saturated.  I believe that he made that proposal only to pretend that he is a reasonable guy, and to steal support from BIP101.

If the 2-4-8 plan were implemented in time, there would be no "fee market".  Then all those small-blockians who are impatient to see the fee market in action would be protesting loudly.  Why aren't they?  Perhaps because they too sense that Adam does not really mean it?

That is what I wrote.

Surely the SPV mining pools will want to do that, then, if it works.  If it is in their interest to do so...

The bitcoin protocol was meant to work if each miner did whatever was more profitable for him.  If it is necessary for the miners to be "good citizens", then the protocol has faied.  In this case, I do not think it has: empty blocks are not a problem, just a normal consequence of other problems (such as limited bandwidth and excessive block reward).


I insist, it was not their fault, but the fault of the devs who programmed BIP66 to be enabled immediately when 95% of the miners had updated, with no grace period -- thus ensuring that 5% of the hashpower would still be using the wrong rules at the fork time, no matter how quickly they tried to update. 

That 5% of the hashpower would have been wasted anyway, even if the SPV miners had not mined empty blocks on top of that bad one.


One does not need to play football to know exactly where the coach went wrong. 

Do you get a free serving of kevin bacon if you buy any hot dog?

The Bitcoinwisdom developer has not logged into bitcointalk.org since Aug/2015.

In one of his last messages, he says that he has been working on a complete rewrite of the tool.  I know, from bitter experience, the danger of such attempts.  I hope he survives...

They have no use for bitcoin or any other cryptocurrencies. If they had, they would use some closed centralized "currency" like Ripple.

The bitcoin blockchain is a lousy and terribly inefficient data structure.  It is used in bitcoin because it was the only structure that Satoshi could think of that prevented double-spend and could be reliably maintained by a distributed swarm of uncoordinated anonymous volunteer miners.  The bitcoin system uses the bitcoin currency to motivate those volunteers, through fees and block rewards, because it has no other way of rewarding them.  However, the banks will hardly want to use uncoordinated anonymous volunteers to process their billion-dollar transactions. So they will not need bitcoin to reward them. So, after the hype deflates, they will realize that there are better data structures and protocols for their problems -- and that they are already using them.

The badly named "SPV mining" is not that bad for bitcoin.  In fact it is better than the alternative

• An empty block buries the earlier ones under a chunk of hashwork, and thus helps secure them against tampering, just as well as a non-empty one.
• You *want* other pools to do SPV mining on top of your blocks, to reduce *your* orphan rate.
• You *want* to do SPV mining yourself when you learn that someone else just mined a block B(N).  The alternatives are (a) keep mining your own version B'(N) of the same block, in the hope of solving it just a few seconds later and getting it accepted by the network in place of your rival's; or (b) keep your equipment idle, or turned off, while you wait to downlad and verify that full B(N).  In both cases you will be hurting yourself, your member miners, and ultimately the network (by wasting some of your hashpower).
• SPV mining is not particularly unsafe, because the pools have no interest in broadcasting bad blocks to their members.  The pools who do SPV mining are making a calculated bet, based on the trust that their peers deserve, and will be punished if they trust a parent that turns out to be invalid.  (The "Fork of July" that followed the activation of BIP66 was the fault of the Core devs, who tried to do a stealth change in the protocol and bungled it.)
• SPV mininng does not really reduce the capacity of the network. Rather, it is a consequence of the limited bandwidth available for block propagation.  If SPV mining was suppressed somehow, instead of empty blocks there would be longer interblock delays and/or a reduction of the effective total hashpower compared to the total available hashpower. The empty blocks are just an embarrassing symptom of the limited capacity

Think of the miners as producers of a continuous stream of hashwork, like toothpaste squeezed out of a tube -- the blockchain -- with transactions being secured by being embedded in that stream.  Empty blocks are a length of that stream  that gets appended to the blockchain with no transactions embedded in it. If SPV mining were suppressed, in an attempt to fit more transactions in the stream, one would simply get a reduced hashwork output (because of longer block waits and/or lower difficulty setting).  So the max transactions *per unit of hashwork added to the blockchain* would be the same.

SPV mining could be suppressed by a protocol change, if desired: make the Merkle link (block hash) from block B(N) to B(N-1) depend on the contents of both blocks, instead of being just the hash of B(N-1); in such a way that the link cannot be computed by the miner that sets out to mine B(N) without knowing the full contents of B(N-1).  But that would probably not increase the effective capacity of the network, as said above.

I find it hard to imagine a motivation for someone to set up such a site other than building a file of passwords that are good candidates to brute force...

Since 2015-11-25, when the daily volume at OKCoin and Huobi jumped to a new level,  there seem to be a relatively sharp daily spike in volume. In the 1h chart, those spikes stand out quite clearly, often 50%-100% higher than the adjacent bars.  Yesterday's peak at OKCoin was ~350 kBTC in one hour, which used to to be a large number for the daily volume until a couple of months ago.  

These sharp daily spikes apparently started in Sep/2015, with the start of the exponential mini-rally that peaked on 2015-11-03.  Curiously the time of the spikes seems to be drifting.  At OKCoin (UTC times):

2015-11-25 11:00
2015-11-26 03:00
2015-11-26 12:00
2015-11-27 03:00
2015-11-28 05:00
2015-11-29 08:00
2015-11-30 09:00
2015-12-01 10:00
2015-12-02 12:00

China local time is UTC plus 8 hours, so the local times range from 11 am to 8 pm.