An alt-"chain" is probably the wrong way to think of this.  It's committed data. There doesn't need to be a chain.  Each bitcoin block could have 0 or 1 tree commitments of a given type.

Which can't be used to implement escrows of the kind we usually talk about in Bitcoin— because it results in at least one (and potentially two) parties having complete control of the separated secret (the party who creates it, and the party who recovers it).

Perhaps you should start of by saying what you're trying to accomplish.

This was basically my point.  You posted a lot of text, which I spent a fair amount of time reading— and I didn't get anything out of it because you didn't say much of anything. I didn't know if it was clear to you that you weren't saying anything concrete, so I used an example to illustrate the point.


Can I download APPECoin?


I'm another miner and I have no transactions involved in the prior shuffle. How do I know know that the shuffle was valid?  Or, say I do have some transactions on the input side— and I see those are fine on the output, how do I validate that the shuffle didn't invalidly replace a bunch of transaction which weren't mine?  Is there a reason why I don't need to know?

I assumed you'd have a non-interactive zero-knoweldge proof for this, but I'm not aware of any which would be suitable.

Unfortunately you haven't answered this question here at all.  This is a marketing speak arm-wave, not a design description.

I'm familiar with some of the re-encryption shuffles e.g. described for e-voting. I'm not aware of any way to get quite the properties you need.

Since you haven't described any details, I'm just going to pick the most insecure system which fits the description you've posted, a reasonable conservative assumption, and then I'll show that the strawman burns easily.

So— I say your proposal is that the miners produce N reencryption keys,  and make a random shuffle with each re-encryption key. The user can decrypt their own but not others. The non-interactive ZKP is created by the hash of the next block selecting which of the N published shuffles is the real one, then the miner must publish the N-1 reencryption keys for the other shuffles, and they must be valid shuffles or the prior block was invalid.

But this means that There is p=1/n chance of replacing all the transactions with your own at any block, or p=1 chance if you can mine two consecutive blocks.  This system fails.

Perhaps you didn't mean to propose something so trivially defeated, but I can't tell because you didn't describe it in more detail.

I'm not trying to be rude, but if you want the credit and attention of having disclosed something interesting you have to actually disclose something of interest— even just links to papers on algorithims which provide exactly the right properties and a sentence or two on how composing them gives you what your feature list describes. I'm sure lots of people would be interested in such a system, even if boring issues like space and time complexity make it not-practically-viable. Also, this thread probably belongs in the altcoin subthread.

A toy example: The block rate is infinitely fast, the communication delay between miners is 0+ε.  All miners are on their own forks and will never converge onto a single chain.   This was even demonstrated in practice on a altcoin.


The miners hases aren't "wasted", since eveyone takes the losses from orphaning. There is only the loss of security of blocks which are frequently below the communications horizon and the race to the bottom to include more transactions regardless of the overall security implications.


There are many problems which are basically unsolvable in a dynamic system but are trivial when the parties can pre-commit. Bitcoin is defined by it's rules, its a pre-commitment that we've all signed up for. Changes that favor some over others would rightfully undermine any trust people put in it...


... especially when there are alternatives.

I would have guessed that someone experienced in financial markets would know you multiply compoundable returns, not sum them. I suppose not.

On the contrary, you missed his.  The most important element of the inter-block time is the network convergence radius, if the interblock time is too small relative to the block validating and forwarding delay and the network is likely to never converge. Somewhat larger, but still small— a concentrated attacker gains an unusual advantage against distributed honest defenders, because the defenders lose hash power extending multiple separate forks due to slow convergence.  If you set the time just high enough to avoid the most fatal effects you still greatly increase the computational burden on full validating nodes, increase the storage burden on simplified nodes, and damage decentralization by discouraging validating or semi-validating nodes and driving people to centralized services.

It's not really an market parameter at all— and to the extent that it is one, it would be one highly prone to a race to the bottom which devalues the system for everyone.   Even if you set it to stupidly-low-will-break-for-sure levels there will intermittently be very long blocks. If you're engaging in activity where you need fast evidence of irreversibility it's almost always the case that you need consistently fast evidence of irreversibility— often fast, sometimes not isn't good.  So making the block times different doesn't really solve anything here.  Fortunately there are other ways to get evidence of irreversibility, lower variance for mining, etc. that don't require breaking the system.

Better watch out,  it's not every day you get threatened by Aishwarya Rai for stealing 16,000 17,000 1,000,000,000BTC!

The reason it twiddles the time in various ways in various places is because the time is used to prioritize peer selection (in some limited ways), if peers could send you times in the far future they could unduly influence your peer selection.

Make sure to chronically the flipside too. The failures, though sad, are also entertaining... and can serve as a cautionary tale for others.

Nope, it's safe, all signing is on a hash of the message, and its assumed that a malicious party may be supplying the strings you sign. Though why do you think it looks weird?

Good thing I did not say linear growth then, I said there is a linear maximum. I have a laptop with enough storage for something like 20 years of growth at the maximum rate.  There are certainly things to be concerned about, like the loss of decentralization that comes from more people lazying out of the initial startup time... but there is no danger from "exponential growth" in terms of size.

It's not a prediction, its not something happening, it's nonsense hysteria.  The blockchain size has a fairly modest linear maximum, which can not change without a hard fork of the protocol.  Can this stupid thread die now please?

Well, another input.  I suppose you're right though.

It makes the duplication ~impossible (save getting a hash collision). There was not previously a behavior where two coinbase transactions became invalid, rather one could replace another— though that is prevented by BIP30.


Because transaction exist externally to and independently of blocks. Even if you were willing to create software which only worked with confirmed transactions (e.g. not a full node) you'd still have crazy issues with transaction IDs changing when the chain reorginizes which could itself create some awesome exploits against merchant software.


Including the height as part of the hash for the coinbase transaction is something Bitcoin should have always done. Although it should have been listed as the 'input' rather than putting it in the coinbase, but sadly the former can't be done compatibly.


(As of BIP30) We reject duplication which would overwrite an existing unspent transaction, because that in and of itself creates some really nasty and critical attacks, but we can't explicitly prevent duplication of already spent transaction in the general case without making pruning impossible.  (If you have to remember every txn ID that ever was in order to refuse to mine duplicates you can't forget spent transactions).

Including the height in the coinbase implicitly prevents duplication by making it infesable but doesn't require unbounded storage like explicit prevention.  It also allows nodes software to be more DOS attack resistant because it would allow additional filtering prior to connecting. This is described in some of the links gavin provided.

BIP30 was an emergency fix for a severe vulnerability, deployed because the real fix couldn't be deployed quickly.  This change fixes the underlying protocol design flaw and fixes up some of the less critiial corner cases the other fix couldn't really address (e.g. the prospect of having to deal with duplicate transaction IDs for distinct transactions).

Just set your dang clock correctly. Get the time you want to display by picking the appropriate timezone.  So long as the time+timezone results in the correct time bitcoin will work fine. You can also set it back when you're done if you really insist on having a clock set >2 hours in the past.

Ah, I hadn't seen how you handled the non-completion case.  So in Bitcoin-style hashchains when that contract was mined it would consume the inputs forever unconditionally. If it did not, you could not have pruning.

Do you plan on breaking pruning or having the satisfaction rules change as a function of height or?

You can't create timeouts in Bitcoin, locktime sets the earliest valid time. So you pre-create the refunds... but yes because the timeout wouldn't be identical in both chains there is some exposure.

I don't see how you avoid extortion in your scheme that wouldn't just apply here.  E.g. you could do the pre-created refund tx only on one side in what I described... and have the other side be the send-hash-first side.  If they don't you perform the refund after the timeout, thus no race.

(Not that in general I think that using chain fragments is bad— but I think it's interesting in external oracles, and less in chains themselves)


Both users would txouts before releasing a secret, so any funny business would have to be in the scriptsig.  If your scriptpubkey looks like if  H(stack) == 123456...  Then I could always copy from your scriptsig anything the satisfied that, even if it computed the value. Though yes, a program for this would have to have a pretty general solver to figure out how to extract the data.  So long as the abort transactions are sufficiently far out that shouldn't be a problem, and you'd have proof of your counterparty being evil.

Correct. The script sig would push the x and y values and the script pubkey would hash and compare them.

(You can also reduce the extortion risk  by using nlocktime, on specially constructed refund transactions. E.g. "Abob_pub + H()+H()" OR "Abob_pub2&&Aalice_pub" and have bob sign a refund txn with far future nlocktime using abob_pub2)

I'm sure someone could give some figures on how often these results could be expected by chance.

Though since today seems to be the day for silly theories.

It was pointed out on IRC that you could do somewhat tidy laundering this way.


Identity X with dirty coins gambles until they lose Y coins.

Then using identity Y, they make more bets, and someone with knowledge of the MAC secret filters their candidate transactions  to help them win until they've won Y/2 (or whatever).

This would be pretty hard to distinguish, except for the weird effect would have on the odds, especially if they weren't careful about the distribution they drew the winning bets from... and it would be impossible to connect the parties beyond they were both participants at some point in the game.

It would also explain rapid, almost certainly bot-based, playing of a negative ev game, reasons for capping the total (make the distribution of bets more regular).  Plus elvis came down from a UFO and told me it was true.