Got anything planned for September? I'm going to be in Israel

Isn't wasted hashing power disincentive enough?


So this "sum-difficulty" is the total difficulty of a chain, including blocks that were merged in from other forks? If the block is merged into another chain, how would the original miner lose his transaction fees from that solved block?

Again, I don't want to mess with the current Bitcoin implementation at all, and I'm completely on-board with the careful and conservative changes the core devs are making. But there are alternative blockchains which don't jeopardize bitcoin in any way. If one of them scratches an important itch, many people will adopt it, and it will compete for some resources. I think the bitcoin ecosystem will eventually be much more robust if there are multiple competing blockchains around instead of just one.

The reason some of these economic functions will be based on bitcoin ideas, is that they need distributed chronological ordering, and the bitcoin ideas are the best way we've currently got to do that.

This is pretty antithetical to the hi tech world. Are hard drives broken now? They work amazingly well. Yet, lots of people are out there making improvements to them. I just don't see how it makes sense to say that a piece of technology works well, so it shouldn't be improved. Moreover, bitcoin is broken when it comes to using it in a commercial setting. Ten to thirty minute waits just aren't acceptable. Sure there are ways to deal with that, but those are hacks.

Bitcoin takes care of money. What about the rest of the financial transactions that manage economies, like exchanges, stocks, bonds, bets, options, futures? You need higher resolution timing for those, and probably lots of other improvements as well. I don't think anybody is recommending baking this stuff into the Satoshi client. There will be alternative coins, and they'll compete on the market.

Of course your points make perfect sense, but isn't this circular reasoning? You're saying that the target time can't be reduced because of network splits and orphaned blocks, but those are exactly the kind of things these proposals are trying to address. Satoshi is a genius, and it's uncanny how well his somewhat arbitrary constants worked right off the bat. It would have been unwise of him to add in extra complexity to reduce those numbers. But time has passed, the system has proven itself stable, and it's time to consider even more amazing things that can be done with these core concepts. Of course, pressing issues shouldn't be neglected, but some people are going to want to work on more experimental stuff, and I think that's great.

I'm looking forward to reading this.

Care to elaborate? It'll be easier to do if we know why it's impossible.

If you stopped reading, how do you know? But seriously, I believe the idea here isn't to address practical problems with the current Bitcoin parameters, but to explore concepts that will be needed if Bitcoin morphs in interesting ways. For instance, if average block solving time is reduced 60-fold to ten seconds, can your smartphone still keep up with all those headers?

kjj, you seem to be confusing two concepts here, the skip hash (most recent block with higher value than the previous) and the highest value block in the chain. In your example, X, Y, Z are skip hashes, but for the traversal stuff, you'd be working with highest value blocks. If I find the highest value block in the chain, clearly there are two intervals: blocks before the hvb in the chain and blocks after the hvb in the chain. If we look at each of these intervals, excluding the hvb, we will find a different hvb in each interval. We can choose to go either up or down. That's the second block in the path.

Hmm, how about this:

Let's hypothetically assume current difficulty for all blocks for the sake of this illustration. Your client chooses a random number (k) from 0 to current block height (n). That number is a binary number with log(n) digits (zero-padded). A zero means "look low", a 1 means "look high". You send me that number and I now have to give you all the blocks I get from traversing the highway according to those instructions. If I wanted to feed you fake blocks, I'd have to either dream up all log(n) blocks on the path for you on the fly, or have all possible paths ready to go, which is basically the same as hashing the entire blockchain from scratch.

In order to hash the blocks on the path in a matter of seconds, I'd need 60 * log(n) more hashing power than the entire network.

The problem with this is that I can try to say that the difficulty was historically ridiculously low. But since I'm feeding you all the highest value blocks, if you're not happy with the overall difficulty you just won't deal with me, because I'm probably a crook. Since you can be off by at least two orders of magnitude and still feel safe dealing with me, there probably won't be a lot of false negatives.

I love this stuff. I was contemplating something similar, where you'd store n=log(block_height) hashes in each header instead of just the last block hash. So in the current block, you'd store the hash for the previous block, the hash for the block before that, the hash 4 blocks back, 8 blocks back, 16 blocks back, all the way to the genesis block. That's about 18 hashes per block currently. This would allow some kind of SPV client to only store log n headers instead of n.  I haven't really thought through how this works yet, but it sounds similar to what you proposed. Your idea is more elegant and has some advantages, though.

Thanks, very interesting!

Without wandering too far off topic, I'm not disputing that this is a very cool idea, or that the trust in the processor is a minor issue compared to trusting someone with the whole escrow. I just wanted to point out that there are drawbacks to each solution which have to be considered, and there's no obvious best solution which trumps the others being discussed.


There's a big assumption there that you're well connected to peers, that those peers are well connected to miners, and that there's no sybil attack. Being properly connected is an extra precaution that has to be managed carefully by vendors, as opposed to being baked into the system. If you wait for a few minor blocks, at least you know for sure that the attacker had to pay for a considerable amount of hashing power. I feel that's a big win.


I'd love to hear your thoughts on this, is there somewhere I could read about this?


That's a very good point. This merits a lot more discussion, but off the top of my head I don't see why the minor/major block paradigm couldn't be used here so that lightweight clients would only be looking at major blocks, at least for historical transactions. In fact, since old transactions have such a massive amount of buried hashing power protecting them, one could consider a scheme that would decrease the number of blocks needed per time interval as you go back in time, potentially making that header chain even smaller.

I was just pointing out that there are tradeoffs to each system. I didn't say you had to trust the processor for the entire escrow, I said you had to trust the processor, and you do, for the amount of a single transaction. That's still trust. If you didn't need to trust the processor, you wouldn't need the processor at all, the recipient could just be the processor.

Thanks Meni, I hadn't seem some of those links and others merited a re-read -- fascinating stuff. A have a few comments about your reply:

Since my main motivation is time resolution, it doesn't matter if the minor blocks are a priori authoritative, only that they reliably fix the ordering of transactions in time once the major block is broadcast. Even so, I find talk about Finney attacks and 51% attacks a bit distracting. Finney attacks are almost impossible to reliably pull off, and 51% attacks are common to every Bitcoin modification I've heard of. The real issue is race attacks, which are certainly feasible. Minor blocks would make race attacks a lot more expensive than they currently are because you'd have to put in the effort to solve minor blocks (assuming the merchant is willing to wait an average of 10 seconds). That's means they can't be used to get a free cup of coffee at a cafe. If you're buying  a car, the dealer can wait for a few major blocks. On the other hand, it would be great if you didn't have to hang around the dealership for half an hour waiting for the payment to clear.

I also don't buy the suggestion that quick confirmations aren't necessary in Bitcoin. Your proposal is very interesting, but there are lots of tradeoffs involved, including trusting an established payment processor, and putting funds in escrow. These are serious considerations, and if there's a way to do this using the elegance of the blockchain idea, while retaining low trust requirements and no escrow, I think that would be a big win. Dynamic block frequency is very cool. With my arbitrary 10 second interval, I was trying to hit the minimum time that would make sense for current network and processing speeds, but a market approach would be very interesting. Perhaps there could be competing blockchains, each optimized for a different use case. Maybe that's what's beginning to happen with litecoin. Maybe we need somebody to throw a 10 second blockchain out there and see what happens?

There are advantages to the hybrid minor/major block approach (high time resolution, faster confirmations, while retaining the longer term safety of the major blocks), but I'm not at all convinced a Bitcoin fork with a 10 second interval couldn't work better. Maybe I'm missing something but the wasted hash power (assuming 7% orphan blocks) and header overhead don't seem like a huge deal to me.

Awesome! That's a really useful data point.


If minor blocks are just regular blocks, and part of the chain, miners would publish them to get rewards, just like major blocks. As I mentioned, this would establish 10 second resolution for transactions, and it would be very useful for more advanced financial blockchains. If minor blocks are really only orphaned about 7% of the time, this could really be feasible. Frankly, with numbers like that, you might not even need to do a dual target, you might be able to get away with just 10 second blocks.

Meetup this week is on Sunday, 4 August at 6:30pm at Strange Brew Tavern in Manchester, NH.

https://www.facebook.com/events/208856109243508/

That's a pretty good account of what this would look like, however you may be overestimating the "frothiness" factor. I'd be interested to see what the P2Pool structure looks like. It's certainly the case that observing a minor block is not as safe as observing a major block. It's also the case that observing a minor block is way better than looking at a 0/conf transaction floating around. Another thing you could do is to track all the minor blocks, not just the longest chain. I don't really think there will be all that many. Also, the 10 second time frame isn't set in stone, it could be made a bit longer if that makes this a lot more manageable. It probably depends on network speeds and how fast miners verify and jump to a newly released minor block.

Lastly, the main motivation behind this was to gain much greater time resolution after the fact. So we'd want to have that 10 second resolution once the major block has resolved the one true blockchain. I'd love to hear comments on that part, too.

Wow, it's embarrassing that I didn't know about that, thanks casascius! I'm pretty stoked that this appears to be working in real life. My main motivation for this was to get higher time resolution for stuff life stock trades and exchanges, and for that it's important that the minor blocks remain in the blockchain. So, is there any reason why this must remain a miner's hack, or could it be floated as an alternate blockchain? Clearly, another benefit that comes out of this is that the new blockchain would have a much reduced need for pools.


Yeah, this is a big deal for vendors.


A miner would be highly incentivized not to ignore the minor blocks. As part of the hashing process, they will find many minor blocks for every major block, so why not take the extra trivial step and broadcast it and have a good chance of getting the reward. This is even more true for major blocks. While hashing the minor blocks, miners will occasionally hit on a major block. It would be crazy for a miner to not broadcast that and lose out on the big reward. That said, I'm not sure the 10:1 ratio is necessary.


In order to get the time resolution, the miners would need to build the blockchain on minor blocks. This would also get you exponential protection against fake blocks instead of linear protection. Is there an obvious reason this chaining wouldn't work? That said, a different blockchain operating as you described could solve a lot of problems, too.