Ding!  We have a winner. 

Joe S. Campbell, however, would have a drastically changed life, starting with harassment by the IRS, the Mafia, the Paparazzi, and every other kind of parasite attracted by money or fame.  It would kind of suck to be him in that case.

Oh, wow.  That does take me back.  I think I remember seeing your posts.  My handle back in the day was "Electric Bear".  This is kind of like meeting someone from your tiny boondocks hometown, decades later in a big city.  Weird... 

Y'all are acting like one of my college roommates, who, when he got drunk enough, liked to sniff root beer because it made him see a beautiful purple color so bright and vivid  that it could never exist in the real world.   He spent weeks, when sober, looking for paint that reproduced that impossible color, trying to find the HTML hex code for it, etc.  But there was never anything that satisfied him, because "root beer purple" was always brighter and more vivid and more dynamic than anything found in the real world. 

The idea that Satoshi "is" someone is like the idea that the scent of root beer has a color.  A compelling illusion if you're drunk, but otherwise a waste of time.  A 'nym which has been used, successfully, without leaving traceable evidence, remains sealed forever. 

The person who invented Satoshi has probably sealed the 'nym, and deleted all the keys when the need for Satoshi was over.  If so, then nobody - not even him - will ever have any evidence to tie that 'nym to anyone's identity. 

And therefore, there is no such identity. 

You're astute.  Bitcoin is still a fiat currency: it has value by User fiat rather than by Government fiat. 

It looks to me like someone is testing the market's ability to absorb and recover from higher-volume purchases and trades. 

The experiment, I guess, shows that there is a lot of "latent" supply/demand out there that doesn't show in the open-orders of the exchanges.  The Bitcoin market is apparently deeper than it appears just by looking at the exchanges open orders.  It's confirming something that was shown by the "bearwhale" episode, but it's being done a lot more carefully.

Every asset has an asset-to-market ratio - some percentage of the total amount of the asset is on the market (with a sell order or at least a stop-loss at some price point) at some price.  When a derivative market gets overextended, the asset-to-market ratio can even get higher than 1 to 1. 

Bitcoin appears to have a considerably lower than average asset-to-market ratio. The asset is owned by people who might be willing to trade it tomorrow or the next day or the day after that but who are, more often than with most assets, not represented at a given moment by any corresponding open sell orders on the books at the markets -- not even at very high prices.  Conversely, there are a lot of people who might buy it tomorrow or the next day or the day after that, whose interests are not represented by open buy orders in the markets, even buy orders at very low prices. 

This is "noise" rather than "signal" to long-term investors, but is crucial information to someone who is getting ready to manipulate the market, getting ready to open a new market, or getting ready to start a new trading pattern that the market would respond to differently depending on its actual depth.   

Hmmm.....  still interesting, still don't know what's really happening.  Time to make more popcorn. 

No, not quite a mechanical-turkism although it might as well be as far as the present discussion is concerned.

I sort of get it, but Traincarswreck is thinking at right angles to what the rest of us consider relevant, and writing for an audience of lurkers, monitors, eavesdroppers, or historians who are or will be reading this thread for other purposes, rather than writing to be read and responded to by any of us who are actually participating in realtime.  

As to whether the communication will be or is considered meaningful by any such audience, I'm confident that 95% of them will have roughly the same opinion of Traincarswreck's relevance as 99.8% of us.  Traincarswreck is hoping that the 5% of unseen listeners with the greatest insight into his (or her, or their) posts will also be the most influential in their respective spheres.  Which I'd consider to be unwarranted optimism on his (or her, or their) part, but he's entitled to hope.

I could try to explain further, but there's at least a 75% chance I'd be wrong about the objectives, intended audiences, and means.  Besides I don't think I care enough.  

Cryddit

Note:  All statistics and percentages given in this post are estimates and guesses which exist in the absence of measurement and proof.  In other words, I'm just guessing.

Even after a new version of the software containing a hard fork is deployed, the new protocol does not actually go into effect (the hard fork does not actually happen) until more than 95% of the hashing power is ready to go onto the new protocol.  

That leaves less than 5% of the hashing power on the old protocol, meaning a new block on the old protocol could be found less than once every 3 hours.  Because that's clearly a loss and a failure, at least 90% of the remaining people would abandon it immediately, leaving it getting one block about every 33 hours.  Making it even more a loss and a failure, but assuming that last half-percent of the hashing power can be an irrational lunatic fringe who never ever leave, then with that amount of constant hashing power....  

The transaction rate on the old chain is one transaction per 86 seconds.  

Most transactions never get into a block on the old chain, because the blocks are only 1MByte and only happen once per 33 hours.  

If a transaction does happen to get into a block on the old chain, it will be ten days before it gets to confirmation depth.

A coinbase from finding a block on the old chain would take four and a half months to become spendable.

And 2016 blocks, which is the time between difficulty adjustments, flies by in just seven years and eight months.  The maximum adjustment an unforked bitcoin will allow is for the block speed to quadruple.  Therefore the time to each new difficulty adjustment is a quarter the time needed for the previous one.  Again assuming hashing power stays constant, which it won't:

You spend seven and two-thirds years getting blocks once per 33 hours.      (1 tx per ~86 seconds)
You spend a year and nine-tenths getting blocks once every 8 1/3 hours.        (1 tx per ~21 seconds)
You spend five months and 20 days getting blocks once every 2 1/12 hours.   (1 tx per ~5 seconds)
You spend a month and twelve days getting blocks once every half-hour.         (1 tx per second)

And after that difficulty adjustment works "normally".  It takes ten years to get back to handling 1 tx per second.

Heh.  It would be a good idea, for example, to add code that sweeps "dust" more than 8 years old (ie, starting with the very oldest dust, at the beginning of next year) into the miners' pockets.  If something has been sitting there for 8 years and it's too small to pay for the fees that would be needed to spend it, then it's useless to its present owner, burdensome to the whole network to keep track of, and ought to be aggregated and paid to miners for network security. 

But if you think the blocksize discussion is contentious?  Sweeping dust would make the ultraconservatives and ultralibertarians here absolutely foam at the mouth.  I'll not even suggest such a thing because the discussion would go absolutely off the rails.

I'd cheerfully go even further and "sweep" *any* output that's been sitting there for >20 years (ie, lost keys) into a "mining fund," then have the coinbase of each block take 0.001% of the current mining fund balance in addition to the block subsidy.  Anybody whose keys aren't actually lost can avoid the haircut by moving her funds from one pocket to another in a self-to-self transaction.

No.  You won't get side-chains if you stay on the 1MB block chain, because the 1MB block chain will not move fast enough to support them.  If anyone at all stays with a 1MB block chain after the fork, then either they will have to have another hard fork to reset the difficulty, or they'll have to adapt and cope with a chain that gets a block less often than once per day.  It would be at least a decade and more probably a lifetime before that network recovered to the extent of being able to handle even one transaction per second. 

It will be quite amazing if enough people stick to it for long enough that even one of its coinbases matures and becomes spendable.  That will take at least four months, but is likely not to happen at all unless there are a whole lot of people with a whole lot of hashing power who don't care about making coins on the main branch of the fork.   I am tempted to maintain a pre-fork full node just out of morbid curiosity, but it would be madness to devote resources to mining it.

Cryddit

Why would client B do that?  The point of the change is increasing the maximum tx per hour, and rejecting blocks for being small would do nothing toward accomplishing that goal.  Further, there's code (in bitcoin main.cpp), specifically to prevent this from happening.  It ensures that there is no rejection of blocks for using old protocol, until 95%+ of the hashing power (as seen from protocol-version headers in the block chain's last thousand blocks) is ready to go on the new protocol.  


Diverge?  No, they won't.  Nobody will ever have a spendable version-A coin after the fork.  You have to remember the 95% rule about the way hard forks actually get rolled out.  No block that violates the A-version protocol (ie, no >1Mb block) will be produced by a B-client miner, until it reads in the protocol version headers of the last thousand blocks that 95% of them have been produced by miners that are ready to understand and mine new blocks in the B-version protocol.    Until that time, Client-B's will continue to read, accept, and extend version-A blocks.  

So there IS no block that an A-version client will reject, until 95% plus of the mining power is mining the B-version protocol.  There can be no transaction that an A-version client would reject, until 100 blocks later when the coinbase from the first version-B block matures.  

To the extent that chain-A continues at all after that point, it has to do so with less than 5% of the hashing power.  That means it has no credibility, so I expect that it will cease to exist entirely rather than diverging.  But if it doesn't cease to exist entirely, it still won't be moving fast enough for there to be "taint" and "divergence."

Assume for amusement that, of that last five percent that hung on with client-A until the 95% majority actually pulled the trigger, one in ten continue to hang on to the old chain.  This won't happen because the old chain will be horribly crippled at that point, but assume that it does.  What have these people got to look forward to?  

With one half of one percent of the hashing power, you get one <1Mb block every 33 hours.  That means your maximum transaction rate is under one per minute, so if anybody is actually trying to make transactions, odds are most of them never get into a version-A block.  They're all acceptable transactions in the version-B chain though, so they get accepted and processed there immediately.  If someone mining the version-A protocol does pick them up,  the confirmation time until that block is in a chain six deep is about a week and a half.  And your chain-A coinbase outputs, which you're counting on to "taint" transactions?  Good luck with that, it'll take four and a half months for them to get the 100 blocks deep that will make them spendable.  

You really think anybody's going to hang around a block chain that crippled, for four and a half months, while all their transactions are getting accepted, processed, and confirmed by the new chain?  While they can't even MAKE a transaction that won't be legitimate w/r/t the new chain?   Hint:  They won't.  Nobody will ever have a spendable chain-A coinbase coin after the hardfork.   Nobody will ever be able to make a transaction that is acceptable to chain A but not to chain B.  

Oh, but, you say, a difficulty adjustment might make it better?  Difficulty adjustments happen every 2016 blocks in Bitcoin - meaning, if chain-A somehow keeps half of one percent of the hashing power, which it won't, about once in seven and a half years.  Nobody's going to stick it out.
  

To start with, B will never deploy with 2% of hashing power.  It will deploy with AT LEAST 95% of the hashing power.  If less than 95% of the miners are mining blocks and putting protocol-version B into the block headers, the fork never happens.    No block not acceptable to protocol version A will ever be produced until the mining client-B sees that 95% of the last thousand blocks are from miners ready to go with protocol version B.    

And that leaves people mining protocol version A With <5% of the hashing power AND <1MB blocks.  Protocol version A will be unable to handle any transaction load at all.

Okay, a lot of people appear to be talking without knowledge of how hard forks actually happen. 

The process starts with miners getting mining software that will understand and could produce blocks on the new version.  They start putting the new protocol version number into the blocks.  But they continue to produce blocks that follow the old protocol until the last 1000 blocks are 95% produced by miners that are putting the new protocol version into the blocks.  After that, the hard fork is enforced.  Two things happen;  they start using the new protocol, and they start rejecting any new blocks that have the earlier protocol number.   

Meanwhile, when the number of recently mined blocks showing a higher version number rises above 50%, any client with the old version will warn that it's on the losing side of an upcoming hard fork and a software update is required.

Here is an interesting thing about this split in particular; even when 95% of the miners start rejecting blocks for having too low a version number, there may not be an immediate split.  If this happens while we aren't bumping up against the 1MB limit, then the earlier clients will see nothing in the first few of the new blocks to object to, because all the new blocks (until a >1Mb block actually happens) are still acceptable to the existing clients.  So, until that time all that happens, from the point of view of the original clients, is that blocks bearing the original version number are getting orphaned by blocks bearing the new version number.

So any original-version blocks created during this time wouldn't wind up in their own block chain, they'd just get rejected, by the new clients for having too low a version number and by the original clients for having another perfectly-acceptable block chain get longer.  Even though the hard fork is being "enforced" by the new clients, it hasn't happened yet as long as the new blocks are acceptable to the old clients.  So any original-version blocks mined during this time are a dead loss for miners, regardless of which side of the hard fork they intend to be on.  Rather than mining at a dead loss, I expect that miners who haven't upgraded yet, mostly will. 

But after a while, a >1Mb block arrives, and the new version clients will build on it and the old version won't, so the hard fork actually happens.  Now the miners have a choice.  They could choose to mine on the new version or the old version.  Let's stack this up for a minute and see what the choice looks like.

The old version has already lost 95% of the hashing power before the new-version clients pulled the trigger by starting to reject old-version blocks.  Also probably lost at least 90% of whatever was left because miners don't like mining at a dead loss, so let's say they've got about one half of one percent of the hashing power.  That means they'd get a block about once per 33 hours.  A one-megabyte block every 33 hours.  Meaning, a limit of 1 transaction per 86 seconds.  Your transaction gets into a block in 33 hours, and it takes about ten days to get to the confirmation depth of 6 blocks.  If you get a coinbase transaction, good luck waiting out that 100 block depth until it's spendable.  It'll take over four and a half months.  Oh, but of course there are difficulty adjustments to make everything work right!  There sure are, every 2016 blocks.   Assuming you still have miners for that long, that takes over seven and a half years.  Taking the maximum reduction that the protocol can take, that'll quadruple the rate at which you get blocks. then you get up to 1 transaction per 21 seconds and you get another difficulty adjustment in 2 years, and another one six months after that, and another one just a month and a half later.  So we're up to about ten years later before the original chain gets back up close to one transaction per second.  This does not sound like a winner to me.

Meanwhile the new version takes off with 99.5% of the hashing power, and essentially flicks whatever holdouts and weirdos stick on the old chain off like an elephant shakes off a fly.  They are able to take 40 or so transactions per second, and the old-version chain, with its smaller crop of miners, is limited to less than one transaction per minute.

Seriously?  Seriously, you think staying on the original-version chain is a viable choice?  I invite you to do so; the rest of us will ignore you, except for the ones that care enough about your welfare to stage an intervention and tell you you're crazy and you need to get help.

You realize that no 'breaker' block (that is, no chain-B-only coinbase) will exist until after chain-B has 95% of the hashing power, and that because the vast majority of people still on A at that time will be there only by accident, that'll rapidly rise to 99%plus of the hashing power.  

That leaves a post-fork chain-A getting, at best, one block a day.  One <1MB block.  Giving chain-A a transaction rate, until the next difficulty adjustment, of maybe 1 transaction per minute, with 1-week confirmation times.   Difficulty adjusts every 2016 blocks, which, if you get it right on the cusp of a diff adjustment and actually manage to keep 1/2% of miners on it, which you won't, means chain-A will be like that for ten years.  

You're pointing a BB gun at an elephant here, and the BB gun isn't even loaded.  

Ah.  You then are one of the people I was referring to as a crook, and want to do double spends.


Except that coinbase from B can't exist until B has majority hashing power.  Any block that would produce a 'B-only' coinbase will have to violate protocol-A (be over 1M bytes long) AND be 100 blocks old before that coinbase can be spent.  Because client-A won't mine on any chain containing a block that violates protocol-A,  unless B has majority hashing power that B-only block will be orphaned long before then.   Further, because no miner will even attempt to produce a client-B block until incremented block version numbers in the recently-mined blocks indicate that B has an overwhelming supermajority of hashing power, there simply won't exist a >1Mb block, or any opportunity to "taint",  until that happens.

I'm looking right at the code, and, no.  Client B will not be locked to chains containing at least one >1MB block; it will continue to accept any block that meets client-B protocol - which includes all client-A blocks, even if a client-B block gets orphaned.  

Likewise Client-A will continue to accept blocks that meet client-A protocol, even if they originate with client-B miners and arrive with an unfamiliar block version number.

Incrementing version numbers in the blocks is invisible at first; miners will start putting client-B version numbers into the blocks they mine while continuing to follow the client-A protocol rules.  The new blocks will be accepted both by Client-A's and Client-B's, and all the Client-B's will keep track of how often new-version blocks have been mined.  Client-B's will not actually create new blocks using protocol rules that client-A will reject until such time as mined blocks with client-B's new version number constitute a supermajority of the blocks recently mined (meaning protocol-B is now supported by the overwhelming majority of hashing power).

Spotting incremented block version numbers in the blockchain will cause client-A to pop up version incompatibility warnings, of increasing severity.  The appearance of an incremented version number that makes it into the blockchain will cause client-A to pop up a warning that a newer version of the software is in use and the user should upgrade.  When the new version constitutes 20% of recently-mined blocks, another version warning pops up.  When the new version number constitutes a majority of recently mined blocks, client-A will pop up a more dire version warning verging on panicky, stating that there is a new block protocol which will definitely cause a hard fork, and that failure to update the software immediately risks being on the losing side of an orphaned chain.   When the supermajority criteria for client-B blocks to actually start issuing is met, Client-A will issue a final version warning stating that a hard fork is imminent and it is definitely on the losing side.  When client-A actually finds itself on the losing side of a forked chain, probably within hours after that, Client-A will see a blockchain that contains blocks it cannot accept, with a different version number, which is getting a huge amount of hashing power.  It will put up a "we appear to be on the losing side of a hard fork, any transactions you make now will not be accepted as valid by the main blockchain, please update your software to get back on the main chain." dialog.  

So....  First, I have no idea where this "bounty" comes from.  Who would pay it and why?  Second, it'll be an orphaned block unless the majority of hash power is already on the B version, so where could a 'taint' come from anyway?  Unless the majority of hashing power accepts that block as valid, the chain it's in will be orphaned long before its coinbase can be spent, and if it's orphaned none of the other clients are going to accept that block as evidence that a transaction has happened, so they'll just ignore it, repeat its transactions in <1Mb blocks, and the world goes on.

I think maybe you believe that someone has motivations they don't have.

The squaring bug isn't a concern for Bitcoin.  We're moving away from OpenSSL for a different reason.  The purpose for which OpenSSL is implemented and maintained is not precisely the purpose for which Bitcoin was using it, and for their purposes they are free to "fix" things in a way that would result in a failure for Bitcoin. 

Before this change, we were using OpenSSL to check the validity of the crypto in encrypted blocks already in the blockchain - blocks that had been transmitted and accepted months or even years previously.  OpenSSL's purpose is in securing communications today, this hour, this minute. 

When encrypted data can appear in any of multiple possible formats, it can lead to different signatures for the "same" data.  This is a problem which could lead to some protocols leaking information, transmitting things redundantly, or letting an attacker see the same payload encrypted by closely-related keys, etc. 

OpenSSL responded to a perceived possible vulnerability that allowed things to appear in either of multiple formats  by first issuing a version of OpenSSL that would only produce a single format, then followed it up 2 months or so later with a version of OpenSSL that would reject all other formats as incorrect.  This is completely in accord with their purpose, and makes a bunch of protocols more secure.  But it didn't work for the Bitcoin protocol.

We have blocks in our blockchain, that have already been accepted, which used one or more of those other formats.  This caused Bitcoin clients which were dynamically linking against the OpenSSL library (ie, which used the latest version of OpenSSL installed on the machine) to decide that we had invalid blocks in our blockchain. 

Most people weren't affected because the downloadable executable was statically linked with an earlier OpenSSL (ie, they used a version of OpenSSL that was guaranteed not to change, but which therefore also wasn't getting updates and bugfixes) so it wasn't affected by the change.  People like me, who compiled from source and linked OpenSSL dynamically rather than statically, had to upgrade our Bitcoin clients before we upgraded our OpenSSL. 

Having had our noses rubbed in the mismatch between OpenSSL's purpose and our requirements, we realized that we needed to put crypto whose purpose is *EXACTLY* our requirements into our client rather than continuing to rely on OpenSSL for things it never promised to do.

Oooohkay.  Let's consider the effect of a client that accepts and will cheerfully create >1Mb blocks.

Let's say I take a standard bitcoin client (client A) and create a new one (client B) that doesn't have a block size limit.  And then I start mining using client B.

Let's say that in a couple of days I make a block.  Cool.  So what's in my new block?  Because my client has been accepting blocks from the other clients, it won't repeat transactions that have already been in previous blocks.  It's looking at the same pool of outstanding transactions as everybody else.  So it'll include all the transactions from that pool that I choose to place in it, and likely have a block size between a quarter and a half-megabyte.  Everybody using client A is going to accept this block, because it follows all the existing protocols.  Then they're going to mine more blocks, and my client is going to accept those because they all follow my protocols.   And we can keep doing that for six or eight months.

But eventually after six months or so, let's say I get an 1100 kilobyte block (block B1, built on block A0).  It goes out on the network, and all the people running client A reject it.  Eventually somebody builds block A1 on block A0, because they rejected my block B1 as invalid.  And after that, A2 gets built on A1 before I get another block B2.  From my point of view it's indistinguishable from having an orphaned block.  As soon as I hear about A2, or maybe A3, I'll drop my B1 block because it's no longer on the longest chain.  From my point of view it's exactly like having a block orphaned for any other reason.

In fact, for as long as there's more hashing power using protocol A with the 1MB block limit, there will be no chain divergence possible.  There'll be no exclusively Chain-B coins, because client B will still accept client A blocks.  Every time the chain of <1Mb blocks gets longer, any chain that includes a >1Mb block will be orphaned. Even clients that find them acceptable will drop them when they aren't part of the longest chain.  And if there's more hashing power on protocol A, that'll happen before the coins from that first >1Mb block become spendable at a 100-block depth.

The next "interesting" thing that happens is when there's finally more hashing power on protocol B.  At this point a chain that includes a >1Mb block can get newer blocks built on it faster than the chain that includes only <1Mb blocks.  This is the point where an actual chain fork happens.  The majority of hashing power has shifted to protocol B, which allows chains that include >1Mb blocks, but a few holdouts, along with a bunch of crooks and their victims, stick with chain A.  

Now, here's the difference between holdouts, crooks, and victims.  A holdout continues to use chain-A outputs exclusively.  For a while, most holdout transactions are cheerfully accepted into both chain-A and chain-B blocks and cause no trouble.  But because chain A is now producing coins that are unspendable on chain B, and because crooks will eventually "taint" most chain-A outputs by double spending them, eventually holdout transactions cannot be placed into a blocks on chain B.  

A crook is using both chain A and chain B, and will spend pre-split outputs along with chain-B-only outputs in a tx on chain B (which gets rejected on chain A due to the chain-B outputs) then make a later tx on chain A to double-spend those pre-split outputs.  That makes it clear what a 'victim' is - a victim is the bagholder in the double spend.  Because he has not upgraded his client, he winds up with Bitcoins that have already been spent on chain B, which is now the main chain.  Victims can also find themselves in this position when they accept transactions from holdouts, if the holdouts have already dealt with crooks (ie, have double-spent coins) or are using chain-A-only outputs (ie, from coinbase tx which don't appear in chain B).  The holdouts may not care about the difference, but the victims sure as heck will.  

Here's the important thing about the post-split world.  Chain B is the majority of the hashing power, and every spend on chain A is also one of four things:  

a legitimate spend on chain B,  

an attempted double spend by a crook,

a spend by a holdout or crook that includes an output created in a previous double spend by a crook,

or a spend that includes coins (coinbase coins) that do not exist on chain B.

So for non-crooks, chain A is either irrelevant (your tx goes into both chains) or harmful (you get coins that are being or have already been double spent by crooks, or else coins from coinbases on an orphan chain).  The only reason to avoid switching to chain B, at the point where a fork actually becomes possible, is to preserve your ability to become someone's victim or the bagholder in an orphan chain.

This is FUD. 

There is no transaction acceptable to the current network that is unacceptable with a larger block size.  There is no transaction unacceptable to the current network that would become acceptable with a larger block size.  No "incompatibility" is being proposed.  The block size issue is strictly about scale, not about features. 

The point at which old and new chains diverge is the point at which the old chain cannot handle the transaction volume.  And if it can't handle the transaction volume, it's going to fail anyway.

Who are you working for?  Who is putting up the money to try to stop Bitcoin from scaling?

I ask, not because I think you'll give an honest answer, but because the other people you're talking to need to see and think about this question.

This is dumb.  Let us say one miner starts filling 20MB blocks with 0-fee transactions.  Let's say that there are users out there who supply her with 0-fee transactions.  Miners who are mining for fees will just ignore the 0-fee transactions, which means people who do 0-fee transactions just have to wait until the one miner who accepts them happens to get a block.

That means that the user has a choice between an 0-fee transaction that may or may not eventually get onto the blockchain at some unknown time in the distant future, or a fees-paid transaction that will get into the next block.  So, fees-paid transactions will keep happening because people don't want the uncertainty, delay, and hassle of wondering whether and when their tx will go through.

But it gets better.  That miner who is filling giant blocks with 0-fee transactions?  She's competing with miners who are collecting fees.  In that competition she will go broke.  So to the extent a miner can cause a problem by the behavior you describe, it's a self-correcting problem.

The November 2008 code is directly from Satoshi.  He posted to the crypto list.  Hal Finney and I were discussing it with him, and he sent us that archive in mid November.  I forwarded the Archive to Sergio Lerner and posted it here a few years later.