Yeah, he's a luddite. Though in his defense I do sympathize with a related sentiment - while it's great when people offer free stuff, it's bad when people demand to be given stuff for free. This dries up the incentives to create high-quality products and services, and the people end up with free stuff worth exactly what they paid for them.

I must have been stuck in a strange wormhole timewarp thingy where what I heard from Simon's talk was different from everyone else. To me it seems he put banks in the same category as killing people and the planet, and criticized their fractional reserve and lending policies.

The "governments buying bitcoins" part isn't that far-fetched. It was the "and then deleting them" that was silly.

<sarcasm>
Congratulations, you've invented a new game - stand with a stopwatch next to newbies and see how long it takes them to become experts in the various intricacies of Bitcoin.
</sarcasm>

This is a hotly debated topic. There are bad pools and good pools but you won't find any consensus about which is which. At this point in time, personally I would recommend eclipsemc.com, yourbtc.net or bitminter.com.

It's not.

It should be about as good as any other software.

Try looking in the "receive coins" tab or "receiving" tab of the address book (depending on the Bitcoin software version). If it's not there then it's probably in an old version of your wallet.dat file. If you lost this file you can't use that address anymore so you should focus on the addresses in the new file (and keep a backup of it). In any case reinstalling the software shouldn't harm the wallet file if you keep the data directory intact.

Sorry, I admit you'll have to remind me your name and/or the time we got a chance to talk.
Scratch that, a search in Google's cache revealed your identity. Of course, we talked a lot and it was a pleasure.

Pretty cool. Though a beginner may not know what "currency risk" is, so...

Sure, I have no problem with that as long as we understand that this is a bootstrappnig model we want to phase out eventually. Since the buyer and seller can choose separately how to handle Bitcoin payments on their end, we have 3 scenarios:
1. Ok - both buyer and seller make JIT conversion
2. Good - one of the buyer or seller holds bitcoins, the other does JIT conversion
3. Great - both buyer and seller hold bitcoins and transact directly with Bitcoin
I maintain my position that scenario #1 offers very little advantage over the current system. But if we assume that, say, 1% of people (both customers and merchants) who use Bitcoin in some way are willing to hold bitcoins, then about 98.01% of transactions will be of type 1, 1.98% will be of type 2 and 0.01% of type 3. This is a good setup for a positive feedback loop where as Bitcoin becomes more popular, it is less volatile so more people can afford to hold bitcoins, increasing the percentage of people who handle bitcoins directly.

Yeah, it was a pleasure meeting you too, maybe I should have started with that

Because I'm a Bitcoin enthusiast and have a long position, I'm holding bitcoins and willing to eat the volatility. This doesn't mean I enjoy it, I do want it to be stable 10 years from now. But for this to happen enough other people need to also use Bitcoin the way it was intended.

I should have mentioned earlier that at this point in time, transaction fees actually have very little to do with the incentive of miners. They exist only to prevent attacking the network by spamming it with useless transactions. So there are hardcoded rules for tx priority which are believed to be enough to prevent spamming. They are tweaked from time to time and there could be glitches which prevent transactions from being included even when they are legitimate.

Features like those I described will only be necessary years from now, though Gavin has implementing an open market for tx fees high on his todo list. I'm not sure what are his plans for this though.

The current "suggested fee" feature of the client is a temporary hack. In the future it will receive as input the desired wait time (or use a default value) and give a reasonable estimate based on historical data.

The protocol supports multiple versions of a transaction. It should be possible to use this to release a new version of the transaction with a higher fee if the old one isn't accepted, and the client can do this automatically.

He shouldn't, and to the extent that he needs to care about it in the current implementation, these are all issues with the usability of the current client.

Mostly likely the transaction wasn't included in the block due to some technical error in the way the miners' client chooses transactions. It's not due to malice on the miners' part.

Miners provide a service for a fee, it doesn't make sense to force them to provide a service to you. Ideally the incentive structure is designed in such a way that the market is efficient and you will find miners offering this service to you at a competitive rate. You're extrapolating from an occasional instance of a technical error, and your proposal does not solve the actual problems (which do exist, and for which a solution will have to be found).

Tx propagation is fast in optimal conditions but you can't assume all nodes are aware of all transactions at all times, so you can't declare a block "invalid" just because it is missing a transaction. Also you shouldn't expect miners to do work for you unpaid, if you want them to include your transaction you should pay them for it. In fact to make the network secure it is important that enough is paid to miners, what we should be looking for is how to make transaction fees as high as possible while still being insignificant to the users.

That said, I do indeed believe, and have suggested in the past, that branch selection should involve more than just the total difficulty, and include things like the total bitcoin-days destroyed in the block - precisely to prevent denial attacks. But this needs to be much more subtle than just "reject a block if you know something it doesn't".

Also, you are drastically underestimating the hardware requirements a full network node will require if Bitcoin becomes successful.

I strongly disagree. If that was true Bitcoin would be completely pointless. If you need to use an exchange just to be able to pay with Bitcoin then the exchange (and/or service like bit-pay) becomes the new bank/PayPal offering no advantage whatsoever over the current system. The point of Bitcoin is that you can store and transfer your wealth without a third party, and only use third party services where they provide additional value. Otherwise you lose all advantages of Bitcoin such as:
1. No sending fee (and thus competing with payment processors who will have to lower their own fees).
2. No currency exchange fee for international payments.
3. Ability to hold and control your wealth without using banks (which are a single point of failure, a hassle and so on).
4. A currency which can be used by countries not strong enough to make up their own currency, and which isn't devalued by monetary inflation.

Also, Tony's suggestion of "buyer buys bitcoins when sending, seller sells bitcoins when receiving" is a bit naive. Yes, it's a passable bootstrapping option for people using Bitcoin now and don't want volatility risk. But -
1. Some time elapses between the buyer buying and the seller selling, at which the rate will change so it does not completely eliminate the risk.
2. If everybody did that and nobody would be actually holding bitcoins, the volatility would be orders of magnitude more than what it is now, making point #1 that much more relevant.

I also don't understand your belief Bitcoin will always be highly speculative even with mass adoption. If fiat currency maintains a more or less predictable purchasing power without being pegged to anything, solely by its ubiquitous use in trade, why can't Bitcoin?

In short, Bitcoin can only work as a value transfer mechanism if it is also used as a value store mechanism.

Bit-pay already has a plan for charities.

Not really. And to the extent that it does, it will be fixed in the future.

Most pools take no fee or a fee negligible with respect to the benefits they provide.

Yes. And to a smaller extent because it's more convenient and gives monitoring features. Also some things like merged mining and long polling require extra work if you mine solo. (So in fact you'll earn more in a pool than with plain solo)

p2pool uses difficult shares and is thus not suitable for small miners. It's great for large miners and proxy pools though.

If you try mining solo you'll get it. I'm serious, you need to experience losing sleep wondering if you've found a block.

Does it matter? For most intents and purposes this is just a technical implementation issue. For normal use it doesn't really have anonymity implications either, it's known that all funds in a given address belong to the same entity, so it doesn't matter which of the outputs they choose to use to send. Only when you want to do fancy stuff like we've discussed here it matters.

The difficult part is how to retract orders. When I put an order I don't want it to stand forever, I want either to be able to retract it (which is difficulty to synchronize and probably won't be supported), or to set in advance a time limit. So you need to have a transaction like you described, but which is only accepted if completed up to a given time. And it needs to be able to be completed even without the issuer's cooperation. And the proof that it was indeed executed before expiration needs to survive block reorgs. This seems challenging even if you design a new blockchain just for that.

You are confused about how Bitcoin transactions work. And while what you're describing may be the ideal, where all bitcoins are fungible, the reality is different.

When I have BTC in an address A and I want to send some to address B, I don't say "Hey, I have bitcoins in address A, I'm sending amount X to address B", I say "Hey, I have bitcoins in address A which I got from some specific output, and I want to redeem this particular output in a transaction whose input is this output, and has an output sending X coins to B, and if the output I redeemed has more than X coins then I'm sending the extra to a change address in a second output".

So an attacker can't force me to comingle tokens with normal bitcoins. If he sends me 1 BTC I still have one redeemable output with 1 BTC and one redeemable output which can be traced back to the agreed upon token output with 123 satoshis.

I certainly can, and will, choose the output that traces back to the original output when I want to transfer tokens. As I said it can be tricky with tx fees and merging of tokens but still doable.

This will become much clearer if you spend some time in block explorer.

It looks like you're talking about enabling atomic trades where one side can't run away with the money. That's indeed easy. I'm talking about preventing people from not going through with an order they've placed. That is, someone puts an offer, he is contacted to execute it, and ignores the request if it's no longer profitable for him or he never intended to honor it but just wanted to manipulate the market.

The design of using BTC as tokens, which is by no means mine, also can't enforce orders. Which is why I suggested on SE that indeed a separate system/blockchain will be needed for the shares. But I only went as far as saying that such a system can be designed to have the functionality required to enforce orders (as well as other asset-friendly features, such as markers) - but how exactly to implement this is still an open problem.

You can if you're careful. Bitcoins are fungible only at the intra-transaction level, not the address level.

If you carelessly combine token bitcoins with normal bitcoins in the same transaction then yeah, in the outputs you can't tell which one is the real one. But an address that has coins from several outputs can certainly tell how many came from each output.

Suppose that you never pay transaction fees, and never merge several tokens in the same transaction. Then there is a linear chain leading from the original output to wherever the token ended up (there can be multiple chains for the original output, but one chain for the endpoint). When an address wants to show it has tokens, it simply references the output from which it received them, and by assumption the transaction with this output only has a single input, so you just follow the chain backwards until the original output.

Transaction fees complicate things a little, because you need an unambiguous way to determine which inputs are tx fees and needn't be traced back. But it should be possible to agree on such a designation (eg tokens are only transferred in multiples of 10 satoshis, and for tx fees the input will be chosen not to be a multiple of 10).

Merging tokens also adds complication because for each output it's possible that several inputs will need to be verified. But the total work shouldn't exceed the total token transfers done.

And this whole thing becomes trivial if a protocol-enforced way is introduced to add markers to outputs. So a marker will be the hash of an output, and a transaction is valid only if the marked total in the output is at most the marked total in the input, where the output itself which has this hash is also considered marked. If not in Bitcoin itself, then in an alternative Bitstock blockchain (or maybe it will be BitAsset to make it more general).

You can't trace them if you're careful to cover your tracks. You can trace them if you're careful to "expose your tracks" (distinguishing tokens from normal BTC). Depending on the implementation you can still obfuscate tokens with other tokens.

This is exactly the kind of transaction you will avoid if the 1s is a token.

Unless I'm missing something, this still doesn't allow placing committing orders.

What do you mean?