So which one is valid? Who cares. Flip a coin. That is exactly what bitcoin does in this situation. If my node is working on a block with on transaction, and your node is working on a block with a conflicting transaction, whoever solves the block first wins.
Now I'm confused again. I thought your scheme didn't have blocks, just transactions. What do you mean, whoever solves "the block" first? By the way, standard DHTs already address preserving data when nodes leave, and spreading the data when nodes join. But standard DHTs are typically used to store chunks of MP3s or movies, indexed by a torrent file that has the hash for every piece. So it is easy for me to tell whether or not I'm getting bad data from any particular DHT node. I don't have to trust them. Nodes would generate node addresses based upon private keys, exactly as is being done for bitcoin addresses. This makes node spoofing implausible.
Huh? Lets say the network has 10,000 nodes in it. I query the network to find the network node closest to a transaction that I want to double-spend. So I generate a private key. It has about a 1 in 10,000 chance of being closer than the current closest node. So I keep generating private keys until I have 5 that are closer. It's too late for me to figure out the odds, but lets say I generate 100,000 private keys, I'm pretty darn likely to find 5. My wimpy laptop can generate at LEAST 100 ECC keys/second, so in under 20 minutes it could generate 100,000. I create 5 nodes with those keys (telling the rest of the network "honest, folks, I chose those keys RANDOMLY...") and I've won. All of the inputs to the out-point hash are fixed except the payee, which is pre-specified. The only flexibility I can think of would be in the payment amount. If you want to iterate through all possible amounts and try to create a simultaneous 5 way hash collision, knock yourself out. I'm not trying to generate a transaction with a particular hash, I'm trying to generate node ids that are "closer" to that transaction's hash than any other node currently on the network. That's much easier. |
|
|
|
So for any new transaction, to verify it, you send it to the five closest nodes to each in-point on the transaction. They record the transaction and immediately tell you if they've seen a double spend. If any have, it's a bogus transaction, which gets broadcast to the other close nodes.
What happens when they disagree about which transaction happened first? Majority rule? Who decides what the majority is, and can it change if 4 of the five nodes leave the network and are replaced by another 5 nodes? And if I know that I'm going to create a large transaction, can I do some work precomputing node IDs such that the transaction (which I haven't yet sent out) will hash to nodes that I control? If I control all the nodes storing the transaction, then I can just answer "yes, absolutely, that transaction is valid and hasn't been double-spent..." The brilliant insight behind bitcoin is the distributed timestamping mechanism; everybody agrees on an order of transactions. I don't see how your scheme solves that problem. |
|
|
|
Some random Friday afternoon brainstorming: could you print out bitcoins to function as user-created paper money? QR code could be used to encode a transaction hash and a transaction signature on a piece of paper (along with a human-readable amount). A bitcoin client could print out coins that are in your wallet and marks them as "PRINTED" (so you don't accidentally spend them-- there would probably be a way of recovering them in case the paper versions were lost or stolen, and they'd automatically get removed when the paper versions were spent). Give that piece of paper to a merchant connected to the Bitcoin network and they can scan it and transfer the coins into their wallet. They should then destroy the paper, because that transaction is spent. Double-spending would be nearly impossible, because once you give the paper to the merchant you lose control over exactly when they submit it to the network to be verified. The only problem I see is how the merchant gives you your change. The merchant could print out the change, but you'd have to trust that they were giving you valid, unspent coins, unless you have a device connected to the network that could verify them (but that's dumb, because if you do have such a device why bother with paper bitcoins?). We trust merchants not to give us counterfeit dollars... I wonder if fear of loss of reputation would be enough to keep them honest when giving paper bitcoins as change... |
|
|
|
Bitcoin could be made into a truly distributed system by storing the transaction graph in a distributed hash table. This is the kind of magic that is behind most other P2P systems. In effect, each bitcoin address would be arbitrarily mapped to a smaller set of nodes that checked its transactions. In such a system, there is no need to broadcast global state to every machine. This takes huge amount of latency out without needing to change any of the desired behavior.
Interesting idea. So, lets see, I create a transaction to pay you (say) 100 of my newly minted bitcoins. That'll be a transaction with two 50BTC TxIns (signed by me, pointing to two mature GENERATE transactions somewhere in the block chain) and one 100BTC TxOuts. You want to make sure I haven't double-spent those TxIns, so instead of flooding the network with that transaction you find the hash of the two GENERATE transactions and send two queries down into the DHT network: "Hey, here's a transaction, tell me if it is valid." They say "yup", and then... what? Include it in any blocks they're lucky enough to generate? Broadcast it to everybody (which'd be no better than the current scheme) or some subset of the DHT network (what subset?)? How do you know that you won't get a different answer to "is this transaction valid" if you ask again in 10 minutes when the network topology might have changed? I don't know much about DHT networks and how they manage to keep reliable information when nodes may be coming and going (or buggy or malicious). How would it work? |
|
|
|
So I send a transaction of .001 BTC from me to Fred and .000001 BTC from me to A. I send a different one to B and C.
Now A, B, and C cannot make a profit by sending that transaction for anyone else to crunch on so if they want to collect they have to process it.
The trick is enforcing the rule that 0.001 only flows from me to fred once and not in each block.
I'm thoroughly confused on what, exactly, you're proposing. I want to make a 100 Bitcoin transaction to you. You're proposing that I need to pay a "transmit fee" ... which is paid to who and does what, exactly? If I pay it to A, B, and C, does that mean they rebroadcast the transaction to everybody they're connected to? Do they, in turn, pay transmit fees to the nodes they're rebroadcast it to? What stops them from saying "Thank you very much for the transmit fee" and cheating (drop my transaction on the floor)? Satoshi's proposal that all transaction carry a minimum fee to cover network overhead makes sense; whoever generates the block with the transaction gets the fee. |
|
|
|
|
Ummm, the command-line RPC is implemented on top of the JSON-RPC mechanism.
So if the command-line RPC is working on your machine, then the JSON-RPC is, too.
|
|
|
|
In a market based society there is only relative wealth. Bill Gate is not rich because he has 40 billion dollars. He is rich because we all don't have 40 billion dollars. If we did all did the "average" house would cost 100 billion dollars and we'd all still have mortgages.
Hah! While I was typing this, Kiba said essentially the same thing... We are all rich because we have computers and the Internet and Wikipedia and other wonders the world has never seen before. There is absolute wealth. We are healthier and wealthier and live longer than any previous generation, and that's a wonderful thing. |
|
|
|
This is a nice exercise in what happens when you give free stuff away.
Hint: People try to get the free stuff.
I do think it's a nice idea, I'm not saying you shouldn't do it.
Yeah, I shoulda anticipated problems when Bitcoins went from 0.005 USD each to 0.06 each. If it takes somebody two minutes to go through the "get a new IP, get a new BC address, solve the captcha" process then they'd make 5*30=150 bitcoins an hour, which is $9 USD an hour, which, if you're unemployed, bored, and/or 13 years old is easy money. |
|
|
|
|
Thanks for all the ideas!
First: I'm definitely going to drop from 5 BTC; I think I'll go all the way down to 0.50 BTC (rather than do 1 or 2). Giving away a percentage of how much the faucet has is an interesting idea, but I want it to be as simple as possible.
Second: I really don't want to make getting coins from the Faucet a whole heavy-weight "register and check your email and yada yada yada."
But I do like the idea of adding an extra hurdle for 'suspicious-looking' behavior. So I'm leaning towards doing some fuzzy browser fingerprinting combined with rate-limiting and, if you look suspicious or the fountain has been giving away a larger-than-usual number of coins, require that you login with your google account before getting any coins. No google account: no coins.
It is hard to create lots of google accounts; they're requiring either phone or SMS account verification these days...
|
|
|
|
I just shut down freebitcoins.appspot.com; it looks like somebody in Spain is being a jerk and getting a new IP address, bitcoin address, and solving the captcha. Over and over and over again: 79.154.133.217 - - [04/Aug/2010:12:46:55 -0700]
"POST / HTTP/1.1" 200 1294 "https://freebitcoins.appspot.com/"
"Opera/9.80 (Windows NT 6.0; U; es-LA) Presto/2.6.30 Version/10.60,gzip(gfe)"
79.146.112.13 - - [04/Aug/2010:12:45:20 -0700]
"POST / HTTP/1.1" 200 1294 "https://freebitcoins.appspot.com/"
"Opera/9.80 (Windows NT 6.0; U; es-LA) Presto/2.6.30 Version/10.60,gzip(gfe)"
81.44.159.81 - - [04/Aug/2010:12:42:20 -0700]
"POST / HTTP/1.1" 200 1294 "https://freebitcoins.appspot.com/"
"Opera/9.80 (Windows NT 6.0; U; es-LA) Presto/2.6.30 Version/10.60,gzip(gfe)" Those IP addresses all map to Telefonica de Espana. If it was you: give them back, please: 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC Now that 5 bitcoins is worth a fair bit, I'm thinking I need more cheating countermeasures. I can think of four things to try: 1. Rate limit based on the first byte of the IP address (79. or 81. in this case). 2. Rate limit based on the USER-AGENT string ("Opera/9.8..." in this case). 3. Rate limit based on last two domains of reverse DNS lookup of the IP address (rima-tde.net in this case). 4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone up 10 times in value since I started the Faucet). If you get rate limited, you'll get a message that asks you to try again tomorrow. BitcoinFX: thanks again for the donation to the faucet; I'm going to drain the Faucet below 500 coins temporarily, and will refill it with your donation after the new cheating countermeasures are in place. |
|
|
|
The 1 BTC transaction is a transaction with 1 input and 2 outputs, but it's still only 1 transaction.
The rule is "if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee": main.h:
foreach(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = CENT;
|
|
|
|
Well, right now nothing stops someone from creating a system where:
A sends 1.00000001 to B
B sends 1.00000000 back to A
Net result is a micro-payment and no processing fee.
... unless B started with zero bitcoins. Then B is stuck; she can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin 'change' transaction, which would trigger the 0.01BTC fee, which they can't pay (because they only have 1.0000000001). |
|
|
|
The two JSON RPC libs available at CPAN (Perl), and a compliant C lib that I wrote locally to verify the behavior.
Perl's LWP module definitely sets the Content-Length header. I would've been surprised if it didn't, since it is required by HTTP 1.0 and the HTTP 1.1 spec says clients 'SHOULD' set it. After some struggle, I got the first JSON::RPC library at CPAN to work: use JSON::RPC::Client;
use Data::Dumper;
my $client = new JSON::RPC::Client;
$client->ua->credentials(
'localhost:8332', 'jsonrpc', 'my rpcusername' => 'my rpcpassword' # Replace with real user/pass
);
my @foo = $client->ua->credentials('localhost:8332', 'jsonrpc');
print "@foo\n";
my $uri = 'http://localhost:8332/';
my $obj = {
method => 'getinfo',
params => [],
};
my $res = $client->call( $uri, $obj );
if($res){
if ($res->is_error) {
print "Error : ", $res->error_message;
}
else {
print Dumper($res->result);
}
}
else {
print $client->status_line;
}
The struggle was setting the realm to 'jsonrpc' (it is fussy about that). I'll document that on the wiki. |
|
|
|
bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it. When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.
Can you be more specific about which JSON libraries don't provide Content-Length ? It'd be nice to document that. |
|
|
|
I am also not saying it is a good thing. having a single split for a fairly long period of time lets people come up with a solution, having many splits that each last for a few hours means that transactions randomly disappear and that hurts confidence in the system.
Transactions won't disappear if they're valid. They'll just move to the longer block chain. Invalid transactions would be somebody trying to double-spend across the split chains (which would be tricky-- you'd have to run a modified client, or copy your wallet to a machine working on the other block chain). Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge. For shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat). |
|
|
|
I would like to enable users to create other custom assets. The asset would have a globally unique hash and could ben sent / recved to addresses. For example, a company could issue "shares" that could then be exchanged and verified by bitcoin. A game engine could issue its own type of currency and have it tracked.
Is anything like this even remotely possible with scripts or would that require a breaking change? Is it even possible to 'upgrade' the network to support such an option at this point?
I don't think you need scripts to do something like that. Just send a bitcoin to yourself, and then declare that transaction is the "root transaction for My Valuable Asset." You'd need a custom client that only accepted or spent transactions that could be entirely traced back to that Root Transaction (not hard, all transactions can be tracked back). And shows fractions of that coin as units of your custom currency. And you'd probably want to make some other changes so your users didn't accidently (or purposely) mix Your Valuable Asset coin with regular bitcoins (like a custom wallet and different scheme for generating payment addresses). |
|
|
|
Shouldn't it be able to fix itself without having to delete the block data?
As long as everyone with an 'old' client stops generating, the bad fork should get shorter and die?
Just checking my understanding.
Yep, you're right. The good fork is longer than the bad one now; the last ORPHAN BLOCK my TEST bitcoind got was about 20 hours ago. |
|
|
|
svnTEST branch is up on github. I also uploaded just the production-bitcoin-to-TEST-network-bitcoin patches to github, at: http://gist.github.com/502460... so: curl http://gist.github.com/raw/502460/2182724de9ef2d6721bf0e0962cc6a6895bcbee4 | patch -l ... should patch production network source code to TEST network. And: curl http://gist.github.com/raw/502460/2182724de9ef2d6721bf0e0962cc6a6895bcbee4 | patch -l --reverse ... will go the other way. |
|
|
|
|
That IS part of the new -port / -rpcport code (I use boost::interprocess::file_lock to make sure bitcoins running on different ports don't try to use the same wallet/blkindex/etc files).
I'll create an svnTEST branch that omits those changes, and will always be just a TEST-network version of the latest svn trunk.
|
|
|
|
Cool! Hope you don't mind, I added it to my github network as a 'feature' branch. |
|
|
|
|
Show Posts
