Topic: High Resolution, Dual-Difficulty Blockchain (Read 2490 times)

Thanks, very interesting!

Never said otherwise.

You can start with https://en.bitcoin.it/wiki/Proof_of_Stake but there are some new ideas I still need to write about.

I guess it will be easier to estimate the exact cost with a more specific design.

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.

You're trusting the recipient anyway to deliver the goods. You don't use the processor because you trust him, you use him because he allows you to send payments everywhere with a single channel, without knowing in advance who you're going to pay.

EDIT:

I don't see how it really helps security against race attacks. With the current system you can query each of your peers if they know of a conflicting transaction. In none do you can be pretty sure the network recognizes the transaction.

Also, proof of stake proposals strive to make the network immune to >50% hashrate attacks. I've had a discussion about PoS lately and I think I have a new framework to think about it, your suggestion could fit in as well.

Header overhead is a pretty big deal. Most people won't run full nodes, and hopefully they'll choose the more secure lightweight clients over eWallets. The resource cost of this is proportional to the number of headers.

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.

I don't know how much you've followed the suggestion but it does not require you to trust the processor. The funds tied up on the channel are not at the mercy of the processor, the customer gets them back even if the processor is malicious or negligent. The amount that is trusted with the processor is the amount of a single payment by a single customer - or even less, if the customer splits the payment to multiple pieces and receives confirmation from the seller on every one (since payments are direct this isn't expensive).

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.

I don't think this works.

Either the minor blocks are authoritative or they're not. If they are then it's just like having block frequency of 10 seconds with all the disadvantages (wasted hashpower, block header resource cost). If they're not then they do not add to security, a Finney attacker could just hold on to a double-spending major block, and then release it no matter how many minor blocks have been found in the mean time, likewise for >50% attacker.

By the way, p2pool is a way to reduce mining variance with fair reward distribution. It was never touted as a way to get faster security for transactions, and it probably won't work for this purpose for the reasons outlined above.

Also, having very quick confirmations isn't necessary, the blockchain is for final settlement and actual payments will more likely be in some form of Trustless, instant, off-the-chain Bitcoin payments.

Related ideas are Dynamic block frequency and Unfreezable blockchain.

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.

I was not imagining the minor blocks as forming a chain. They'd all just be orphaned/ignored eventually but in the moment you can say to yourself, "Ok, 3 out of 4 minor blocks included the tx I'm interested in and none of them included a different one using the same input, sounds good to me."

The missing piece to me is why should miners broadcast these minor blocks?

On average p2pool blocks are orphaned 7% of the time, so not too much branching.

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.

In the OP, there are 60 minor blocks in a typical 10 minute window. These will not be in a single tidy sequential chain but multiple splitting branches and twigs. Imagine the trunk of the tree as the last major block and then various branches, smaller branches and twigs sprouting from it.

Note also that this tree is 'burnt to the ground' when a next major block appears. Its structure does not get used by the major blocks.

If my transaction is on the 3rd twig, 4th branch on the left what does it mean ? It means a miner saw it, it is well formed and THAT miner has put it into the self-immolating minor block tree. There may well be a competing transaction (ie a potential double spend) on the 7th twig, 1st branch on the right. Which will get into the next major block ?  The minor block tree gives no indication.

It is an innovative idea but I am not sure it gives much more than knowing the miners saw it ie network propagation info.

All these "second tree" solutions seem awfully complex and like a short term/bad solution.

When, not if, bitcoin reaches VISA volumes you will need like 3 meta trees or something.

Its the most ugly solution I have ever seen, I don't get why people here talk so much about it.


Super nodes are better or other solutions...

If they aren't using P2Pool, they aren't generating minor blocks.  They are either generating whatever their pool op wants to generate (if in a pool), or are attempting to generate entire Bitcoin blocks worth 50 BTC a pop.

Current downside to P2Pool as far as I know, from the perspective of a miner, is that the setup is way more complex and that they need a whole local blockchain and bitcoin node, as opposed to mining from a diskless headless machine that boots from a live CD.  This is mostly an inconvenience, not a fundamental flaw: P2Pool miners help decentralize the network, traditional pool miners booting from CDs do not.

When mining P2Pool becomes as easy as booting from a CD or USB stick, I will bet more people will do it.  If this "meta tree" thing picks up steam and mining nodes can start mining after only having downloaded and verified a few weeks worth of transaction activity (rather than the whole blockchain), then perhaps P2Pool mining from boot CD's will become feasible.

Do you mean that the downside is that most miners have no incentive to broadcast minor blocks? Unless they happen to be using P2P pool in which case that's how they prove they are mining?

edit: If so, this seems like a somewhat inevitable good thing right? I don't mine though, what is the downside to P2P pool?

If P2Pool were the biggest pool and had the majority of the hashing power, then it probably would be a better idea compared to right now where it isn't.

This sounds great.

Would this be a reasonable implementation? Have a checkbox in the client for "Alert me about minor blocks" and if you have it checked and if you have a 0/conf tx it listens to miners and peers who are optionally broadcasting minor blocks and tells you if one or more minor blocks that your client is hearing contain that tx?

Am I roughly understanding?

Seems brilliant.

God I would love to have Seals accept 2 minor confirmations.

In P2Pool, solving minor blocks results in you getting a proportional share of the payoff when somebody else solves an actual block on the Bitcoin block chain.  The minor blocks are there to prove you were working for the entire pool's benefit.

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.