There will be 2.1 quadrillion satoshis. There are approximately 770 trillion pennies in the US M2 money supply. We've got a VERY VERY long way to go before bitcoins are as popular as dollars, and there are much higher priority things to work on right now than adding more divisibility for a problem that is pretty likely to never actually be a problem. |
|
|
|
|
etotheipi:
Sorry, I was responding to the original proposal, not yours, I should have made that clear.
Better protocol support for lightweight clients is a Good Idea.
|
|
|
|
...
within a year or so, only people with a dedicated ASIC (costing $1000+) can mine (even fewer people).
And in two years maybe anybody who can afford to buy an asic-mining-space-heater for their house can mine. And in ten years maybe new houses will come pre-equipped with asic-mining-baseboard-electric-heaters. Or maybe not. Nobody knows what is going to happen, which is why I keep repeating BITCOIN IS AN EXPERIMENT IN PROGRESS. If you can't handle uncertainty and the very real possibility that the experiment will fail, then don't get involved (but don't come back whining that you missed out if the experiment turns out to be a huge success). The thing is that while that the raw hashing power needed to attack the network is growing, the number of miners you need to target by DDOS or otherwise (if you are a malign government wanting to take down Bitcoin) is getting lower by the day!
IMO the 3000 nodes that we currently have seems like an easier target for a well funded attacker than than the prospect of deploying 55,000+ spartan 6 chips to brute-force a 51% attack.
What do you think? Is the chronic decline in hosts a genuine problem for the backbone p2p network?
No, I don't think it is a problem, any more than the relatively small number of "backbone" routers are a problem for the Internet. The bitcoin network is evolving in roughly the direction I expected it would (lots of lightweight clients connecting to a smaller number of heavyweight "backbone" nodes). All of the incentives are for merchants, exchanges, and big mining pools to accept lots of connections, relay only valid transactions and blocks, and be as DoS-resistant as they can afford. Merchants and exchanges want transactions to be validated quickly, the big mining pools want their payouts to be processed quickly and want their blocks propagated quickly, and they all want to be reliable. The big exchanges and mining pools have ALREADY implemented DDoS countermeasures because they have ALREADY been attacked. And the network keeps chugging away, processing transactions.... |
|
|
|
|
Chaining not-yet-signed transactions is impossible because transaction inputs are identified by the previous transaction's hash, and the transaction's hash includes everything about the transaction, including the signatures.
A multisignature transaction taking funds from #1 and paying them to #4 that requires signatures from #1, #2, and #3 should accomplish the same thing, though.
|
|
|
|
|
So code up a prototype:
+ Implement code that computes and publishes 'balance blocks' and 'balance block hashes'. Convince a couple people with extra download bandwidth to run it.
+ Modify one of the bitcoin implementations to download the latest 'balance block' from some trusted place at startup, and use it if transactions/blocks can't be found in the traditional block database.
+ Extra credit/paranoia : query a couple of trusted places for the balance block hash, and make sure it matches the hash you got.
+ OR: randomly spot-check the balance block by requesting blocks in the traditional way, and make sure the balance block doesn't list any outputs as unspent that are actually spent.
You don't want bitcoin address balances, there are no addresses way down deep inside. You need to know which transaction outputs have not yet been spent, and the value of those outputs.
I'm not excited about this proposal, because I think it is solving a problem that doesn't need solving yet, and my priorities for bitcoin continue to be wallet security and network stability, not making it quicker for newbie solo miners to get a full blockchain so they can start validating transactions/blocks.
|
|
|
|
I'm not familiar enough with Satoshi client internals to easily understand what script_tests is doing. Could you confirm my understanding of the format of the two JSON files?
The format is a list of pairs, where the first item is the scriptSig required to spend and the second is the scriptPubKey. The third item is ignored (useful for comments). script_valid.json contains only valid scriptSig/scriptPubKey pairs. script_invalid.json contains only invalid scriptSig/scriptPubKey pairs. valid/invalid are defined by the rules of transaction validation, and the unit test actually constructs transactions and runs the verification routine on them to make sure that they succeed or fail, as expected. |
|
|
|
$ ./bitcoind addmultisigaddress 2 '["0446fc07bc99bef8e7a875249657c65e1f1793fd0bf45e2c39d539b6f8fcd44676acc552ab886c1 1eb08f4a275e7bb7dc4fdaf9c4b2228856f168a69df7d216fbc","04df70eb0107ed08e1ddcd4b4d85d26bf8cca301f5c98fd15f5efef12ba4de72bfef7287f964e30 4207164c003029449740aaae2d6af1ff7ae3f6bb27f3012296c","046003581a3ff5bc3dedaa6da4834ce7bcd49d3f114ce15791f6b5de8b0cec81a46db2eb8cf84d2 db845854c57788c7283ab4040aeb3595bc5c68303a17fdde7c8"]' Works in a Terminal on my Mac, returns: 3EffXJKyYB9zWh2dhx2hcccqBK8DGC7x2x ... which validates as: $ ./bitcoind validateaddress 3EffXJKyYB9zWh2dhx2hcccqBK8DGC7x2x
{
"isvalid" : true,
"address" : "3EffXJKyYB9zWh2dhx2hcccqBK8DGC7x2x",
"isscript" : true,
"ismine" : false,
"script" : "multisig",
"addresses" : [
"1HEmNY7Lpsqc81nP6JAymjGuuvdFLaqt1e",
"1Gpuy32bmhtn3KL6dBDHdTHfMosXRH6xV4",
"1AbU2FDgJRKejuY4e4XGYEfzo6uAGQ1Kyy"
],
"sigsrequired" : 2,
"account" : ""
}
I don't know enough about Windows CLI quoting rules to get ["...","...","..."] passed un-modified to bitcoind.exe. |
|
|
|
Could this be used to attack Bitcoin?
No. Bitcoin connections are TCP, so you can't forge the IP address. I've also implemented denial-of-service checks that automatically ban misbehaving peers to make network disruption attacks more difficult. Trying to anticipate future DoS attacks is hidden engineering work that you will never notice if we get it right. |
|
|
|
Ok, I need to create multi signature transaction.. 2-of-3... What do I do?
Gather (or generate) 3 bitcoin addresses, on whichever machines will be participating, using getnewaddress or getaccountaddress RPC commands (or copy and paste from the GUI). Get their public keys using the validateaddress RPC command 3 times. Then create a 2-of-3 multisig address using addmultisigaddress; e.g. bitcoind addmultisigaddress 2 '["044322868cb17d64dcc22185ae2d4493111d73244c3668f8ac79ecc79c0ba8d30a6756d0fa20157 709af3281cc721c7f53321a8cabda29b77900b7e4fe0174b114","..second pubkey..","..third pubkey.."]'
addmultisigaddress returns the multisignature address. Be a little careful, the public keys are raw hexadecimal and don't contain checksums like bitcoin addresses do. You can then send funds into that 2-of-3 transaction using the normal sendtoaddress/sendmany RPC commands, or the GUI (or anything that's been updated to recognize multisig addresses). That will create a multi signature transaction. If you want to then SPEND the funds sent in that 2-of-3 transaction... that isn't implemented yet (well, if bitcoin has all 3 private keys in it's wallet then the funds will show up in the wallet's total balance and it may be selected to be spent like any other funds received by the wallet). "We" need to implement RPC calls to implement BIP 10 or something like it. |
|
|
|
|
What Pieter said. BIPs are intended to make it easier for different implementations of Bitcoin to inter-operate with each other. The existing network protocol is just one piece of that.
|
|
|
|
|
Bitcoind doesn't run on ppc-- and minimum supported osx version is 10.5.
And Armory depends on bitcoind, right?
|
|
|
|
|
We have been quietly notifying the largest exchanges, merchant service providers and mining pools about this issue, and waited until they upgraded or patched their code to go public with this:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
CVE-2012-2459: Critical Vulnerability
A denial-of-service vulnerability that affects all versions of
bitcoind and Bitcoin-Qt has been reported and fixed. An attacker
could isolate a victim's node and cause the creation of blockchain
forks.
Because this bug could be exploited to severely disrupt the Bitcoin
network we consider this a critical vulnerability, and encourage
everybody to upgrade to the latest version: 0.6.2.
Backports for older releases (0.5.5 and 0.4.6) are also available if
you cannot upgrade to version 0.6.2.
Full technical details are being withheld to give people the
opportunity to upgrade.
Thanks to Forrest Voight for discovering and reporting the vulnerability.
Questions that might be frequently asked:
How would I know if I am the victim of this attack?
Your bitcoin process would stop processing blocks and would have a
different block count from the rest of the network (you can see the
current block count at websites like blockexplorer.com or
blockchain.info). Eventually it would display the message:
"WARNING: Displayed transactions may not be correct! You may need to
upgrade, or other nodes may need to upgrade."
(note that this message is displayed whenever your bitcoin process
detects that the rest of the network seems to have a different
block count, which can happen for several reasons unrelated to
this vulnerability).
Could this bug be used to steal my wallet?
No.
Could this bug be used to install malware on my system?
No.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQIcBAEBCgAGBQJPsTpaAAoJECnZ7msfxzDB76cQALBqcEb40dQOtopbsk7vHDuL
FL4xd56B1/s3idyHGeCuwJX5bgxGD9b3svayXhDiLo9O+5E3sxsLY1HehTXnU8KV
BGpIQ7I+XLDcmarGYrDLMNMDLFOp/1hTipi08X3cr6oHNdYOxGbdtqCQR8xxtdfh
Mmo07ReYYWamlF+QbwoXIJQOEka2UVeWWgmk1C+WW1phI3P3Of5EvWvkmOurZsY1
zew7G3sk0Lu8glxSt8qq1SKlDXOaSqTBPxs+2FtgkUplNrAIyufu0vCTsnC44oie
ndJD6XZAaG6cYr3adGQKmUjRR+oyZarMtBdDHBvYHkrQI4uQclL1aS7DhkLtH8kp
fBRHdqmbBJpmpWOcs+OZeaQCzrArKihuVVZqP4HYbHgGHLV3Ls1bebyWm5eLZH6Z
C5l3B4Hz/lp50gJpVsIZI291l3KWfoBW2qGyQv51U4uByLU8tPzgr5bdyo6YCo4N
XQZHveNInMDI8jSimGyHg7WNm0YjkSAM8PEIJhQuL+RaHKgN/ghLPR+1K1YZnMjq
BPdJZVDpP2bgClyj6P+UkhAplEoenxZUsjyRmcs9EWjHZo3UUI9MLZW96vkR0Wlv
UBgq0/jSNQ6s3U3YwKM8CDFJ4OB7Mu1Ln6sn+Tu5sl3xtPyapARA5K67FYSpvqVX
GNIME8aiNjICQmtIFiuX
=9L8G
-----END PGP SIGNATURE-----
|
|
|
|
|
I'm definitely not in the "speculators are evil" camp. Speculation for the right reasons (hedging risk, for example) is a very good thing.
I personally think speculation for the thrill of gambling is not a good thing, but I'm also not in the "Every Bad Thing (where I get to decide what Bad and Good is) Should Be Illegal" camp. If you want to gamble you should be free to do so; I think it is stupid that we let rich people on Wall Street gamble with other people's money and yet have laws that make it illegal for not-so-rich people to gamble with their own money.
From his post, Tong thought about Bitcoinica and decided that he could be more effective at making the world a better place by working on something else that is more obviously positive-sum. Good for him!
|
|
|
|
|
It seems I touched a nerve when I said that getting better at playing a zero-sum game isn't a good way to make the world a better place.
I was thinking of day-traders at the time; people who don't care what asset they're buying and selling but just try to buy low and sell high to make a profit. Or high-frequency traders who try to be just a tiny bit faster executing transactions to take advantage of tiny inefficiencies in markets.
Probably I don't have a deep enough understanding of the value of liquidity in asset markets or a deep enough appreciation for their role in creating market prices, but it seems to me the world would get along just fine without them spending all their time and effort competing against each other.
I wasn't thinking of competition in general as being a zero-sum game, because in general it is not. Competition drives efficiency, and efficiency (creating more by using less) is what makes the world a better place -- assuming that the thing you're making more efficient has a positive effect on the world. Competing to build the most efficient bomb or assault rifle is not a world-improving activity.
To bring it back to Bitcoin: competition between Bitcoin miners is a zero-sum game for the miners, but if you think that Bitcoin will make the world a better place (I do) then the competition to be more efficient at mining is a net positive for the world as a whole.
|
|
|
|
|
Good luck-- I share your view that coming up with better ways of playing zero-sum games is not the way to make the world a better place.
|
|
|
|
Do you get different answers for 'getbalance' versus 'getbalance "*"' ? There is a longstanding issue with they way unconfirmed transactions are counted that might be the source of your problem: https://github.com/bitcoin/bitcoin/issues/172 |
|
|
|
|
Pieter fixed the "100% usage on OSX bug" and I created and uploaded a fixed version 0.6.2.2 especially for the Mac.
RE: upgrading: the best upgrade practice is to:
1) Backup your wallet someplace safe (if you're running an 0.6 release then use the Backup Wallet menu item).
2) Shutdown. Make sure Bitcoin isn't still in your system tray-- don't just close the window, shut it down.
3) Wait a minute or two (it can take older versions a minute or two to completely shut down)
4) Install and run the new version.
|
|
|
|
|
Over 50 BTC in donations with no fundraising effort-- thanks everyone who has donated so far!
|
|
|
|
|
Show Posts
