|
Not relaying "smelly" blocks is a very interesting idea.
It doesn't have to be a binary relay/don't relay... you could immediately relay good blocks but wait a while before relaying bad blocks, and make the length of time you wait to relay based on how bad you think they are (maximum of maybe 10 minutes before you relay).
But... not relaying new blocks immediately might just encourage the bad guys to try to connect directly to as many nodes as possible, and that could be bad for network health.
|
|
|
|
If you can get 15%, well 51% is only about 3.4 times as hard.
Check your math-- to get 51% you'll need to dedicate six times as much hardware to hashing as it takes to get 15%: The formula for what fraction of existing hashing power you need add to get X% of the network is: To get 15%, you need to add 17.6%. E.g. if existing hashing power is 100, then you add 17.6 more and your fraction is (17.6/117.6) = 0.15. To get 51%, you need to add 104%. E.g. if existing hashing power is 100, then you add 104, then your fraction is (104/204) = 0.51. 104 is six times as much as 17.6. |
|
|
|
|
I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.
It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify. etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.
If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.
|
|
|
|
The more I think about it, the more I realize that this workflow is possible without P2SH: it's also possible with simple elliptic curve multiplication. Smartphone generates a stream of key A's from a seed, computer generates a stream of key B's, and given the public keys from the smartphone, the computer can generate the public key for C, which is used as the receiving address. Recovery remains the same: two seeds instead of one.
How are signatures created when the phone or computer needs to spend some coins? I'm told it IS possible to break a single ECDSA key in half and then have a complete signature generated without either device ever knowing the entire key, but, if I recall correctly, the solution involves several communication round trips between the devices and some very sophisticated cryptography. The multikey solution is much simpler. If I'm wrong, then great! The single ECDSA key solution will get adopted for wallet security and multisigs will only be used for escrow. RE: makku's question "How do you identify transactions that belong to you in the first place?" I think it is wrong to think of coins involved in a multiparty multisignature transaction as "belonging to you." They don't belong to you-- you have to agree and cooperate with other keyholder(s) for the transaction to be spent. You are involved in the transaction, but you need some extra information that isn't in the blockchain to know how you are involved (are you an arbitrator? a person getting paid? a person paying somebody? something else?). |
|
|
|
How long do you plan to keep the fix "secret" and what's the deadline for making the vulnerability public?
We'll release full detail tomorrow (Monday) at 16:00 GMT, after essentially the entire world has had a chance to go into work Monday morning, see the alert message, and shutdown/upgrade. |
|
|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A potential security vulnerability has been discovered in the Windows version of Bitcoin-Qt. If you are running Bitcoin-Qt versions 0.5 through 0.6 on Windows you should shut it down and upgrade to either version 0.5.3.1 or 0.6rc4 NOW. The command-line bitcoin daemon (bitcoind), Mac and Linux versions of Bitcoin-Qt, and versions prior to 0.5 are not affected. Due to the nature of the vulnerability, we believe it would be very difficult for an attacker to do anything more than crash the Bitcoin-Qt process. However, because there is a possibility of such a crash causing remote code execution we consider this a critical issue. Binaries are available at SourceForge: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/If you have questions, feel free to drop by the #bitcoin-dev channel on FreeNode IRC. - -- Gavin Andresen Gregory Maxwell Matt Corallo Nils Schneider Wladimir J. van der Laan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/iEYEARECAAYFAk9j12IACgkQdYgkL74406iIyQCfbxFTO3yD4Q2bHDjPlDuJn3Mj 9GAAn3mV+ggo+5q1Ujd0A5zwpFYojkE2 =g1Ad -----END PGP SIGNATURE----- |
|
|
|
I don't see a point in "officially" depreciating something that must be supported forever anyway.
I agree. |
|
|
|
|
Testnet is healthier now, although you'll need to run latest 'git HEAD' to be on the right chain. Thanks to everybody who threw some hashing power at it to outrun the bad, old-rules chains.
|
|
|
|
Stay tuned: the testnet is a mess right now. Another genesis block reset might be needed to fix it, there have been several blockchain-splitting changes and there are several different versions of the blockchain competing (with/without the difficulty change, with/without the duplicate coinbase change, and with/without BIP16 support). In the meantime, testing with a testnet-in-a-box or private testnet is a good way to go: https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/ |
|
|
|
|
There have already been several "transaction spam" attacks; as already pointed out, transaction fees keep them from being a big problem.
The code also limits the number of free transactions that are relayed across the network, so you can't flood the network with transactions that will never get mined.
Smarter denial-of-service attack prevention code has been a major unseen feature of the last couple Bitcoin releases.
|
|
|
|
Are the rc1 OSX CPU bug(s) fixed in this release?
Yes, fixed in rc2. |
|
|
|
|
Bitcoin doesn't install Growl-- something else must have in the past.
PS: there is an open bug in the 0.6 release that it is not compatible with some versions of Growl; if that isn't resolved Growl notifications might be completely disabled.
|
|
|
|
|
PS: The 'accounts' feature doesn't scale well past a dozen or two accounts each with a few hundred transactions. It could (need to add some indices to the database so looking up transactions by account and/or time is quick), but doing that work hasn't been a high development priority.
|
|
|
|
You should be able to build your GL on top of the accounts feature of bitcoind. The 'validateaddress' RPC call will tell you the account associated with an address and whether or not it is an address that belongs to you or is external. Combined with the 'sendfrom' and 'setaccount' RPC calls, you should be able to create a proper general-ledger-type application where all transactions have well-defined "from" and "to" accounts. Example of one way to do it using my testnet-in-a-box setup: 1. Create a couple of accounts: ./bitcoind -testnet getaccountaddress "cash"
# ... send some coin to the "cash" account from ... somewhere ...
./bitcoind -testnet setaccount mzDfbJCELPQzHMjJ6ZLFRUxT51FdKezbEZ "hosting_expenses"
# the mzDfb... address would come from my web hosting company, of course
2. Now pay for web hosting out of "cash" ./bitcoind -testnet sendfrom "cash" mzDfbJCELPQzHMjJ6ZLFRUxT51FdKezbEZ 10
3. All the information about the transaction (from and to accounts) is available, but you'll need 2 RPC calls to get it: $ ./bitcoind -testnet listtransactions "cash" 1
[
{
"account" : "cash",
"address" : "mzDfbJCELPQzHMjJ6ZLFRUxT51FdKezbEZ",
"category" : "send",
"amount" : -10.00000000,
"fee" : 0.00000000,
"confirmations" : 0,
"txid" : "53a681fd7f6b2cb542d69cb72d18ca780d42df63fcc00cf46b19499ab75540b3",
"time" : 1331050826
}
]
$ ./bitcoind -testnet validateaddress mzDfbJCELPQzHMjJ6ZLFRUxT51FdKezbEZ
{
"isvalid" : true,
"address" : "mzDfbJCELPQzHMjJ6ZLFRUxT51FdKezbEZ",
"ismine" : false,
"account" : "hosting_expenses"
}
The GUI has no notion of a "sendfrom account", so any coins send from the GUI won't play nicely with whatever system you create using the RPC interface. The expectation is the vast majority of GUI users won't go to the trouble of creating a general ledger system to keep track of where their bitcoins are coming from and going to. |
|
|
|
But this would just affect the client program that users download, so some people would be downloading some random program that could do harmful things to their computer, yes?
That is always a risk, which is why next to the downloads there is a gpg-signed SHASUMS.asc file. To check the integrity of the download you should: + Check the signature on the SHASUMS.asc file: $ gpg --verify SHASUMS.asc
gpg: Signature made Wed Feb 29 20:51:40 2012 EST using RSA key ID 1FC730C1
gpg: Good signature from "Gavin Andresen (CODE SIGNING KEY) <gavinandresen@gmail.com>" + Make sure the checksum for the downloaded file matches the checksum in the SHASUMS.asc file: $ shasum bitcoin-0.6.0rc2-macosx.dmg
7ab035250ad32a95adf12f2bf8751df9adae0ad4 bitcoin-0.6.0rc2-macosx.dmg
$ grep macosx SHASUMS.asc
7ab035250ad32a95adf12f2bf8751df9adae0ad4 bitcoin-0.6.0rc2-macosx.dmg
|
|
|
|
On edit: as indicated above DUH the blockchain. Close enough for this work and nearly impossible to spoof at least economically.
I was thinking of a kind of replay attack: + Control the TPM's view of the world (e.g. make it seem like it is Jan 1, 2010) + Get the TPM to sign a small transaction, shut it down. + Increment time, get it to sign another transaction + Repeat. Replace "time" with "blockchain" and you've got the same problem: can the TPM know that it's view of the external world is correct? If it sends a nonce (to prevent replay attacks) to some external service that adds a timestamp and signs it with a public key known to the TPM code... then we're back to using two different servers. |
|
|
|
Great ideas, Mike. I think the "use two servers" approach will happen first (you typically want at least two servers anyway just for backup and redundancy), but trusted code running in a TPM could be an extremely powerful and cost-effective building block for much more secure solutions. RE: How do you abstract and simplify the techniques needed to track external state. For instance, a pool server needs to track who is owed what payouts. Even if an attacker can't compromise the wallet, they could submit bogus payment data to the monitor and trick it into signing away its money. The monitor could potentially store and manage the entire database itself, but there are often better ways. The trick is to make them simple. This is a problem shared with the multi-server approach. Common design patterns would help a lot.
That seems like the hardest problem. Does the TPM have access to a guaranteed-to-be-unhackable time source? If it does, then a policy like "do not approve more than X bitcoins worth of transactions in timeperiod Y" should work well enough to prevent more than petty theft, assuming you've got some other way of watching the blockchain for unauthorized transactions and shutting down the compromised machine or using an emergency offline backup key to move the funds to a non-compromised wallet. |
|
|
|
|
RE: tx replacement:
Somebody aught to start experimenting with transaction replacement with testnet-in-a-box.
Put together a test plan, modify the code and try to break it.
Assuming it all works, submit a pull request to enable transaction replacement on testnet (with a pointer to your test plan and results of testing, please).
Then we can start trying to break transaction replacement on testnet; again, assuming no bugs/hacks/issues turn up after "enough" testing, and if there's general consensus that the benefits outweigh the risks, it could be rolled out to the production network.
We just pulled a DoS fix involving filling up memory with orphan transactions; one concern with transaction replacement is DoS (could I fill up the memory pool by spamming "will be replaced" transactions?)
|
|
|
|
|
Show Posts
