Ehh yeah sure, if you store everything in one big table... Or if you know the mysteries of SQL "Join". |
|
|
|
WOW ... PHP has actually **TWO** different libraries just for doing arbitrary precision arithmetics ! This is awesome. PHP FTW.
I'll let you into a secret. I only mentioned two of them. But PHP actually has **ELEVEN**! Ruby only goes up to ten. |
|
|
|
Bitcoin ... is a currency like any others But ... Bitcoin is a currency totally different from all the others! |
|
|
|
|
In that case I still don't understand the need for more than one checkpoint.
|
|
|
|
|
If you want Bitcoin to have lots of flourishing exchanges, you have to let the exchanges make money.
People who complain about "excessive" profit margin at an exchange should open a competing exchange.
|
|
|
|
You don't easily change a protocol constant. Agreed. If we can find a workable algorithmic block size, it makes sense to adopt it earlier rather than later. I have never understood the argument that when transaction numbers rise you can pay a transaction fee for priority, or use free transactions which will get processed "eventually". It makes no sense. If the average number of transactions per hour is more than six blocks worth, the transaction queue will grow and grow and grow without bound, transaction fees or not. |
|
|
|
Actually, i think that BC_MATH extension is compiled-in PHP in most Linux distributions. BC_MATH is widely available, and if it isn't in your distro (or at your ISP) then it's likely that GMP is available. Either of these libraries is suitable for arbitrary precision decimal arithmetic without glitches. |
|
|
|
Actually I think i remember Satoshi or Gavin saying that it actually is a quite easy change as bitcoin was designed so that decimal places can be added indefinately.
An authoritative link would be really good, because this issue keeps coming up and it would be nice to have it answered once-and-for-all in the FAQ. |
|
|
|
|
I pledge 10 BTC. (sent to kiba)
|
|
|
|
By the way, who pays for bitcoin.org and for the forum server? How about a "donate" button? Every time I see those checksums at the bottom of the bitcoin.org home page I have to resist the urge to send some bitcoins to them. |
|
|
|
|
And bitcoinwatch.com shows that 168426.7 bitcoins were sent in the last 24 hours. That's 3.6% of all bitcoins turning over in a day, for an average hold time of 27.6 days.
Although some of those coins are turning over to another address belonging to the same person, there are many more coins being traded (e.g. on MtGox) without showing up in the block chain.
|
|
|
|
|
Why is more than one checkpoint needed? Block 74000 (for example) is cryptographically linked to the earlier blocks, so if 74000 is OK aren't all the earlier blocks also OK?
|
|
|
|
"...Don't worry, if they never claim it, the Bitcoin will eventually get returned to your MyGox account..."
Things may have changed, but I'm pretty sure that this is inaccurate. There is the possibility of expiring transactions, but the scripting process is not yet operational. MtGox sends out an email. If the recipient of the email has/creates a MtGox account and claims the funds, MtGox processes the transfer. Otherwise MtGox returns the funds to the originator's MtGox account. No bitcoin transaction is created, so the issue of expiring transactions doesn't apply here. |
|
|
|
Wouldn't it by much easier to, for example, put a 1 as the first bit of the 64bit int Yes, a "signal bit" is a much better way of doing it than moving to 128-bit integers, because 63 bits of precision is plenty for any transaction. But the 64th bit should not mean "shift everything by 16 bits", because we want to keep the subdivision of a bitcoin in decimal units, not binary units. The 64th bit could mean "the remaining bits are an integer count of the number of 10 -16-bitcoins rather than the number of 10 -8-bitcoins". 55 bits is enough to store all of the bitcoins at the current level of precision (21,000,000.000 000 00), so there will be quite a few spare bits available when the time comes. |
|
|
|
First, the purpose of my new page at http://bitcoinaddress.com is to create a master directory of public bitcoin addresses of people and organizations which accept donations via bitcoin. This is a bad idea. If an organization stops accepting bitcoins, or changes to a different wallet, anyone who donates from your links will be throwing away their money. Bitcoin donation addresses only make sense when they are directly maintained by the organization receiving the donations. [edit: including bitcoin donation addresses in a TXT record of the DNS would work much better] |
|
|
|
If the protocol permitted perpetual inflation, even at a predictable and unalterable rate, I certainly wouldn't be here to talk about it. I can only guess at the motivations of others.
Ditto. The fixed coin limit was what got me hooked. |
|
|
|
Click on "Account History".
Thanks! I see three decimal places for all the calculated values. |
|
|
|
are you ready to see the numbers like this:
12.3234453404553525454656
No. MtGox already calculates the transactions to a certain level of precision (I think it might be 4). All we want is for our real MtGox balance to be exposed through the interface. Without that, we can't withdraw our entire balance. If it says 80 bitcoins, but rejects our request to withdraw 80 bitcoins, how are we to know that we really need to ask for 79.9775? |
|
|
|
"Transactions are free now, in the future free transactions may become slower as transactions with fees will be given priority."
Somehow that sounds like "Bitcoin is great right now, but in the future it will be slow and expensive." Why not keep it simple and honest and just say "Most Bitcoin transactions are free." Overall, it's a very well-written piece. |
|
|
|
I suppose I should just floor the amount displayed. No, you should display the actual balance. If the real balance has three digits after the decimal, you should show three digits. |
|
|
|
|
Show Posts
