As I have explained many times, it is not just academic interest; I feel I have also the obligation of giving public information about it (like I have been doing for 10 years about electronic voting).

BTW, two days ago one of my students asked me whether it was worth mining bitcoin with GPU cards.   Luckily I knew enough to tell him to forget the idea. 

It was only the second time someone asked me in person about bitcoin, since I started following it; and the previous case, too, was about GPU mining.  I wonder now whether someone is trying to sell some bitcoin mining project around here...

Thanks! But you are giving me too much credit.  Most of the time, I have been just one of the early critics...

I helped organize a couple of them when I was a Ph. D. student in the US.  But the Brazilian Students Association was so popular that the president was from Portugal.  So that does not add much to my resumé, I am afraid.

Amagi Metals, the bitcoin-accepting precious metals dealer who promised to become bitcoin-only in 2016, seems to be rather non-existant at the moment:

http://www.reddit.com/r/Bitcoin/comments/3b93ui/psa_amagi_metals_has_scammed_me_and_ran/

From Nathaniel Popper's book:

> "Not long after that, Gates made his first public comments praising at least some of the concepts behind Bitcoin, if not the anonymity."

Here is what Bill Gates wrote in Jan/2015

> "Bitcoin is an exciting new technology. For our Foundation work we are doing digital currency to help the poor get banking services. We don't use bitcoin specifically for two reasons. One is that the poor shouldn't have a currency whose value goes up and down a lot compared to their local currency. Second is that if a mistake is made in who you pay then you need to be able to reverse it so anonymity wouldn't work."

So, bitcoiners need only make sure that the price of bitcoin will remain at 245 forever, abolish anonymity, and make transactions reversible.  Then Bill Gates will sure have thrird thoughts.

Price of bitcoin now = 245 USD/BTC.

But 245 = (value of 1 BTC)/(value of 1 USD), or 245 = BTC/USD for lazy typists.

Are you sure?  The first transaction, AFAIK, was Satoshi sending some coins to Hal Finney for test. I don't think that there was much investment in bitcoin until demand for use as the SilkRoad currency drove the price up.

Last Active:    2015-06-05, 07:59:56

Last post:       2015-02-07, 17:50:20

Next-to-last post (same date):

Indeed, there were many small equal bids equally spaced, that were removed all at the same time.  Leaving many slighy larger bids, equally spaced with double the step.

Best Biblical exegesis ever. 

Can you make guinea sausages out of guinea pigs?

I see that as burying one's head 100 feet deep in the sand and laying down a foot-thick concrete slab on top.

Transaction fees did not go up, because most clients were not prepared to upgrade their fees, and replace-by-fee is still not a common practice.  Transactions that paid the standard fee got delayed for many hours.  If the "attackers" had used higher paying transactions,  then hiigher-paying transactions would have been delayed too. 

The "attackers" had intended to spend 5000 euros on the test, but their own BitcoinD servers crashed under the load and so they gave up after spending less than 500 euros.  Even so, the large queues that formed at the nodes crashed Blockchain.info, knocked out bitcoin ATMs, caused problems for BitPay and other services.

The small-blockians have no meaningful technical arguments against the block increase, so they are resorting to personal attacks on Mike and Gavin, and exaggerating the danger of a possible a split of the coin.  Which would never be a real risk if they did not make such a fuss about the increase themselves.

Again, I am each day more convinced that Blockstream had promised to their investors that the network would saturate in a year or two, and then the crowds would come knocking at their door for their Sidechains/LN solutions; and that Blockstream had most of the core devs, so that they could make the changes that they needed to the protocol while blocking any changes that their competitors would need.  That would explain why they were so upset, and why they continue to oppose it when the major players have all agreed to it.

Not Viacoin (although that may be the case for one of the devs).  Blockstream was formed by Greg Maxwell adn Adam Back to develop off-chain solutions to solve bitcoin's scalability problem.  These solutions were originally to be the sidechains, but now Blockstream seems to be admitting that sidechains will not do it.  Now they seem to be all excited about the Lightning Network (although the inventors of the LN are not Blockstream employees, AFAIK).

If I understood correctly, Blockstream employs several other "core devs" besides Greg and Adam, including the head developer who inherited the role from Gavin.  That gives them control over the "reference"  implementation of bitcoin (BitcoinQT).  Gavin has since joined Mike Hearn to support another version of that software (BitcoinXT).  The new devs are already including in BitcoinQT several fixes and extensions that supposedly will be needed by sidechains and the LN.

But I still don't understand how the Lightning Network is supposed to work.  

The first descriptions of LN used a thing called a Payment Channel (PC).  To use a payment channel, the sender A first locks up an amount X of bitcoins on the blockchain, earmarked for the receiver B, for a certain time T. Then A can send to B any number of payments, whose sum S does not exceed X. (Each payment is more like a signed "check" for an increasing amount, such that B can cash at most one of those checks.)  At any time before T, B can cash the last (highest) check he got in order to receive the S bitcoins, thus closing the channel, and the remaining balance X - S is then released and returned to A.  If B fails to cash the check in time,  the entire amount X is automatically returned to A.  Either way, the closing operation is done on the blockchain.

A payment channel is worth using only A expects to be doing three or more payments to B within time T; and it has the disadvantage that A must lock up the entire total S in advance, plus (usually) some exccess bitcoins, and cannot get back her balance until the timeout T has expired or B cashes the check.  Moreover, if B's train develops a flat tire and he fails to cash before time T, then he has no way, technical or legal, to collect the bitcoins -- unless A agrees to send them again.

Since it would be impractical for each customer to open a PC to every merchant that she *may* use, the LN plan is to use a set of "hubs" (think of Coinbase or Circle).  Each user would normally open only one PC to a hub, and use that PC to pay any merchant, who would receive the checks from his hub, possibly through one or more hub-to-hub channels.  Then bitcoin "checks" could circulate within the LN through several hops and commercia transactions, without adding traffic to the blockchain until they are "cashed out".   The LN would use the blockchain only rarely, for bulk settlements between hubs and other large bitcoin transfers.

However, if that is indeed the idea, in order to establish all those channels, each user woud have to lock up in advance, at his ingoing PC, all the bitcoins that he intends to spend in the next week or month.  Moreover, in order for the hubs to establish the outgoing channels to users, they would have to borrow bitcoins.  So, for example, a hub that served 1'000'000 customers, each with 10 BTC to spend over the next mont on any or all of 1000 merchants, may have to lock up 10 million bitcoins with each merchant, or 10 billion BTC total.  Even if the hub does a statistical guess about how mucheach merchant will receive, it would have to borrow and lock up at least 10 million BTC.

Another problem is how to prevent a customer from spending 8 BTC with each of two merchants, when he has locked only 10 BTC with the hub.  It seems that the merchants would have to trust the hub to do that checking.  If the hub fails to prevent that double spend, the merchants will still get their 8 BTC each, but the hub (or whoever lent BTC to it) would lose 6 BTC.  

Perhaps the LN and Blockstream guys have other secret tricks up to their sleeves to solve those problems. I have tried to get a worked-out example from Luke Dashjr, Adam Back, and at least three other redditors who seem to know about LN; but whenever I get to those questions the conversation stops.  They don't even say "there is a way but we can't tell you".  So, right now I believe that their design of the LN is about as advanced as Leonardo da Vinci's  design of the airplane.

One thing that seems certain, though, is that the LN cannot grow little by little.  If only 30% or 50% of the bitcoin users are in the LN, the "checks" would have to be cashed all the time in order to send to non-LN recipients.  Likewise, when receiving bitcoins from non-LN sources, the LN users would have to close the PC to their hub and reopen it with their increased amount.  (But users cannot close their outgoing PCs, they have to ask the hub to do it, which may take as long as the timeout.)  Thus each payment between an LN user and a non-LN user will require three transctions in the blockchain.  Far from reducing the traffic on the latter, the LN could multiply it.

The apparent need for the LN to start fully-formed may explain why the Blockstream seem to desperately need the bitcoin network to saturate and its fees to go up (someone mentioned 100 USD per transaction): so that all bitcoiners would be forced to move together to the LN.

Unfortunately, the new devs do not seem to realize the chaos that will ensue if the network capacity is exhausted.  Mike Hearn posted a description of the "crash landing" of bitcoin, based on common knowledge of how queues behave under those conditions, and what it would mean for clients given bitcoin's demented fee policy (Which Peter Todd wants to make even more demented, but that is another topic).  But the new devs do not seem to understand the problem, and keep claiming that the "free market forces" and some "trivial" changes to the clients will magically make things work:
They cannot see that the bitcoin "fee market" is not at all a free market.  


The top five Chinese miners (with 60% of the total hashpower) have signed a joint statement saying that they agree that an increase in block size is necessary, but 20 MB was too much for them; they said 8 MB now would be fine, and further increases shoudl be discussed later.  Gavin has changed his proposal to lift the limit to 8 MB at 2016-01-11, or two weeks after 75% of the miners have adopted the large-block version, wichever comes LAST; and then double the limit every 2 years.


The exchanges and other services are not directly impacted by the block size issue, since their use of the blockchain is very light.  But OKCoin supported the original 20 MB proposal, and I believe that many of the others did too.  

This may be another explanation for why the new devs and/or Blockstream were so upset. Seeing that the new devs were not going to accept his proposal,  before publishing it Gavin tried to contact the major players privately to sense their position.  The new devs understandably felt trampled over.  And, perhaps, Blockstream had boasted to their investors that they had control of the protocol -- which Gavin and Mike are now disputing.


If the new devs had supported the block increase, the fork would almost certainly have been a non-event.  The change itself is minor, and it merely restores partially the original limit (32 MB) that Satoshi had put, and later lowered to 1 MB as a protection agains some hypothetical "huge block attack".  As soon as the new version was adopted by a majority of the mining power, all the other major players and wallet developers should switch to it (even if they did not like it), out of self-interest; and would tell their clients to upgrade too.  Then, at the scheduled fork time, the original branch of the blockchain would die for lack of miners.  Clients and services who upgraded would notice anything unusual, except an occasional block above 1 MB. Any laggard clients would be unable to use their coins, and would have to upgrade in order to recover access to them.

The chance of the coin splitting is small; but even if it happened, it would not be the end of bitcoin (if the fork is done properly, which it may not be).  Such a split would create two bitcoin clones, one with blocks limited to 1 MB and one with potentially 8 MB blocks.  Every bitcoin owner would start out with equal amounts of both coins, and could move or sell them independently.  Then the fanatical small-blockians could sell their big-blockian bitcoins and buy more small-blockian ones, and vice-versa.  The market would then decide the value of each coin.  Perhaps the small-blockian coin will become the LN settlement currency, whereas the big-blockian coin would be the choice for for those who prefer a palaeolithic cryptocurrency, with all the natural fiber and vitamins.  

It would be like that time when the Catholic Church and the Protestants peacefuly split and agreed to let people choose freely their church, in a free market kind of way.

Those threats sound like the kid who threatens to hold up his breath until he dies unless mom lets him watch late night TV.

The fork to increase the block size would have been a non-event if the Blockstream guys did not make such a fuss about it.  

It is like they promised their investors that the blocks would fill up next year, or something...

Some results of the test gleaned from this plot:

  Estimated network capacity:  85 kB/min

  Typical input tx rate before test: 30--50 kB/min

  Typical queue size before test: 300--600 kB

  Peak input tx rate during test: 126 kB/min (~3x normal, ~50% over capacity)

  Peak queue sizes during peak test: 12 MB (14:00), 14 MB (21:30)

  Sustained input tx rate for several hours after peak: 70-100 kB/min

The test definitely showed that even a small player can create a large backlog with modest expense.

It showed that when the input transaction rate is close to the network capacity, even a small increase in that rate can create a huge backlog.   Between 18:00 and 21:30, when the input rate increased from ~75 kB/min to ~112 kB/min (a 50% increase), the queue grew from ~3 MB to ~14 MB (a 370% increase).

The previous stress test (on a late friday night) used only free transactions, so the fee-paying transactions were delayed only slightly. This one used fee-paying transactions: it will be interesting to see how it affected the ordinary fee-paying transactions.  I hope that someone will do a detailed analysis.

I watched the transactions for a short while during the test, I remember seeing many 0.0001, several 0.0002, a few with larger fees.  I don't know whether the 0.0002 were part of the test or not.  Perhaps they answer that in this thread

Raising the minimum fee to ~0.10 USD would make this sort of attack more expensive, but it would still be cheap and simple compared to, say, a 51% attack by an outside party.  Also raising the block size to 8 MB would make it 8x more expensive.

A mandatory 0.10 USD fee would have other advantages.  It would encourage miners to fill blocks.  It would cut down annoying small transactions that are being spammed to random addresses for advertisement purposes.  However, it would have some drawbacks.  It would harm things like tumbling and gambling, which many people consider important.  It would also probably cut the number of transactions by 50% or more, that would look bad on charts.



There are posts by Satoshi on this forum discussing that; check his posts through his user profile.  The original limit was 32 MB.  Then people thought that a malicious miner might create 32 MB blocks full of garbage transactions, that would take a long time to send across the network, validate, download when syncing, etc.; that could break some nodes or clients.  So Satoshi and/or Gavin changed the limit to 1 MB, and commented that it should be raised later if necessary.

KnC: "Yes, we issue and buy back ETNs in the market. At this point we have net sold 1388774 ETNs and hold 6944 BTC"
https://twitter.com/xbtprovider/status/611454898492833792

(200 ETNs = 1 BTC, apart from fees perhaps)

The stress was very weak, unfortunately.  From this plot:

  Estimated network capacity:  85 kB/min

  Typical input tx rate before test: 30--50 kB/min

  Typical queue size before test: 300--600 kB

  Peak input tx rate during test: 126 kB/min (~3x normal, ~50% over capacity)

  Peak queue sizes during peak test: 12 MB (14:00), 14 MB (21:30)

  Sustained input tx rate for several hours after peak: 70-100 kB/min

Methink the test was necessary for people to pay attention to the problem.

The test showed that even a small player can create a large backlog with modest expense.

It showed that when the input transaction rate is close to the network capacity, even a small increase in that rate can create a huge backlog.   Between 18:00 and 21:30, when the input rate increased from ~75 kB/min to ~112 kB/min (a 50% increase), the queue grew from ~3 MB to ~14 MB (a 370% increase).

The previous stress test (on a late friday night) used only free transactions, so the fee-paying transactions were delayed only slightly. This one used fee-paying transactions: it will be interesting to see how it affected the ordinary fee-paying transactions.

I think that it was scheduled for 14:00 UTC, which is 15 minutes from now.

There are already threads that discuss and keep track of those instruments, but they may not be be updated regularly:

KncMiner XBT: 3175 BTC traded at 248$ !

$GBTC Speculation, Information, and Cogitation

For XBT Tracker One, my USD prices are different from those reported in that thread because I use the approximate SEC/USD exchange rate of the day, whereas that thread may be using the nominal value posted by KnC.  There are also service fees that may not be properly accounted for.