|
I would be trivial to add a JSON-RPC command to do that. Just use the IsValidBitcoinAddress function.
|
|
|
|
If you wanted to do that, it'd probably be best to modify rpc.cpp and deal with nValue directly. The recipient doesn't need to do anything special to receive the coins, though they'll probably end up throwing away most of the additional (sub-0.01) bitcoins. You'll also be throwing away coins, but probably more frequently -- you might lose a lot of them this way. You could eliminate losses from dealing in sub-0.01 bitcoins (for yourself) by improving the way Bitcoin chooses which coins to send. It currently doesn't try to avoid the "dust change" situation, so it happens randomly. |
|
|
|
(The bitcoins themselves can't be reproduced.) Your password, key shape spec or bitcoin keys are not property but the stuff in the safe and the bitcoins are. Morally and in any reasonable legal system.
It doesn't make sense. Bitcoins are only a sum that the network agrees belongs to some person. There are no contracts between any participants, so why should it be illegal for someone to cause these independent entities to change their mind about who the coins belong to? |
|
|
|
So are the bitcoins in my wallet real property?
No. The data in your wallet can be freely reproduced, so it is not real property. The password to a physical safe or the exact specifications of a physical key would not be real property, either. |
|
|
|
Since it is possible to detect majority of all nodes in the p2p network by visiting the bootstrapping irc channel, it seems fairly easy to determine where exactly all the nodes are in case any attempt to disconnect Internet, seize hardwares or some other action ever occurs. Is this something to be concerned of? For example, I can determine all the IP addresses of p2p nodes available and then proceed from there. All non-darknet P2P networks have public lists of participants. Tor publishes a list of all relays (except bridges) to the directory servers, I2P floodfill routers maintain RouterInfo data, Freenet has seednodes (in OpenNet mode), Gnutella has GWebCaches, etc. If an attacker wants to target every public user, nothing can stop them. Every Bitcoin user could use Tor hidden services to communicate, but this would be even worse than the current situation, because then someone would have to destroy only the single Tor hidden service authority to bring down the network. Generators will always need to be located in free countries. Clients can use Tor and/or connect to only a few generators. |
|
|
|
|
The archive should be excluded from search engines.
|
|
|
|
|
Anything that is being used as a medium of exchange is money. Bitcoin, like gold, is money.
|
|
|
|
|
A hyperinflation would be the perfect time to advertise Bitcoin as an alternative to USD. I hope they start printing a trillion every day.
|
|
|
|
Thanks theymos! That's exactly what I was wondering. How did you do that? Was it with the 'bitcointools' that gavinandresen mentioned?
I output the most recent 10,000 blocks to a file (using the getblock patch) and then searched it for the hash (b5a1946b3...), which is derived from the BC address. This took only a few minutes once I figured out how to get the hash from the address. Tracking spends from that address would be more difficult, since you can't get the full public key directly from the address. Making an easy-to-use web tool for doing things like this has been on my to-do list for a long time. People really seem to overestimate Bitcoin's anonymity... |
|
|
|
Cool game! I won 2 BTC!  I would have liked to use something publicly verifiable for the hash used in determining the outcome rather than the payment info plus timestamp hashed that I ended up using, but couldn't find if there is such a thing for each payment. Nothing like that exists. The user knows the entire transaction before everyone else does, and nothing is ever added to it by other nodes. The info+timestamp system probably isn't secure, either, since you can guess most of this info. Just use a random number. If someone wants to verify your honesty, they can look at the randomness of the results. would it be possible to see the results and then spend the coins again to another account if they didn't like the outcome? It's possible. Worst case: - Attacker sends the first transaction only to you. - You accept the transaction and relay it to your eight peers. - Attacker doesn't like his results. He creates a double-spending transaction back to himself and sends it to 5,000 peers. - Attacker is very likely to reach more nodes than you will, and will therefore probably win. The attack is made much more difficult when the attacker can't connect directly to you (which he can't in your case). A 10-second delay between accepting the transaction and showing the result would nearly eliminate the attacker's chance of beating you. You can also run Bitcoin with -maxconnections=100 to increase the number of peers you'll relay transactions to, which will improve your chances. See this thread. And finally is there some way to read the status on outgoing payments back from bitcoind? I believe the listtransactions patch can do that. You can't do it with stock bitcoind, AFAIK. |
|
|
|
You cannot pay transactions fees on one fork with coins from another afaik. You can build a separate currency system on top of the Bitcoin block chain, paying fees in bitcoins while transacting in another currency. This is a good idea for niche currency systems, since running their own chains would put them at risk of being attacked by people with a lot of CPU power. Transactions made in an "offshoot" currency couldn't be checked for double-spending by the Bitcoin network before being inserted into a block. This doesn't affect security if the offshoot clients are designed correctly (AFAIK), but it would make it impossible for offshoot clients to use an abbreviated block chain, which might be a problem once it takes weeks/months to download the full chain. |
|
|
|
22 transactions were made to the address Ground Loop mentioned: "value" : "0.10000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "9.90000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "0.10000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "50.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "0.10000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "50.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "0.01000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "0.06000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "0.06000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "50.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "50.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "5.35519824",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "5.35519824",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "5.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "5.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "50.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "50.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "5.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "10000.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "5.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "5.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
--
"value" : "5.00000000",
"scriptPubKey" : "OP_DUP OP_HASH160 b5a1946b352902aef52a059836bc7b8a44af0910 OP_EQUALVERIFY OP_CHECKSIG"
|
|
|
|
|
I would buy/sell via WU (or wire transfer), but I don't think it would be economical after accounting for the fees.
|
|
|
|
My problem is this: the 0.01 fraction is also increasing in value over time, and there is no mechanism in place to adjust this value downward to some other smaller fraction without introducing a major upgrade to the whole network... and version conflicts if and when this value needs to be adjusted downward. There won't be any conflict if the limit is lowered in a new Bitcoin version. Transaction fees are totally up to individual generators; the network doesn't care what you charge. If you modify Bitcoin to never charge any fees, then the 0.01 limit will be eliminated for blocks that you create, and every other Bitcoin client will still accept your blocks. This fix is also not enforced by the network. |
|
|
|
|
Once DNSSEC is working, it'll be possible to securely put your cert's fingerprint in DNS. Then only people you're actually doing business with -- ICANN, the TLD registry, and your registrar -- will be able to compromise your site's encryption (at great risk to future trust from customers). Right now an attacker needs to control only one of several hundred root CAs (plus an unknown number of sub-CAs), but with DNS-based authentication, they'd be pretty much limited to the registrar (ICANN and the registry aren't likely to give in easily).
|
|
|
|
I don't trust CACert's security, so I don't allow them to hijack all of my TLS connections (which adding them as a CA does). I've removed a few dozen built-in certs in Firefox because I don't trust those companies (GoDaddy is a commonly-used one that I've removed). There's no harm in MyBitcoin using CACert, though, since I can just treat their specific cert as self-signed and allow it. StartSSL would probably be better, since it's accepted in most browsers. You can get FF to do this by mucking with the preferences and a plugin called "Certificate Patrol". Certificate Patrol only monitors certificates that have already been accepted by the browser. Firefox's handling of untrusted certificates is poor -- I frequently get vague errors about untrusted certs (with no information about which cert is causing the trouble), and it's impossible to autoupdate if you don't trust certain CAs. |
|
|
|
|
You could use your Bitcoin keys for authentication, but ECDSA doesn't support encryption.
|
|
|
|
I still have the address and key, so shouldn't the transaction be replayed when I parse all blocks again? Due to a bug or an attack on the network, blocks might be rewritten. Honest generators will rebroadcast your transaction for you if this happens, but this system might break down as well. It's very unlikely, of course, but you might want to account for this in situations requiring very high security. I wouldn't bother with it if I were you; I just wanted to mention the possibility. The means by which transactions get transported are the blocks, right? There's no out of band communicating of transactions between clients? That's right. |
|
|
|
You could attach an already encrypted text to it, right?
You could, but any MITM could modify it / steal your coins... |
|
|
|
|
Show Posts
