Topic: LumpCoin...a better block chain? (Read 895 times)

I wish it was.
It doesn't yet exist, but hopefully will.
For now I am just trying to get feedback on the general idea, but apparently no-one cares.
I also do not know how to write source code.

Give please a link to the source code.
Coin already is traded on exchanges?

I assume it was you who voted "the whole idea is just stupid."
If so, I am very disappointed that a "Hero Member" will do that just because of an ill-chosen name. I assumed that long-established members of this community are more mature and would think deeper than "the name sounds stupid, therefore the whole idea is stupid."

As to my previous post, the idea of making blobs non-perishable is flawed because a selfish miner can refuse to publish blobs and pay blob fees to him/her-self, a fee of one half should provide enough incentive to include a blob, unless the miner is already a 51% attacker.

Any coin named Lump deserves to perish. A bad joke?

A better idea could be for blobs to be non-perishable, blobs always remain valid and can be confirmed at any time, however, they only give proof-of-work weight to the blocks it is built upon, this reduces the problem of capricious miners rejecting blobs (blob fees more than one half are unneccesary), a miner could accumulate a huge stash of blobs from an early block and publish them all at once, but that is no different from conventional attempted 51% attacks. The blob rewards depend on when the blob is confirmed.

A better way to distribute the coins is as follows (similar schemes can work for non-blob currencies):
First 1*10^7 lumps create 1125.899906842624 coins each.
Next 2*10^7 lumps create 562.949953421312 coins each.
Next 2*10^7 lumps create 281.474976710656 coins each.
Next 4*10^7 lumps create 140.737488355328 coins each.
Next 4*10^7 lumps create 70.368744177664 coins each.
Next 8*10^7 lumps create 35.184372088832 coins each.
Next 8*10^7 lumps create 17.592186044416 coins each.
Next 16*10^7 lumps create 4.398046511104 coins each.
Next 16*10^7 lumps create 2.199023255552 coins each.
Next 32*10^7 lumps create 1.099511627776 coins each.
Next 32*10^7 lumps create 0.549755813888 coins each.
Next 64*10^7 lumps create 0.274877906944 coins each.
Next 64*10^7 lumps create 0.137438953472 coins each.
And so on...

Those newly-mined coins are shared between the blob miner and the block miner at some ratio, they can be split half-and-half, or the blob miner can receive 1/4 and the block miner 3/4 (I still don't know which is better).
This scheme results in a hard upper limit of 45035996273.70496 and the rewards reach 4 pico-lumpcoin at 100663290*10^7 lumps, 2 pico-lumpcoin at 134217722*10^7 lumps, 1 pico-lumpcoin at 201326586*10^7 lumps, and finally breaks down at 268435450*10^7 lumps.

Since lumps are produced about every 3.1 seconds, as in the previous post, and one year is about 3.1*10^7 seconds, "*10^7 lumps" can be mentally replaced by "*1 year."

This results in 1/4 of the coins mined the first year, 1/4 the next 2 years, 1/8 the next 2 years, 1/8 the next 4 years, 1/16 the next 4 years, 1/16 the next 8 years,....

Please comment and vote on the poll.

The main problem appears to be that selfish miners may refuse to include blobs and everyone's effort is wasted. One idea is to fix the BlobFee at one-half the reward, I doubt miners would get more than that by mining selfishly. This does not appear to be a definite fix.
Assume a miner (Eve), who owns 10% of the hashpower, tries this selfish approach, she mines lumps, but only attempts to confirm his own blobs.
What does she lose? She loses block fees, and, if someone mines a block soon after her, her block will be abandoned.
What does she gain? She may get a disproportionally large amount of new coins by preventing others from receiving their share, which may increase the value of her coins, but if the difficulty is set by the frequency of blocks, she will not get coins any faster. If the BlobFee coefficient is more then the fraction of total coins she owns, she clearly losses more than she gains. Giving most of the blob reward to the block miner (15/16, or maybe 3/4 or 1/2 is enough) would reliably fix this issue. Also, selfish mining may reduce the value by reducing trust in the currency.

Also, should orphaned blobs be discarded or kept as PoW?

Also, 1 block per 32 lumps and 99.2 seconds per block has nice numbers, 1/2 blobfee gives the block miner about 31 times more, while 3/4 gives 93 times more (I hope publishing blobs is still worthwlile).

One way to fix this would be for honest miners to only consider mining from leaf blocks (blocks with no blocks after them), choose the one with the most PoW (blobs and blocks counted equally, including available blobs after the last block), and include all available blobs in the block.

However, miners need some incentive to include lumps, they do not really have any incentive to not include them, and they make the block less likely to be orphaned and yield blob fees. If high fee blobs are released after a block (that does not include them) is mined, some miners may try to mine a parallel block including them, however, their block may well be orphaned if more blobs are mined to the main block before they mine a block, also, blobs mined here are likely to be abandoned, so the incentive to do this is highly questionable, specially if blob fees (which may not be necessary in the first place) are capped at the lump reward. Any thoughts on this issue (or non-issue) would be greatly appreciated.

To avoid halving problems, blob fees can be expressed as a fraction of the block reward (the odd pico-lumpcoin can go either way) and the blobs can be ordered based on the hash of the block (hash the block hash with each blob hash, order by value of resulting hashes for reward purposes, in any case, the block has priority over each blob in it).

Right after a transaction is confirmed, it may briefly have less proof of work then a potential fork, to be secure, it must accumulate more proof of work.

Since Litecoin appear successful, a block time of 150s may be appropriate, blobs would then pop up every 10s, for a total lump rate of 9.375s.

The reward function described above is ill-thought out as it gives very large rewards to the first miners, better would be for example, first 1*10^6 lumps at 1 lumpcoin each, next 2*10^6 lumps at 0.5 lumpcoin each, next 4*10^6 lumps at 0.25 lumpcoin each...

Also, someone voted "the whole idea is stupid" I do not take this personally, getting offended by criticism is, in itself, stupid. However, I would greatly appreciate an explanation.

Also, someone voted "Yes (but can be improved)" I am very curious as to how, please explain.

Since 37.5 seconds * 1000000 = ~1 year (slightly more, but the actual rate of lumps may depend if difficulty is set by all lumps, just blocks, or just blobs), the reward scheme shown above yields the first mega-lumpcoin in years 0-1, the second in years 1-3, the third in years 3-7, the fourth in years 7-15, the fifth in years 15-31, the sixth in years 31-63, the seventh is years 63-127, 8th in 127-255, 9th in 255-511, 10th in 511-1023, 11th in 1023-2047, 12th in 2047-4095 13th in 4095-8191, starting with a reward of 1.09951162778 lumpcoin allows exact halvings for many billions of years, thus providing incentive to mine without over-inflating.

The main question is, however, how to resolve new block versus parent block plus new blobs competitions, without giving up the security advantage of using blobs?

On an unrelated topic, PoS may work for confirming transactions, but distributing new coins proportionally to coins a minter already has defeats the purpose of "distributing the coins in a decentralized manner" (am I right in attributing this quote to Satoshi Nakamoto?)
To sum up, please, give me more than 2.3219280948874 bits of feedback!

This cryptocurrency combines features from Bitcoin and my previous invention, Dust.
Each lump attempt (iterated by miners) has the following form:

MinerAddress Difficulty BlobFee PreviousBlockHash Counters HashRoot Iterator

MinerAddress - Self explanatory.
Difficulty - Set by network (I don't know exactly how this works).
PreviousBlockHash - Self explanatory.
Counters - Blockhight and LumpNumber.
HashRoot - Hash of recent transactions and blobs.
Iterator - Self explanatory.

For the lump to be valid, the first bits of the hash H(MinerAddress Difficulty PreviousBlockHash HashRoot Iterator) must pass the Difficulty.
The last four bits of the hash determine whether the the lump is a block (if they are 0000) or a blob otherwise.

Blobs are added to the block chain, (with the HashRoot included simply as a string of bits) and do not conflict with each-other, multiple blobs can sit side-by-side in the block chain, each of them confirming the previous block.
Blocks are added to the block chain, they confirm (and contain) the recent transactions (transactions are no different from bitcoin transactions) and recent blobs.


If the Difficulty is set to yield blocks every 600s (on avarage), blobs are created (on avarage) every 40s and lumps (both blocks and blobs) every 37.5s.
Each lump yields a quantity R of lumpcoin, this changes over time but is the same for blocks and blobs, in addition, blocks collect transaction fees and blob fees.

Honest miners determine where to mine by selecting the chain with the most PoW (blocks have somewhat more weight) and try to include recent blobs. If everyone else does this, there is nothing to be gained by defecting, since (even without blob fees) including recent blobs benefits the miner by reducing the risk of a block being orphaned (it makes no difference for blobs, blocks can still be orphaned if several blobs are found before word of the block gets around, this can be fixed by giving more weight to blocks in choosing where to mine). Mining from blocks that are to be orphaned in the aforementioned manner is also stupid, since both blocks and blobs may be orphaned.

This system has some advantages over standard Bitcoin (the most obvious is finer distribution of coins) but more important is finer distribution of confirmation.
Assume, for now, that the block to blob weight ratio is 1+, (same weight, block wins in a tie, fresh block can be orphaned by 2 quick blobs, different ratios may be better).

Imagine Alice owns a coffee shop, Eve, who controls 10% of mining power, walks in and asks for a cup of coffee. She pays Alice with Bitcoin and Alice serves her the coffee after 2 confirmations (about 1200s). To reverse the transaction, Eve has to mine to catch up with the network, she is behind by 2 blocks (the math may not be right, I hope I can still get the point across), the chances of this are on the order of 1% (source: guess).

Now imagine Eve pays with Lumpcoin, as before, Alice waits about 1200s and about two blocks are mined. However, there are about 15 blobs in the second block, and all of them confirm the transaction. To reverse this, Eve has to catch up by 18 blobs, 1 block and 17 blobs, 2 blocks and at least 15 blobs, 3 blocks and 14 blobs, 4 blocks and 13 blobs, et cetera. In any case, she is behind by at least 17 PoW's and the rest of the network is chugging one out every 41.67s.
If the ratio is 2+ (3 quick blobs to orphan), Eve has to catch up by 20 blobs, 1 block and 18 blobs, 2 blocks and at least 15 blobs, 3 blocks and 13 blobs, 4 blocks and 11 blobs, 5 blocks and 9 blobs, 6 blocks and 7 blobs, 7 blocks and 5 blobs, 8 blocks and 3 blobs, 9 blocks and 1 blob or 10 blocks. However, options closer to the end of the list are increasingly unlikely and, in even the unlikeliest cases, she is still behind by 10PoW's.

You may ask what advantages this has over mining blocks more often (lower difficulty), the answer is that in, for example, DOGE, each block conflicts with parallel blocks and the result is a highly branched block chain, in Lumpcoin, blocks conflict with each other and, to an extent, with lumps, but lumps do not conflict with each other.

The lump string may also contain a block counter and a total lump counter. The lump reward R can be 1 lumpcoin for the first lump, 0.5 for the next 2, 0.25 for the next 4, 0.125 for the next 8, et cetera, thus maintaining relative scarcity while maintaining non-zero lump rewards to the end of time. To order lumps in one block, the block can come before the blobs and the blobs ordered by hash value.

Some things I am not clear on:
What prevents a miner from gaining more weight for his/her lumps without significantly changing difficulty (Bitcoin also has this issue?) by increasing the difficulty very slightly?
How is difficulty set in the first place?
What value is best for the fraction of lumps that are blocks?
What weight ratio is best? 1+? 2+? 16?
One issue I see is that a malicious miner may mine blobs and release them right after a block is mined, just to disrupt the network, is this a problem?