There's an "-rpcallowip=" switch in SVN, which allows you to access RPC from the specified IP addresses. This is not safe from MITM attacks, however.
|
|
|
But really do you actually have to logon to another computer on the LAN You don't have to log in. I just meant that you and the recipient need to be on the same TCP/IP network. Then just -connect to each other. You could also do this over the Internet, though I don't know why you wouldn't just use the Bitcoin network if you have Internet access. My x-btc URI scheme supports encoding transactions, which would work for sending them over Jabber. Like this: x-btc:rawtxn=-b602XR4AAAAAAAAAAAAAAEBAACnisLtAQAAAAES6XDE51AD_pYhTZODDyPD_GjmmAYan2xWh7GDOI4TCwAAAACKRzBEAiAXOUBjGZND6nrLDYE-y3_N1WGVlgL1zD_m4LIhZH9ZdQIgFDSSsM5UZsRpT8ZXX0hXBKxCrLA8afGzgk-bNqdTYRwBQQTmNw7nZNxJlGWCRBEnytR8_NgSU_oUkMnvKLkW-1xtaClPJydcBEm49cf0d0nj-PV6yUtNU0YyVMgxa-9Mf1XA_____wIA4fUFAAAAABl2qRSCBUpR68uXfcAIpPacDqhzd208_oisQPbTBAAAAAAZdqkUyk5AXdWLHER9M4PtJ8nn5pcXaESIrAAAAAA;store "-b60..." is a Bitcoin network "tx" message encoded in base64url. X-btc is just a specification, so you can't actually use this format for anything right now.
|
|
|
creighto:
You can do something like that right now without even modifying the client. Just connect to someone's Bitcoin client over a LAN and send them a transaction. Both sender and recipient will broadcast the transaction when they get back to the Internet. A double-spending attack is also easily possible without modifying Bitcoin when you do that -- the sender just has to create a wallet.dat backup beforehand and get to the Internet first.
|
|
|
Moreover, there is no reason to include ANY transactions in block at all, except the first one with 50BTC.
Transaction fees...
|
|
|
You could create an additional database file with public keys associated with usernames/passwords. Creating an address logs the resulting public key to the new database (in addition to wallet.dat); CreateTransaction is modified to only select coins from those addresses associated with the account; the various "list transactions" commands are modified to only tally/show transactions to addresses associated with the account; new commands are added to transfer keys from one account to another. You could make it possible to transfer funds (without the keys) from one account to another without a real transaction, but this would involve much more complexity.
Implementation wouldn't be too difficult, I think (if you don't have to deal with the UI). The worst part would be dealing with the new database file and figuring out how to replace the existing authentication with your own stuff.
|
|
|
I also don't see how bitcoin could be used as a captcha, those are used to make sure there's a human on the other end and not a spam bot...you could easily automate the payments. For this niche, it's paying for high bandwidth, concurrent downloads of pirated content; it just won't work otherwise IMO.
Bitcoin can't prove that someone is human, but requiring a very small payment for each "dangerous" action is perfect for preventing abuse.
|
|
|
Non-generating nodes don't know the current block size you mean? Even generating nodes don't know what the current block size will end up being, so I don't think that's much of an issue. Non-generators do know the size of recent blocks, so they can guess about as well as generators.
Generators use the size of their own temporary block, which is likely to be very near the actual blocksize. Non-generators always assume the blocksize is 1 kB. Satoshi has said that non-generators will look at recent block sizes if it becomes a problem.
|
|
|
BTW how do recently connected nodes get all transactions that should be included in the block even that which were broadcasted before these nodes connected? Do they ask their peers or are there periodic rebroadcasts?
You don't get old transactions. You don't need them. Someone who knows about the old transaction will generate a block with it eventually. If the entire network forgets about the transaction, the sender and receiver will rebroadcast it.
|
|
|
I have been thinking that the best way to start a regime of anarcho-capitalist protection agencies (other than seasteading) is to start companies that protect you from the government in various ways.
Since "payout" is expected to be rare for at least a while, the fee should be low. I might be interested in joining -- I wouldn't be surprised if my Bitcoin trading violates some law or other. I am very sick of worrying about whether my activities are legal...
|
|
|
I expect the rate to go down on the medium-term (3-6 months). Only a small percentage of the bitcoins in existence are being actively traded, and a great number are known to be owned by people (not lost). I also suspect that the rate of inflation is greater than what the market can absorb.
|
|
|
It's possible. Bitcointools can give you the public/private keys (you need to adjust it to show the non-abbreviated keys), but you'll have to do insertion yourself. See AddKey in main.cpp.
|
|
|
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...
|
|
|
|