Irrespective of any opinions on what the MAXBLOCKSIZE should or should not be, it is a variable and needs to have a value, or be eliminated from the code entirely.

Something or nothing must be done, so go ahead and place your bets, er, votes.

It's November, 2015.  Recent media attention and a rapid rise in the price of BTC are likely causes of the daily transaction count decisively moving above 150,000.  There looks to be a good chance of exceeding 200,000 daily transactions by the end of the month, if not sooner.

There will soon be more transactions submitted to the network than can be cleared by blocks.

It's clear that a transaction fee market for will develop, for better or worse.  But what about mempool growth?  And are there other backlog issues?  The stress tests came and went, but we might be entering a sustained period where transactional demand exceeds the networks capacity.  What will this look like with nodes and network we have today?

Multisig wallets have come a long way, but for the ultimate in usable security, it will be important to have a 2 of 3 (or 3 of 4) setup with different devices, each running different brands of wallet software.  Every mulitsig implementation that I know about only works with wallets from the same developers.  Does anyone know of different wallets that can multisig with each other?  And is there any sort of interoperability protocol that has been proposed or published?

Thanks!

Running a full node on a phone seems like it will never make sense.  SPV clients are convenient, but there are several unfortunate security and privacy tradeoffs.

It seems like it would relatively straightforward to run full node at home that was setup as a personal SPV server.  Your phone could pair with the server and all everything between the two would be encrypted.  Friends and family could link to it as well.

Does anyone know of any projects along these lines?  In addition to boosting the security and privacy on the SPV side, it would give users a very good reason to run full node, which would help the network as a whole. 

The blockchain synchronizes quickly when Bitcoin Core is first started, but after some time, maybe an hour or so, it slows to a crawl.  I can’t find the bottle neck.

This behavior is occurring under good testing conditions.


Computer: MacBook Pro 3.1, 2.4 Ghz Core 2 Duo, 4 GB RAM, 250GB SSD

OS: Mavericks 10.9.5 - Clean Install.  Bitcoin Core 9.3 is the only non-packaged software.

Internet: 25 / 5 mbps cable (comcast).

All settings are essentially stock.  I turned on the software firewall, then turned it back off.  Filevault 2 has been activated.

Description:  I did a clean install of the OS last night on a brand new hard drive.  I encrypted the drive and immediately proceeded to download Bitcoin Core 9.3 to test it out, and to test out the current blockchain total download time.

The client has been running for about 7 hours now, and currently has 16 inbound and 8 outbound connections, but it seems like nothing is happening. The block count in the debug window hasn’t budged in 5 minutes

CPU is 80% idle.  RAM is only about 50% full.  Network - 20 KB /s.

Then, as I am writing this, the data rate flowing into the computer surges to ~1.0 MB/s, the CPU starts processing, and the block count is flying upwards.  It is currently requesting blocks from September, 2011 era.

Now, just a couple of minutes and 1,000 blocks later, the computer is receiving only ~50 KB/s, the CPU is idle again, and the block count is not increasing, not even slowly.  It is stuck at block 143,882.

Next I quit and restart Bitcoin Core.  Almost instantly blocks start processing again, and downloading at 500 - 1,000 KB/s.  Within a minute or two, it has 1 inbound connection and 8 outbound.

I have observed the same thing happening on other Macs running 10.9.5.

Does anyone have a good explanation for this behavior?  It almost seems like my client just happens to be connected to 8 peers, none of which are willing to share any blockchain data.  If that is the case, I am surprised it wouldn’t do a more active search for sources of fast blocks.

A Proposal for a Trustless Hardware Random Number Generator

Overview

All of the hardware random number generators I am aware of, even the allegedly “crypto secure” ones, appear to rely on the integrity of their integrated circuits.  I don’t think it is reasonable to trust any particular integrated circuit for mission critical security.  With deterministic processes, it is easy to avoid trusting specific hardware by executing in parallel and checking the results against each other.  A simulation could be run on ten separate, air-gapped computers each using different operating systems, each having been made by different hardware manufactures and each running the simulation on different implementations of the same ‘protocol’.  All results should agree.  The chance of an attack affecting all ten systems, in such a way that they all give the exact same bogus result, is vanishingly small.

Traditional hardware random number generators, non-deterministic by design, cannot have their results audited in a similar way.  The user is left to trust that the hardware functions as advertised.

The kind of trustless HRGN (TL-HRGN) that I have in mind must somehow separate the source of entropy from the digitization process, such that there can be multiple computer-observers of the same physical event.  Ideally there could be as many isolated computers as the user wanted, each recording the same phenomenon – say dice rolls - and afterwards comparing results.  The results should match.  The user would still be responsible for making sure they had fair dice – a much easier task than making sure an I.C. doesn’t have a backdoor.  In addition, each of the separate computers could be running statistics on the dice-generated entropy to make sure it met tests for randomness.

***********************************************************************************

Design

I am currently working on a TL-HRNG design for which I intend to construct a working prototype.  Design goals are as follows:

Size:          Desktop computer tower-sized or smaller
Data Rate: At least 500 bits of entropy per second. 10kbits / sec would be better
Cost:         Under $2,000 - under $500 would be better

The randomness will be motion-based, using BBs or ball bearings that cascade down from the top of the device, sliding and rolling down an inclined backboard.  There will be some ramps to limit and roughly control the flow of the bearings.  There will be sensitive electrical switches placed in locations where bearings will frequently strike.  The switches will be designed such that when struck with a bearing, they will close only momentarily, hopefully something on the order of 0.1ms.

{Insert Picture of spring-switch}

A switch will be wired to a battery and light emitting diode. Every time a bearing strikes the switch surface, the connected LED will blink.  A photodiode, connected to a high-speed analog to digital converter, will look directly at the LED.  The quantity to be measured will be the time between blinks, hopefully to the millionth, or even ten-millionth, of a second.  The high precision is important.  The data will not be random, and therefore not useful, until at least several positions to the right of the decimal.  At the same time, the data can only be considered trustless if at least two independent computer systems can agree on their observations.  The closer the agreement - in terms of time measured - the more useful bits of entropy that can be harvested per event.

Since the two computer systems are isolated from each other, they will not have any kind of clock synchronization.  Perhaps to within a second or two, as that could be accomplished by manually setting date and time, but that is not going to help with the required micro-second precision.  The idea is each computer will have a list of time-stamped events.  While the time-stamps themselves will not match, the elapsed time between events should be the same, at least to some level of precision.

This should be possible to accomplish with any number of isolated computer systems. The only thing the computers have common is they are all staring – via separate photodiodes – at the same blinking LED.  The LED blinks when cascading ball bearings strike a switch surface.  A trustless hardware random number generator.

**********************************************************************************

I was inspired by the Dice-O-Matic (http://gamesbyemail.com/news/diceomatic).  It is an automated dice rolling system.  The dice are rolled by tumbling down a curved chute.  At the bottom they settle into an elevator system for ride back to the top of the chute.  As the dice ride the elevator, a camera snaps their picture, and the dice markings are analyzed with software.  While the ingenious creator doesn’t indicated having multiple cameras and computers to corroborate each other’s record, they would be trivial to add.

I was inspired by whitslack's nice Bitcoin inflation charts, found here https://bitcointalk.org/index.php?topic=130619.0.  I wanted make a similar chart, but one that included John Ratcliff's estimates on lost, or "Zombie" bitcoins.  The Zombie analysis can be found here http://letstalkbitcoin.com/blog/post/rise-of-the-zombie-bitcoins.  I used R to make the chart.  It was my first time using R and it took me all day!



If in fact 3 million coins are not controllable, and therefore effectively out of the current supply of bitcoins, the current inflation rate is closer to 15%, which is 50% higher than the 10% that would otherwise be expected.  The results are interesting and the graph speaks for itself.

Wikipedia just announced the are accepting bitcoin.  They are using Coinbase, and as a result their receiving address is different for each donation.  Using a fresh address for each transaction enhances privacy, but it also makes it a little harder to verify that you are sending funds to the correct party.  If the address is static, it can be printed in magazines and newspapers or displayed on a charity's main website without too much dynamic code.

Are there reasons why a charity wouldn't want to have a publicly know, static donation address?  Maybe they should at least provide a fresh, private address if requested, but it seems like the sender should be protecting their own privacy if they care.

I woke up and saw this email in my inbox:

Hi John Doe

Thanks for your email.  I wanted you to be among the first to know that as of this morning, the Wikimedia Foundation is accepting Bitcoin donations!

Later today, you'll receive a generic email from the Foundation with the news, but I'm hoping that my note reaches you first.  If your offer is still good, we're definitely interested, and we would be very grateful for your generosity and your patience! 

You can donate here: https://wikimediafoundation.org/wiki/Ways_to_Give/en#bitcoin.

Best,
Caitlin

Caitlin Virtue
Director of Development
Wikimedia Foundation

If there is a hard fork to increase the maxblocksize, say to 5MB or 10MB, wouldn't it make sense at that point to drop the block interval to 5 minutes, and raise the maxblocksize by only half of what would otherwise have been done?  The benefit would be faster confirmations, which is helpful in many cases (and I would rather not argue that point).

What would the drawbacks be?  Double the load for SPV servers.  That seems manageable.  Orphan rates should be negligibly higher, but the time to propagate a block scales lineally with transaction payload.  I am assuming empty blocks propagate very quickly and I am assuming since I don't know.

gmaxwell has previously raised concerns about network convergence times.  But isn't that mostly a function of the total amount of data that is attempting to stay in sync?  Wouldn't convergence basically be the same for 10MB blocks every 10 minutes as for 5MB blocks every 5 minutes?  Granted that as block time approaches zero, convergence will be a problem.  But for just cutting it in half?  I can't see why convergence rates wouldn't be similar.

I know the subject of confirmation times has been discussed many times before.  This time I am particularly interested in discussing it in the context of (1) larger blocks which would be (2) part of a hard fork.


Below are some of gmaxwell's points from a related discussion.

https://bitcointalk.org/index.php?topic=260180.0;all

(1) Orphaning rate depends on the time relative to communications & validation delay (formula given in the link).  At the limit as the block-time goes to zero the network will stop converging and typical reorganizations tend to infinitely long.  The actual delays depend on network topography and block size. And as an aside— in the past we've seen global convergence times on Bitcoin get up to over two minutes, although the software performance has been improved since then it doesn't seem that there a ton of headroom before convergence failures would be likely in practice, certainly fast convergence is harder with larger blocks.

(1a) There have been altcoins who didn't understand this and set their block times to be stupidly low and suffered pretty much instant convergence failure (e.g. liquidcoin). There are other ones that may start failing if they ever get enough transaction volume that validation actually takes a bit of time.

(2) The computational/bandwidth/storage cost of running a SPV node, or query a remote computation oracle for signing, or to present a bitcoin proof in a non-bitcoin chain is almost entirely due to the header rate. Going to 5 minutes, for example, would double these costs. Increasing costs for the most cost-sensitive usages is not very attractive.

(3) With the exception of 1 confirmation transactions, once you are slow enough that orphaning isn't a major consideration there is no real security difference that depend on the particular rate. For moderate length attacks sum computation matters and how you dice it up doesn't matter much. One confirm security— however— isn't particular secure.

(3a)  If there is actually a demand for fast low security evidence of mining effort,  you can achieve that simply by having miners publish shares like P2Pool does. You could then look at this data and estimate how much of the network hashrate is attempting to include the transaction you're interested in.  This doesn't, however, create the orphaning/convergence problems of (1) or the bandwidth/storage impact on disinterested nodes of (2).

(3b) Because mining is a stochastic lottery confirmations can take a rather long time even when the mean is small. Few things which you can describe as "needing" a 2 minute mean would actually still be happy with it taking 5 times that sometimes. Those applications simply need to use other mechanisms than global consensus as their primary mechanism.

(4) While you can debate the fine details of the parameters— perhaps 20 minutes or 5 minutes would have been wiser— because of the above none of the arguments are all that compelling.  Changing this parameter would require the consent of all of the surviving Bitcoin users, absent a really compelling argument it simply isn't going to happen.

If you'd like to explore these ideas just as an intellectual novelty,  Amiller's ideas about merging in evidence of orphaned blocks to target an orphaning rate instead of a time are probably the most interesting—  the problem then becomes things like how to prevent cliques of fast miners self-centralizing against further away groups who can't keep up, and producing proofs for SPV clients which are succinct in the face of potentially quite fast blocks.

For large, conservative investors, this is the first chance to buy bitcoins directly from the U.S. Government.  There is an implicit guarantee that the coins to be sold are legal and without any sort of taint, at least in the eyes of the Feds.  Also, to many such investors, the U.S. Gvt is the most trusted trading partner possible.  They are the most reliable organization to trust wiring millions of dollars to.

The auction is a giant stamp of approval, if not for bitcoin as a whole, than at least for the particular set of coins at auction.

There are obviously reasons why the coins may sell at a discount as well, and I tend to think that is more likely.  My guess is there is about a 20% chance the coins will sell over spot.  After all, the supply of government-approved bitcoins is very very tiny.

I wrote this for the comment section of the Economist article that covered bitcoin's deflationary aspect.  I know it has been discussed many times here, but we should probably keep discussing so we can continually educated ourselves and our growing community about this very broad and subtle topic.

http://www.economist.com/blogs/freeexchange/2014/04/money

The strength of the economy not a measurable concept, is in the eye of the beholder.  Your good economy might be my bad economy.  There are hundreds of millions of people around the world who disagree with the Western Governments conventional view of economic strength and progress.  If bitcoin could drive down over consumption as part of its macro-effects, I see that as a positive.  Others might disagree.  But if you think I should be pressured into a certain type of behavior, such as working 40 hours a week, or ‘investing’ my money, because it benefits your view of what a good economy is, than you are much more aligned with central planning and a lack of personal freedom than with free-market capitalism, where each can seek their own path with minimal interferance.

*put another way*

It really comes down to what your concept of an 'economy' is.  I consider the essence of an 'economy' to be about society enabling people to satisfy their needs and desires.  It doesn't necessarily have anything to do with the maximum material output and over consumption that currently drives mainstream western economic thought.  Imagine some future utopia, where only ten hours per week of work is needed for the typical person to fulfill their needs and desires.  Materiel consumption is almost nothing, as goods last a lifetime, and instead of shopping for new gadgets, people derive their happiness from hours of reading, spending time with their friends and children, making music and meditating. Who am I to tell these people they have a bad economy?

[reversible address]

Optional reversibility at least.  I've heard a million times on these forums that third-party services will offer the needed features that consumers desire.  The more features that are built into the protocol, the less reliant we will be on those shady centralized services that want to "know us", hit us with fees, or just Gox us.

Here is the concept.  It's probably been discussed and dismissed already, but here it is anyway:

You would be able to predesignate an address as a reversible address.  Two variables would need to be set, the block-depth of the reversibility and the address to which any reversed funds would be sent to.  Since an address doesn't exist on the blockchain until at least one satoshi is sent to it for the first time, you would have to send that first satoshi along with the proper reversibility instructions to setup the address.

After the one satoshi spend was confirmed, you could verify on-chain the reversible properties of the address, which again, would be the block-depth of reversibility and the go-to address of any reversed funds.  You could proceed to load up the address with coins.  Spending would be as normal for the owner.  It would be publicly verifiable that any spends originating from for such an address would be reversible until they were 'X' blocks deep in the chain.

If you spent reversible coins and wanted to undo the transaction, you would have to broadcast a new transaction and have it confirmed in the chain before 'X' blocks had elapsed.  In order for that new 'double spend' to be valid, you would have to direct the funds to the same go-to address originally specified when you set up your reversible address.

The point of having a designated go-to address be different from the originating address is in case your private keys were compromised.  You would still be able to undo the transaction, as would the attacker.  But unless they were in control of the second address as well, they wouldn't end up with the coins.

There could be an upper limit to reversibility, perhaps a month.  There are pros and cons to encumbering your coins as such.  No vending machine would accept coins that could be reversed.  But an internet retailer would, they would just need to wait X blocks + 6 confirmations before shipping your stuff.  The nice part is you could get the email receipt from them that you paid and all was good before the reversibility window had passed.  If you didn't get the email, maybe because someone had man-in-the-middled the merchant's address, you could fix the mistake before it became permanent.

I am wondering if this would be a viable, legal strategy.  Say you bought 100 coins at $10 per coin over a year ago, then sold 50 coins at $1000 each.  You're capital gains for this year would $49,500.

But then, at 11:55 PM on new years eve, you but 30 coins at $800 each ($24,000), and then just a few minutes later in 2014, you sell them again for the same amount of cash.

Nothing offset 20 of the 50 coins you first sold, so that would be $20,000 profit.

The other 30, I would think you'd have realized $200 of long term gain on each one.  So another $6,000.

$26,000 in long term captial gains for 2013,

30 x $800 = $24,000 in long term capital gains to start off 2014.

I wonder if there will be little spikes and crashes as different time zones approach midnight.

I know this is a little bit off topic -

Does anyone know how make os x display the recovery key (really just the direct encryption key) for an encrypted drive?  I've been going though a process of doubling down on all of my security procedures.  One result is going to be a bunch of encrypted drives, and I will be greater risk of data loss if all else stays the same.

First I would like to make os x show me in - plain text - each of the keys.  Then would like to have a way to test out each of those keys and prove to myself they are capable of decrypting the drive.

Does anyone know some terminal commands that would work?  Google is not being my friend.

Thanks

Bitcoin continually blows my mind.  It looks like a top of the line Retina MacBook Pro can pump out about 20 MH/s, whereas a KNC Nuptune is advertised to hash at 3 TH/s, or 150,000x faster than the macbook.

Can someone double check this calculation.  I find myself in disbelief.

The dude could have be holed up in his parents basement, wearing dirty underwear and popping pills.  Truly amazing they have managed to amass so much wealth and their identity remains not publicly known.  That fact alone is a testament to the power of Bitcoin and an example of one of the many ways in which it is going to change the world.

I am traveling from the USA and will be in Helsinki this coming weekend.  It would be great to meet some bitcoiners when I am there.  I've never been to Finland before, so I don't know where a good meeting place would be, but hopefully a local will read this and suggest a good location.  Maybe Localbitcoin founders will come?

I think it could be helpful to remove some of the uncertainty around old coins, to see if they are truly lost or not.  This is an issue that is will never go away, and in fact will only grow more troubling as bitcoin grows in value.  My proposal is to pick a comfortably far off future date (maybe 1 year) and say that any coins on addresses that have been stagnant since some long-ago date (how about Jan. 1st, 2011?) would be removed from the money supply.

If you had coins on an old address, all you would need to do to protect your wealth would be to transfer them to a new address, or just send a single satoshi, before the future cut-off date.  This would be a one-time event that would require a hard fork and therefore a consensus of the community.

Every market thrives on information.  I would argue that large uncertainty about the amount of lost coins is hurting bitcoin adoption, especially its use as a store of value.  I think this proposal would help bitcoin adoption by providing a count of the number of controllable coins, and it would do so in a manner that would not unfairly penalize anyone. 

If there are any Muscovites reading this, I'll be visiting your great city for the first time starting Wednesday morning.  The global currency aspect of BTC is one of the coolest parts, and I'd like to make that more real for myself by meeting up with some of you.  I apologize in advance; I don't speak any Russian, at least not yet, so I would be a good chance to practice your English skills.

-Let me know if there are any bitcoin meetups in the coming days
-I will be offering to sell small quantities of BTC 1 to 4 at a time to acquire Ruples without using the banks.  I will offer them at 1% - 2% over spot to anyone on this forum
-Contact me if you want to party, drink some Vodka, and talk about bitcoins
-If you have or know of a couch I could spend a few nights on, I would be very grateful and of course invite you to stay at my place in Hawaii

See you all soon!