Right, but every TxIn has to have a corresponding TxOut (except for GENERATE/coinbase transactions, but those have their own rules).  So if you want a 0 BTC TxIn, you've gotta first pay yourself with a 0BTC TxOut and that'll trigger the fee.  TxIns don't contain a value, the value is in the corresponding TxOut...


But you agree that it wouldn't be OK for a 'refundtransaction' API call to make it easy to do that, right?

If they are (I didn't see anything preventing them after a quick reading of the code), then they trigger the 0.01BTC micro-transaction fee.

I'll be doing a lot of experimenting (on the TEST network, of course) with refunding transactions over the next few weeks.  I think the UI issue can be resolved (it should be pretty straightforward to teach the UI to recognize refund transactions and show them as "refund from BLAH", where BLAH is either a BC address or a label from your address book.

I've already implemented a "refundtransaction" api call, but it still needs work before it would be ready for standard bitcoin.  In particular, it shouldn't be possible to create infinite 'refundtransaction' loops (where you accidentally or purposely refundtransaction a refunded transaction, probably triggering another refund, etc).

And refunding a transaction should, ideally, use the same "coins" (... should have the same ancestor transactions, for anybody who's going to get all pedantic on me) as the original transaction, if possible, so if that original transaction is exactly as valid as the original transaction.  Otherwise it might be possible to generate a bad transaction, send it somewhere you know it will get refunded immediately with different, valid transactions, and so "launder" your bad bitcoins for good.

Eventually the largest merchants and money exchangers will control what is "standard" bitcoin.

Take the "50-coiners" scenario, and imagine that they manage to get 75% of the CPU power on their side.

But imagine that the biggest merchants and money exchangers are more conservative, and are in the 25% minority.  I think they will be-- I don't think they'll be the ones in the business of generating coins (they'll be busy selling products or doing the exchange thing).

What happens?

Well, the block chain splits.  Transactions using coins minted before the split will get added to both block chains, and accepted by everybody.

Transactions involving "50-coins" (generated after the split) will be accepted on the 50-coin chain, rejected on the 25-coin chain.  And vice-versa.

"50-coiners" would quickly find out that they couldn't get rid of their newly minted money because who wants bitcoins that are rejected by the biggest money exchangers or merchants?

If the big merchants and money exchangers disagreed, I bet you'd see Bitcoin clients that ONLY accepted pre-split coins and did no coin generation (since those transactions would be accepted by everybody).  If it was never resolved, I think the number of Bitcoins at the time of the split would become "the number of Bitcoins, period,"  because most people will not want to use money that is accepted some places and not others.

Sure, in exactly the same way the existence of credit cards motivates behavior of stealing credit card numbers from innocent credit card users.

Or the existence of bank accounts motivates hackers to try to break into your system to find out your bank account number.

Or the existence of cars motivates some people to steal gasoline from innocent service station owners.

I believe the benefits of Bitcoin will outweigh the harm, and I further believe that I am capable of making that moral judgment.  I might be wrong, and I might regret I ever got involved, but if I only ever did things that I was 100% certain were going to work out for the best I would never accomplish anything new and interesting.

No, not at all.  Like I said when I jumped into this thread, I think using a DHT network to somehow distribute the work is a very interesting idea, it just seems to me any solution that partitions the network will be more vulnerable to attacks that insert malicious nodes.  I think it would be fantastic to come up with less resource-intensive solution that actually works.

How does Freenet generate node IDs?  The only info I see in the latest Freenet paper is:
.... and:...which doesn't sound like it would work very well for Bitcoin.

Now I'm confused again.  I thought your scheme didn't have blocks, just transactions.  What do you mean, whoever solves "the block" first?

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.

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.

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.

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...

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?

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.

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.

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:

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 rule is "if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 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).

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:
The struggle was setting the realm to 'jsonrpc' (it is fussy about that).  I'll document that on the wiki.

Can you be more specific about which JSON libraries don't provide Content-Length ?  It'd be nice to document that.

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).