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!

Meni's paper is a very good read.  Here is a table from his paper and the two notes that followed.

•If the attacker controls more hashrate than the honest network, no amount of confir- mations will reduce the success rate below 100%.

•There is nothing special about the default, often-cited figure of 6 confirmations. It was chosen based on the assumption that an attacker is unlikely to amass more than 10% of the hashrate, and that a negligible risk of less than 0.1% is acceptable. Both these figures are arbitrary, however; 6 confirmations are overkill for casual attackers, and at the same time powerless against more dedicated attackers with much more than 10% hashrate.

I am concerned that a possible practical improvement is getting lost in the theory discussion.  With lots of factors to balance, there is a risk that any big change would lead to problems.  No one wants that.  But from what I understand, changing the target interval to 5 minutes would be safe.  Max block size would be shrunk to 500KB, coins issued per block would be cut in half.

Lets take your arguments gmaxwell, and look at them in the context of this specific proposal.


So the blocktime would be at 5 min in this case.  The orphan rate would be higher, but I'm guessing it would it rise by more than 5% or 10%.  And lets remember, the orphan rate is under 1% of all blocks, so the actual percentage of orphans would change from lets say  0.80% to something like 0.85%.  I'm just making these numbers up, so let me know if you disagree or have better estimates of the actual values.  I don't know to much about the convergence concept.  I would guess that 500KB blocks every 5 minutes still be well within the margin of safety though.


Good to know.  Lets not do that!  I don't think anyone would think 5 minutes is stupidly low (unless they were stupid?).


This may be a good point.  I don't know enough about how the headers work, but I'll try.  Empty-block headers are about 80 bytes.  If every block thus far had been empty, we would have ~20MB would of block headers since the genesis.  That number would be ~40MB if it had been 5 mins from the start.  A question: would the header-of-a-100-transaction-block + the header-of-an-empty-block be the same size as the two 50-transaction headers combined?  If that is true, than the added header 'overhead' costs would seem to be reasonable, basically an additional 80 bytes every 10 minutes over what we generate now.


Seems like Meni is taking you up on the security side.  Statistics aside, lets not forget the importance of that first confirmation!  I've met dozens of people in coffee shops helping them to get some bitcoins.  In purely human terms, there is a big difference between 5 and 10 minutes.  5 minutes is fast food, 10 is not.  You expect putting gas in a car to take 5 minutes - 10 would be a drag.  5 minutes just feels a lot faster than 10.  And since that first confirmation is way, way (maybe 100x?) more secure than an unconfirmed one, everything happening twice as fast would be very convenient for the bitcoin community as it is today.  I agree that in the future there will be lots of solutions to these issues, but to get there from here we need to keep people happy and things convenient so that the community lives on.

Of course, if Meni is right, and I think he is, then you can multiply that savings if you need more confirmations.  The current security provided by three confirmations (30 mins) could be replaced by four confirmations at 5 minutes (20 mins), and time savings will be afforded at any desired level of security.


It's good there are options, but this is a very technical solution.  Don't forget we want to make bitcoin better for even minimally technical users, so therefore it is not an argument against 5 minute blocktime.


The distribution curve doesn't change shape, but the timescale underneath it will be shrunk by a factor of two!  Again, transactions where two people initiate the transaction and then wait it out, but that 1, 2 or 6 blocks.  Whatever your number is, you will be waiting half as long on average.  Adjusting to keep the security level the same would not result in a 50% times savings, but maybe 30%.  Meni will tell you the exact amount.


No one wants to wait longer.  This is 99% a technical issue, and if the core dev team gives it's blessing, people will be very excited.  Why not propose raising it to 20 minutes and see if there is a similar level of excitement.  I tend to think we need a hard fork to prove to ourselves that we are dynamic community and can handle the challenge.  With core dev support, consensus will easily be over 95%.

I like it.  They lines could be shadows, or they could be movement trails.  My eye sees the movement trails, and then it looks the B⃦ and coin are moving backwards.  Nothing wrong with that, but perhaps not quite as subliminally powerful as is moving up and forward.  The particular change would be altering the angle of the shadows lines from ~120º to  ~240º.

Actually, they do.


All someone would have needed to do 2 months ago... well more like 4 months ago, and going back 4 years... would have been to make a few ASICs.  Just a few!  Now an attacker would have to make many, many ASICs.


Exactly... now an attacker would have to order a 'big bulk' as you put it.  That's way up from the very small amount that were necessary before four months ago.  Furthermore, a botnet is no longer any kind of threat.

The actual point you have come closest to making is that the network is more vulnerable now than it will be in the future.  There is no know technology that can supplant ASICs anytime soon.  However, the cost to mount a 51% attack is HIGHER now than it EVER WAS.  And it is getting higher every day.  Now, would bitcoin be more secure if humans didn't have knowledge of ASICs, or if somehow the laws of nature prevented them from being?  Maybe.  But that is not the case.  In this world that we actually live in, the cost for a 51% would have been no higher than the cost of designing and manufacturing ASICs.  This was possible back in the CPU and GPU days and is still possible now.  Now an attacker would have to actually ramp up production to make enough chips, and by then end of this year the cost of that attack will be many $10's of millions of dollars.  And it will cost more than just the silicon, getting everything connected is expensive too.



I agree with this.  But the technology has essentially always been there.  Bitcoin mining ASICs are comparatively not too difficult to design, so an attacker could have made bitcoin ASICs three years ago if they had wanted.

Downloading now...  started off with 11 peers and consistently over 12mbits/sec and peaking at 20mbits/sec, and that is on my 20mbit cable connection.  Yep, bitcoiners know how to make any kind of P2P kick ass.

That 'most countries are using mobile phones for payment' is hardly a missed opportunity.  If they are using litecoin... then yes, I'll agree, but they are using local, proprietary systems.  It's still a massive opportunity for many reasons.  With bitcoin they can pay for things globally, and in turn receive remittances instantly.  Keep in most of them don't have bank accounts.  Also, the political systems their are in pretty bad shape.  The managing of their currencies might even be worse than the USD.  Finally, to your point, they are already comfortable with digital, phone based currency.  Provide them with a vastly superior e-currency and you don't think they will go for it?


Edited to fix bad quote format

Exactly what I was thinking!  Even for [the unfortunate] people who don't yet have any bitcoins, they can travel there at a big discount if they just load up their brain wallets before they get on the plane.

I think SHA-256 is probably okay for proof of work.  Bitcoin, however, should include something other than just proof of work.  I am curious about the possibility of tying proof of work to proof of identity via private keys.  A block would have to have both a hash of a certain difficulty and be signed with a valid private key.  The hard-code of client could prohibit reject any block not signed by a valid private key, and to discourage centralization, only 4 out of the last 100 blocks could be signed by the same private key.  I just made up 4 out of 100... obviously these could be picked carefully after some statistical analysis.  We would first need to decide just how dispersed we wanted the hashing to be.

Then the real questions becomes 'what determines if a private key is valid?'.  Maybe those keys could be mined themselves, via scrypt.  Maybe it could be based on a web of trust model that somehow limited each person to just on current private key.  The private keys could wear out... they could be good for only 100 blocks total.

Of course we would have to be extremely cautions in picking a method to make sure it couldn't be easily gamed and lead to greater centralization.  There would be a market for valid private keys, and that is okay and expected.  I would hope there is someway the web of trust idea could be implemented.  Bitcoin, after all, is a service in the name of us people.  This project is not about trusting no one, but more so trusting everyone.  We trust ourselves - as a community - right now.  The web of trust could start with the core devs and valid keys would be propagated throughout the bitcoin community.  One person, one valid key.  The details of how that could be enforced I don't know yet.  But I hope some of you will be able to build on this.

I was mostly being facetious and was trying to imagine how someone with many thousands of bitcoins might have thought about it.  It Wikimedia thinks I have a shit ton of money, maybe they would be more receptive to the request.  I think I actually changed the 'small' amount to $1,000 in my actual email.

The impact of the ETF is not about the number of bitcoins it currently holds.  It is the impact of the ETF's legal and financial structure that is truly huge, or will be when and if it is approved.  The CONCEPT is extensible to ANY NUMBER of bitcoins and or dollars.

Thanks TippingPoint.

Dear Wikimedia,

I have a small amount of money - around $10,000 equivalent - that I would like to donate to support your awesome efforts at keeping information free and available to the people of this world.  I have been trying to find a way to get my funds to you, but it seems your organization does not accept bitcoin.  All of my funds are held in bitcoin.  I would like to donate.  Please consider accepting bitcoins for donations so I can give!

Thanks

Does anyone know what would be a good email address to send our thoughts to?

I like Coinbase too.  Coin stored with them, however, are not safe from government confiscation.  Why not?  Because they control and manage the private keys.  All it takes is one court order or police raid and you will be locked out.  You should really only use them to store a small amount of money, just as you would in a real leather wallet.  Don't use them as a bank account.

Back up for me too.  I like CampBX, but they really need to get some faster servers.  Their site is always slow to move around in.  They also need to beef up their two-factor auth. offerings.  It's only google authenticator right now.  Adding email, sms, or both would be welcome.

Also, I always need to enter my login credential twice to actually log in.  Very strange.

Just wondering if anyone else is having the same problem.

Way to spread the word chsados.  I skimmed the thread.  Yep, it was painful.  The problem hardly seemed to be about bitcoin, but rather that those gamer people had not a clue what money is.  General financial ignorance, topped off with a healthy does of close-mindedness, and maybe even a small dash of stupidity.  I wouldn't be surprised if the average IQ of the bitcoin community is over 110.

I pulled this post off the tread so.  Yep... painful.

****************
So.. Bitcoin isn't real. It's generated via interwebz. Money you didn't work for.
{irrelevant ramblings removed}
Course, i just read about wtf Bitcoins are soooo... And from what i read, i sure as heck ain't using it. Rather buy things with money I've earned working.
****************

For a few reasons.  One reason being that such a number would have a correlation to the cost to do a brute force 51% attack.  But mostly I think it is an interesting financial indicator that reflects the sentiment of the bitcoin community.  The price of a bitcoin is of course the primary measure, but I would put investment in mining hardware as a strong second.  It also just sounds cool as a talking point.  Being able to tell people 'well, if bitcoin is bullshit, better tell that to the folks who have dumped xxx millions into specialized hardware' is also a plus.

I think you approach gives a good low-lower bound.  I would guess that no more than 50TH/s is due to GPUs and CPUs, just looking at where the on the graph the spike started (and that coincided with the first Avalon rigs being brought online).

I think Avalon's batch 3 pulled in about $5,000,000 alone
75 BTC x 600 units x ~$100 per btc at the time (but some were four blade units at 100 BTC)

Does anyone know, between all the ASIC companies, how much USD money has been spent on pre-orders and mining equipment?  And invested in ASIC miner shares?

Looking for a 'total invested in mining' number.