Bitcoin Forum

Hi there,

It seems to me that no one is talking about something quite obvious that has come to light quite recently regarding scaling bitcoin. None of the segwit/blocksize increase proposals are the right answer. That's why there hasn't been a unanimous agreement on the right path the choose. Both of the major camps are lobbying for changes which are only stop gap measures.

IMO, something quite radical needs to change in the way bitcoin works in order to facilitate proper scaling and to decrease centralisation literally as far as physically possible in a system with mining incentive.

What we need is something like this:

*) Homogenise - Remove the distinction between miners and users of the system
*) Reduce blocks to one per transaction
*) Users mine their own blocks when sending a transaction, no other user can mine another users block
*) Users can choose their own difficulty level when mining their blocks
*) Block reward is proportional to chosen difficulty (up to a an moore's law based maximum and with a spam preventing minimum)
*) Preserve orphaned branches of blocks and include them in a new LCR scoring system so we maintain deterministic, global state

These measures:

*) Allow bitcoin to scale indefinitely, as the block size is now as small as it possibly can be, and there is now no fixed block interval, as these tiny blocks arrive constantly
*) Miners can still participate, but instead of enabling transactions to be sent/received their only job is now in securing the chain by providing hashing power; they still earn their mining reward
*) Chain security remains strong; miners get paid for being on the longest (largest cumulative difficulty) branch, and now this weighting includes orphaned branches which are referenced within each block, so no history based attacks are possible
*) Decentralisation is maximised because there is no need for mining pools anymore, since variance in mining reward is now under the control of the user. Moreover, since only you can mine your own blocks (the PoW is signed by you), mining pools are unattractive anyway.

Thoughts?

edit: draft whitepaper: https://github.com/wildbunny/docs/blob/master/T.E.T.O-draft.pdf

Cheers, Paul.

drivel

Did you get hacked through email recovery or password leak ?

I think moderator changed email for my account by "fake" requesst
https://bitcointalk.org/index.php?topic=2030689.msg20221556#msg20221556
Sorry for offtopic.

Care to expand?

No.
Your ideas told me that you know absolutely nothing about how crypto works.
Start with this article: https://en.wikipedia.org/wiki/Tragedy_of_the_commons

Self interests are still aligned with overall system convergence.

There is/was no distinction in original bitcoin idea. Everything was implemented to gain fiat profit

Why do we need "blocks" in this paradigma?  ;D

In original bitcoin and now, there were miners and non miners. This change would make *everybody* a miner by necessity.


Because a block contains more than just info relating to the transaction.

1) If every user just mines their own blocks, how are double spends prevented?

2) If tiny blocks get propagated everywhere with users only mining their own blocks, how do they know which chain to base their blocks on?

3) How can miners still participate if there's no distinction between users and miners and everyone just mines their own chain?

1) There is still an LCR rule for selecting the branch with the largest cumulative difficulty. Users want to be on the longest branch, so they have timely confirmation of their transactions.

2) See (1)

3) Miners participate by choosing high PoW difficulty blocks to mine (their own blocks). They are incentivised to add them to the branch with the largest cumulative difficulty, because otherwise they won't get their mining rewards.

And how will you send your transaction if there are another 100500 users who have more 100500x times hashrate than you?
It will be very complicated quest to send coins in your network :)
"Run you PC for a week or buy an ASIC device to purchase a cup of coffee"  ;D

Because you can chose your own difficulty. Miners who are in it for the money, as they are in bitcoin, can mine with maximum difficulty. End users like you and I can chose a much, much lower difficulty because we don't expect to earn anything, we just want to send a transaction.

...how does anyone know what the branch the one with the largest cumulative difficulty is if everyone is just firing transactions away on their own branches? How do you keep track of transactions if everyone is just writing their own transaction history? How do you achieve consensus what the actual global state of the ledger is? And once again, how do you prevent double spends? Nothing is preventing a user from sending the same coins multiple times to different addresses... they can just mine different transactions using the same inputs over and over again and see what sticks.

Users are not on their own branches - just like in bitcoin, miners/users aim to put blocks on the main branch with the greatest cumulative difficulty.

Ok, let me rephrase my question. So we are at block 100. Everyone knows were at block 100. 5 people mine based on block 100 and send their transaction at the same time. One on each continent. Each of those people propagate their own block as block 101. What happens?

Ok, I understand what you are getting it.

So, in that situation you have 5 new blocks at the same height referencing the same parent. What happens next is that someone else sends a transaction picking one of these branches to extend from (either like bitcoin does, or by tiebreaker rule) - this next person references one of the other branches as an uncle in the block he produces. Then along comes the next person, who extends the longest branch again, and again references an uncle branch, so the transactions in the brief 5 wide fork all get included in the ordering eventually and the system reconverges on the longest branch.

The big difference between this and the current bitcoin are the inclusion of the uncle references, which are a permanent record of forks, and allow forked blocks to be included in the set of valid transactions. This is necessary because otherwise users would need to retry sending their transactions over and over if they didn't place them on the correct branch.

Double spends which are also in forks are resolved by the way blocks are ordered - a block which contains a double spend persists within the ordering, but since it is invalid, it is simply ignored. The first spend of a set of outputs which is processed is the valid spend, the 2nd processed spend of those same outputs is invalid.

Here is an example of the ordering using uncle references:

https://i.imgur.com/cZyN6Ih.png

Cheers, Paul.

Good thought.

Now explain it for 10000 blocks ready for the position of 101st block.

Sorry, I don't understand the question?

I think he means that there's 1000 blocks (think transactions) and every one wants to get on the main chain. How long would it take? I mean if the main block time would be a 1 sec that could be possible, as in your example after adding 1 block to main chain every transaction would have to solve puzzle again with a new header. That would take forever to include a single block. Or did I misunderstood your proposition?

Ok, so in the pathological case that 10000 users all begin sending a transaction at the same time, and by some miracle all their PoW are solved at exactly the same time, and no other transactions arrive during this period, then, yes you would have a temporary 10000 wide set of single block forks. But unless this set of circumstances continues, the process for resolving will happen naturally as miners of differently chosen difficulty solve blocks making one branch the leader in terms of cumulative difficulty.

The way to visualise this is like a tree, which expands in width as the transaction throughput increases, but further back in time, the trunk is much more narrow as a single best path of blocks back to the genesis will be visible, with the forks preserved by uncle references (other branches of the tree).

Cheers, Paul.

You are getting me but what if there are continuous thousands of new solved blocks then how would blockchain adds new blocks? I am not saying there are 10000 blocks at any one time but I mean that as users can set their difficulty very low to solve blocks and propagate their new block as soon as possible (yes, they can get little reward but swift transaction. Just think about a normal user). Isn't in that case network speed and latency etc. plays a very big role?

Network latency plays a very big part. When transaction throughput is high, the width of the top of the tree grows but then it'll shrink back down in periods where throughput is lower.

As miners who are in it for the money contribute their blocks, they greatly shrink the width of the tree because their blocks have a lot of 'weight' in terms of the difficulty solved, so when one of these blocks appears, everyone will tend to extend from it.

edit: think about the width of the tree being similar to a dynamically adjusting block size in normal bitcoin.

Not very reassuring that a moderator can do that :o Thank you for the explanation

How does the wallet=miner gets all the required data like last block, utxo,...? Only SPV style?

SPV clients will continue to work as normal. They can still mine blocks - it wont matter if they don't place their blocks right at the latest head block because their blocks will get referenced as an uncle by other, more dedicated miners.

So the more dedicated miners are the common miners we know yet?

What is the difference than to 0-conf TX ?

Full nodes will likely be mining for profit, because they need up to date info on the latest blocks to make sure they get paid. The difference is that you wont need a mining farm to earn bitcoins anymore, even SPV clients can potentially earn a small block reward if they place their blocks on the longest chain and mine with sufficient difficulty.

I was just thinking of the SPV nodes /  mining a bit more and was reading / externding an idea that was about enriching SPVs with a minimum random part of other TX / blockchain parts.

If we would have enough such SPV + random nodes, the part's sum of those will do the job of many 'full' nodes.

Further: If mining could be done in such a SPV + random style as well, like:

You can only send (+  pre-mine) your own TX if you 'atomically' mine a couple of others TXs (at least 2) than mining could be fully decentralized as well and scaling / storage is no issue - at least if there are also enough merchants / miners with huge SPV + random nodes, where the random part might be very huge one for some bigger and riskier entities.

Any comments?  

Well looks like there's a plan now it's time to actually execute it. Maybe someone will jump on board as contributors if there's proof of concept to develop it further. 

Could you write it down. Instead of having to go through questions and answers

You just explained exactly a Block-Tree which I developed back in 2012, which the original eMunie project used.

It doesn't provide an sufficient scalability improvement over a blockchain and was subsequently dumped in 2014.

The overhead required to maintain the global state so that everyone knows there are n number of child blocks to a parent block at scale becomes quite extreme.  This kills performance past that point.  

If you don't keep all nodes consistent to the very latest information (CAP theorem gets in the way a bit here) then two problems arise:

1) Nodes may also not know what the main branch is because they don't have all the state information and reference parents in weaker branches by mistake.  If that happens, your main branch becomes weaker, because hash power is inadvertently distributed across many branches and lots of miners don't get rewarded.

2) New blocks that are children of old parents will be created and won't be included in the uncle list of the next real block of that parent due to it being created already.  

Your diagram that you put together shows exactly this (by coincedence I assume):

https://ip.bitcointalk.org/?u=http%3A%2F%2Fi.imgur.com%2FcZyN6Ih.png&t=581&c=sRWU5_r4qdX9nw

Block(X) is not reference by other blocks, maybe it came in late.  There is also no guarantee if or when it will be referenced by any future blocks either and therefore poses a double spend security risk.

You also have the problem that a dishonest miner can throw in a block on a recent parent with more POW than the other blocks referencing that parent and those which come after it.  That then becomes the branch with the most work.  Therefore, any inputs in a block higher up, can be represented in a block as a child of that new block.  If the input that is seen first is considered the legit spend, and those after it are considered double spends, well.....double spends can happen.

Hi Fuserleer,

I largely agree with your assessment, but I think the only real problem here is making sure that nodes with old data don't end up posting transactions which are never included in the main ordering. There needs to be some incentive for miners to reference previously unreferenced blocks; perhaps something like ethereum's uncle reward.

The other issued you've outlined are minor, I think?

Cheers, Paul.

I've been thinking about this more recently, because no-one has come up with a real replacement, or workable improvement for bitcoin yet...

The primary problem in my proposed design is the incentive for miners to reference orphaned blocks, or branches - in the initial proposal there is no incentive, and in fact it would be more profitable for miners to ignore uncles and just concentrate on generating large difficulty PoW blocks.

I propose as a solution to this problem that miners get rewarded for 'information gain', defined as the sum of block rewards of a previously unreferenced, or orphaned branches which a newly mined block includes in the main ordering via an uncle reference.

By using the block rewards of orphaned blocks as the reward, it isn't advantageous for a miner to purposefully generate a bunch of orphaned blocks, because the reward he will get from including them later is <= the reward he would get by just increasing the difficulty of his newly mined block.

In this way, it is advantageous for miners to add information to the main ordering, which will not only prevent orphaned, or stuck transactions, but also decrease the time it takes for a transaction to become 'confirmed'.

Comments?

Scaling of the block-chain should had been in from day one never-mind later using this
as an excuse to pump up mining fees.

Global money ! You must be joking unless you think that trying to read, decode 200gb
block-chain on a Intel I3 has the processing power of a AS-400 machine

it's like trying to get Microsoft Access using Local MDB files to feed the world without linked tables!

 

Ripple, NEO, IOTA would fit the bill but I exclude ETH and the clones because they are much too slow

Single transactions leaves the wallet and it sure seems complicated how that simple transaction gets
written into the block-chain and it's also difficult to walk with one leg and a blind fold on a system that's
been designed to eat up CPU's

In ethereum, uncle blocks contain redundant data. In my proposal, there is never any redundant data, because every transaction sent mines itself, so the analysis in that link doesn't apply.

This is a very good idea, but it shouldn't be used as a reward to consensus.  I think consensus should be done freely and then PoS is a good method (see other thread).  However, I think PoW is a good technique for coin creation (independent of consensus decision).  If coin creation is proportional to a weighted form of proof of work, where the weight is the economic cost of proof of work (technology dependent), then we have an automatic value control mechanism, and we are finally making a CURRENCY, not a speculative get-rich-by-hodling asset.  That currency would be created more if its market price rose (it is then more interesting to spend PoW to make it, than to buy it in the market).   Coin issuance would stop if the price goes below the cost of PoW.  In other words, PoW would work as the central bank regulating supply, and there's no problem of seigniorage, because it is wasted on PoW.

If a coin is set to cost about, say, $10 in PoW, then that coin will hover steadily around $10.  If it rises, more coins are created and this extra offer plummets the price.  If it drops, no more coins are created and its scarcity can make the price rise again.  Moreover, the expectation of constant price will avoid speculation, and promote currency usage.

But again, one should not reward consensus. 

Rewarding consensus is completely and utterly key to the security and usability of a PoW cryptocurrency - without it, there is no way to bound transaction acceptability.

In addition to that, you cannot control the value of a currency by changing the PoW difficulty. Value is derived from supply and demand, changing the difficulty only affects the supply side.

The difficulty was brought in to prevent one "bad" actor with massive amounts of hashing power to mine all the blocks for himself and also to adapt to the technological improvement of processing power. So as soon as there are a massive spike in the total hashing power, then the difficulty will adjust to balance things out.

The difficulty is one of the core principles of the protocol. ^smile^

Of course, with a PoW consensus mechanism, you need rewards, to compensate for the economic loss in PoW.  The problem is triple:
1) that you then get convergence because of economies of scale (see bitcoin)
2) that you waste a lot of value, in other words, your system is a net value burner.  You need to waste a high amount, because that waste is your only protection.  If the waste is not gigantic, anyone can attack from the outside
3) that you split the system in a set of "wasters/PoW industry" and a set of "users", and both have different objectives.

But that's more a problem of wanting to use PoW based consensus, than an inherent problem of finding consensus.  

As I said, rewards give rise to strategies.  Strategies can then be different than the desire to come to honest consensus.  It is very difficult/impossible to find rewards such that the optimal strategy for those rewards is going to coincide with the desired other outcome, namely consensus.   The systemic difficulty in reaching consensus increases if you reward the one proposing it, instead of making it easier.  Normally, reaching consensus on "sufficiently old mem pool messages" shouldn't be that hard.  Of course, the *current mem pool state* of all active network participants is different, because of network delays.  But a list of "old enough mem pool transactions", broadcast at a certain moment by one of the participants, is easy enough to check and confirm.  The "difficulty" of having several of those lists being broadcast nearly simultaneously, and arriving at different order at different network participants, can also easily be solved by including a symmetry-breaking merit function, part of the protocol, that will assign different preferences of the broadcast lists.  After a reasonable network delay, most nodes can assume they received all of the list candidates, the merit function indicates which one is to be preferred, and all nodes will come to the same conclusion.  That's the consensus.  When the network propagates the message that consensus has been reached, nodes can start thinking of broadcasting a next consensus list, built on the previous one.
If all of this is done without reward, and just on the basis of "altruism" because one wants the system to work, there is no incentive to "game the system", to "make others accept YOUR consensus list" and so on.  There's nothing at stake, apart from contributing to the good functioning of the system.  From the moment you introduce rewards, it becomes strategic to be the one that gets HIS/HER consensus proposal and not your peer's one.  Instead of cooperating in the network, you compete.  

Such a system is totally opaque to any form of long-range roll-back attack, simply because no roll-back is possible.  Reached consensus is reached consensus, done real-time and on-line.   The price to pay is that verification is only on-line.  If you leave the network, you trust your network peers that they continue to build the consensus.  
You can think of ways to recover from the improbable "global network split", by accepting, when the network unites again, a merge consensus, that accepts all that happened on the two split histories.    If you discover nodes that have another prong, with another history from a given point in time, you accept as well their transactions, as those in your prong.  
A priori, these two prongs should be compatible: this is like in a DAG like coin: there can normally not be double spends of the same coin, or it would mean that there was a node, sharing both half-nets and doing double spends, one on both sides.  Splitting the network is already difficult, but splitting the network and being on both at once is even harder.  If ever that happens, one could accept the double spend exceptionally.  That's just some extra coin creation, no problem if it is rare enough.  The important thing is that no roll-back is possible.
Again, this merging is quite straight-forward if consensus DOESN'T come with reward.  Because merging the prongs doesn't mess with rewards that don't exist.


Well, if supply follows demand, price will stabilize.  And supply is value-controlled: if *making* a new coin has a fixed economic cost, you will ONLY make it if its market price is higher than that cost.  So as long as there IS a demand, this will converge to the set price.  You are right of course that if demand simply plummets, the lowest supply (namely NO supply) cannot go lower than zero.  You might introduce a systematic destruction of coins if you think that's a problem: a destroyed transaction fee, which is a given percentage of the transacted value.  It would indicate a "half life of coin": grossly the number of times you can transact a coin before it is gone entirely.  If you put that to, say, 1%, a coin's half life would be about 100 transactions, grossly.  I don't know if such friction is a good idea, though.  At least, it would make speculation impossible.  You put an upper cap on value.

It is indeed. This proposal is radical, however it maintains the core principles of bitcoin, including the reason you state.

In fact, the actual result of difficulty adaption is rather the opposite.  If you have "one bad actor with massive amounts of hashing power that can mine all blocks for himself", then the automatic difficulty adaption is *in the advantage* of this actor, not against this actor.  

Imagine a system where you have 100 "normal" solo miners that mine a block every 10 minutes.  Each miner has, on average, 1 chance in 1/100 to mine a block.  His average time of success is 1000 minutes.  His success series is a Poisson series with a time constant of 1000 minutes.  Each miner has an individual, independent Poisson stream of success with a time constant of 1000 minutes, and the total block rate is hence a Poisson stream (the union of these 100 individual Poisson streams) with an average of 10 minutes.

Now, imagine that our 'bad actor" arrives with about 100 times more hash rate.  Without adaption of difficulty, this doesn't influence the other Poisson streams.  Our new actor will make new blocks on average every 0.1 minutes, but our 100 other actors still have their block every 1000 minutes each.  

Come adaption: difficulty goes up x 101 (let us say, 100).  Or bad actor now has a Poisson stream of success of 10 minutes on average.  Our other actors are now only getting each a success every 100 000 minutes.  That's one block ON AVERAGE every 2 months.

It is not just that our bad actor has diminished revenue of our 100 normal miners: he also increased seriously the FLUCTUATIONS of their revenue.  Mining doesn't only become less profitable, it also becomes riskier.

So the difficulty adaption made life much worse for the "good and numerous" actors.

If you go from 100 to 1000 "good" actors at the start, they go from one block every 10 000 minutes (one block every week) to 1 million minutes (one block every 2 years).   Suppose that the average revenue still allows the good miners to make up for their PoW.  On average every week a block makes them get a relatively steady stream of income ; however, on average every 2 years a block is way, way too risky.

So, difficulty adaption favours the big "bad" actors.  It pushes the smaller miners into oblivion.  You limit the amount of independent solo miners to a small number.  in other words, you centralize, simply already by the effect of income fluctuations and hence, financial risk.  Add to that economies of scale, and you're done.

When Bitcoin was being developed on a university campus by academia it worked fine but now
we know that it won't scale and consensus might work on a dozen or so machines but now we
have 20,000 machines doing the "consensus" which leads to a lot of wasted effort

The internet runs on an array of specialized nodes providing specific services and the Bitcoin "Every node for himself"
philosophy is a disaster but then the Lightning Network goes the other way when it comes to off-block private ledgers
running on banking hubs so we end up with a single point of failure unless paying miners Tx fees to open up lots of
channel for our wallets.

Come on boys we had web-farms providing redundancy on the internet twenty years ago to spread the
load because it's starting to look to me like bitcoin is designed just to keep the miners happy and yes someone
needs paying to provide hosting services but lets start thinking about the public when it comes to design and
put the miners more to the back of the queue.

CPU-Wars and PoW to make a living, i don't know what they will think of next

New technologies such as blockchain have the potential to reduce cyber risks by offering identity authentication through a visible ledger

For anyone interested, I've attached a draft whitepaper explaining all the details of the proposal to the first post in this topic.