This appears to have scalability and security problems. From a scalability perspective unless mining is highly centralized you must communicate with many parties or process many signatures.  From a security perspective a miner signing saying they'll mine a transaction doesn't actually prove that they're even trying to do so or force them to continue trying (e.g. if a higher fee comes along).

Instead, I point out that P2Pool's sharechain approach already solves this.  Right now the included txn in p2pool shares can change freely, but in order to enable 10 second soft confirmations it would be perfectly possible for p2pool (or a similar system) to commit to some transactions (e.g. ones with sufficient fees) which can't be removed without making their shares get ignored.

This has the property that the proof of confirmation is actually also proof of really trying... and it doesn't have the same scale problem in the case of decenteralized miners where there are many possible ones. It could be done by existing pools for the pure confirmation purpose but there would be no incentive to participate other than providing faster confirmations and then defection is easy. When the shares are used for payout, however, there is a good incentive not to defect.

Although with finny attacks being cheap thanks to gpumax and getting cheaper, I don't know that any of this matters: One confirmation isn't enough for most things where zero isn't enough.

You still have to have the complete data that you would remove. E.g. when I spend txn X,  I don't specify all of X's data to spend it (thats burried elsewhere in the chain) only the hash. Order invariant wouldn't let me recover that. I need some kind of undo data, even if its just the location of the original txn so that I could fetch it. (though more efficient if you can serve me up a whole undo block)

One recent revelation I've had as a result of Pieter's ultraprune implementation is that any tree commitment scheme should also commit to undo logs so that nodes don't necessarily have to all individually store all the data required to reorg forever.

You usually work with the parties responsible for the thing you're reporting against and take whatever timeline they ask for, unless they're unresponsive or completely unrealistic.  As an ethical party your duty is to minimize harm, and harm is minimized when things go in an orderly and well coordinated fashion, though harm is not minimized if the vulnerabilities are not fixed so it's also not unreasonable to hold software distributor's (or site operators) feet to the fire if they're not being earnestly responsive.

Fourteen days is more than enough for somethings and far to short a time for others— it depends on how complicated the fixes are, how difficult the deployment will be, the resources available to fix the issue, what the risk of exploitation will be both before and after the disclosure and the amount of damage done. Communicate carefully, listen, and keep the good of the world in mind.

If changes in usage resulted in centralization of validation it would 'destroy' Bitcoin. No, it wouldn't stop existing— but it would stop having a point. We have other ways to have centralized money and Bitcoin isn't an especially efficient one.

However…


Technology like pruning and txout trees are things which _prevent_ centralization. What you're saying above right now applies much more strongly to block validation then they do to storage.  Storage has been growing at a rate faster than moore's law and slow nearline storage is very inexpensive. At home I already have enough storage for about 100 years of the current maximum blockchain growth.  But timely validation is much more costly and there is a risk of a tragedy of the commons on performing it and everyone moving to centeralized webwallets or lite nodes that trust other nodes to be honest.  Technologies that minimize the cost of fully validating nodes are not a threat, they are potentially a salvation.

(In particular: it's already trivial to mine without having the history— all of these centralized pool miners are doing so already, and unless you're using P2Pool, bitpenny, eligius-gmp, or solo mining you are guilty of it too, so these improvements don't create new ways of being anti-social)

I'm not too worried about your concern because the cost of storage is reasonably cheap, and preservation of the data is valuable for many reasons and not just preserving the autonomous trust-freeness of the system— e.g. historical, contractual, investigative, and academic reasons. But the autonomous validation is probably enough incentive alone, after all the whole Bitcoin system was created in order to have that property.

In addition to that it's possible to retain strong confidence of trustworthyness in even in an environment where many people don't have access to the long ago historical data— I suggested an idea I call "proof of treachery" on the Bitcoin-dev list:

If the rules are violated in a chain someone who observes the violation can copy out the minimum necessary data to _PROVE_ that a violation happened (which is always small: it's no more than two conflicting transactions or one bad-signature transaction, and the hash trees that connect them to the header) they can then broadcast these proofs and any node— even one without the history can see and understand the proof just on a purely 'mathematical' basis— without trust and then completely reject any chain following the point of treachery, even if that point was long before the history they have.  Because information is hard to stifle so long as there was at least _one_ honest node that observed the cheating it would be reliably defeated.  That is not quite as good as "you checked for yourself", but Bitcoin doesn't quite achieve that even with access to the whole history because someone could have potentially concealed an alternative history from you (e.g. there is another longer chain but no one has told you about it) so Bitcoin's autonomy already depends on it being too hard to effectively conceal the truth from nodes for too long. Plus, a proof of treachery is much smaller and more easily passed than a block (and it's origin more easily concealed from someone who would want to suppress it).

So I think so long as we build all these paranoid little tools that preserve the vision of Bitcoin and act with thoughtfulness and care when making adjustments to improve scalability which might result in centralization then Bitcoin will do just fine.

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