Topic: Alternative minting methods (Read 2092 times)

If the scale is not linear you'll have people gaming the system. If the reward benefits small miners, the big miners will split up their wallets to look like small miners. If the reward benefits big miners, small miners will join up to become big miners.

Does not scale and is far from neutral. Is supporting a church charitable? The NRA? Greenpeace? PETA?

Great idea.
Is it implementable?

How about "Proof of Charity"?

Similar to proof of burn, but instead of sending to an verifiablely unspendable address you send it to support a worthwhile cause.

Of course, this requires trust in the charity selected.

OK. Hope you won't mind me throwing another idea to be kicked around.. kicked in.

I have another POW/POS Chimera Horse.

Let's say you have GHOST protocol branch selection in place. This uses the branch with the most POW as the deciding factor, stales included. This value would need to be normalised to a ratio value from 0-1.

Now you do the same calculation but instead of using POW you use the sum of the total BTC balances, POS, of all the accounts used in txns in the blocks of the various branches. This value would also be normalised to a ratio value from 0-1.

You then add these values at each node of the tree, and use a GHOST protocol that uses heaviest POW+POS branch selection. (That's why they are 'in some way' normalised values)

This way if you wanted to take over the network you would need a minimum 51% POW AND minimum 51% POS(of the recent txns in the blocks). Large/Medium stake holders might regularly perform a tiny txn (to themselves if necessary), simply to show their approval of a branch, by adding their not inconsiderable BTC balances to the POS heaviest branch selection process.

A user could send a TXN and include the hash of a block that HAD to be in the chain that this txn would eventually be added to. That way users would have some say in which branch to go for.

Well - this is to redistribute to fees. And it's not quite like the other Proof Of Stake systems out there, as they use your stake to allow you to mine, and find blocks. You would get your cut of these redistributed fees even in a paper wallet offline.

What if, like Proof of Burn, we just throw the fees away.. ? (I am assuming minting is finished..)

So that they are only used as a method to prioritise which txns to add to your block and to stop txn spam DOS attacks.

Can a system where the miners ARE NOT REWARDED work ?

Is the 'Tragedy of the Commons' the ONLY argument against letting people decide when to upgrade their kit ?

I can see that the network hash rate would be lower than it is now, but so would the incentive to acquire a high hash rate, as you don't make any money from it..

The only reason someone would try and garner 51% is to 'destroy' bitcoin, and maybe a different mechanism could be used in that case.

If there weren't 'dedicated' miners, you could maybe change the POW algorithm regularly to prevent ASICS coming in to play. CPU only, since users wouldn't really care.. as long as their computer can still compute it.

That's called Proof of Stake then again...

You could redistribute based on their BTC balance as a percent of the whole. No Sybil attack.

I'm also saying that this would be the absolute minimum fees possible to prevent spamming the network with txns. So maybe just chuck them away. Re-Mint if necessary.

Tragedy of the commons.. Yep.. it hangs over us all, but i'm not 100% that someone who had literally Thousands/Millions of btc would allow this to happen.

Well, the obvious problem with distributing fees to all miners is a sybil attack - someone (secretly) controlling thousands of tiny miners. Also it might create a tragedy of the commons scenario where it is much cheaper to not mine at all but the influence on the total network security is tiny. A similar issue is with environmental pollution for example - there is a whole lot of air out there and you blowing a bit of smoke in it won't really change a thing. If everyone thinks that way though, you'll have a problem collectively.

[BANG]! - That's the horse I was flogging earlier, being shot.. Cheers Tiers.

I was thinking - what if you didn't pay the miners at all.. ? What if the minimal fees, just to stop DDOS, were simply redistributed, in some way, to ALL the users. Can think of a couple of ways. Maybe just lose them completely. (Yes - there would need to be some other system to MINT the coins)

Would the whole network just collapse.. ?

What if you, the bitcoin user, ran the full node, and it was up to you to protect your investment, by making sure the hash rate of the network was high enough to prevent a trivial 51% attack ?

People could be compensated for allowing SPV clients to connect to them.  

If there was no money in it for the miners, would we still have the miner's issue..

Those with 10's of thousands of bitcoins, would simply choose to upgrade their equipment. To protect their stash. Kind of - Proof of Stake, but voluntary.. Those with more of a stake, would HAVE to invest in mining equipment, or risk losing it all.

Just a thought. (Down Dobbin!..)

So far, all of the alternate methods proposed have the flaw that the miner is required to own coins before they can be a miner.  Also, none of them solve the problem of centralization that is begining to happen in the bitcoin network.

Another method I have been thinking about is a full node lotto.  The only requirement to be a miner would be to run a full node.  One full node is randomly selected to recieve the payout for each block.  There are two ways I can imagine this being implemented.

First would be to include a list of all miners on the blockchain.  Based on the hash of the previous block or a random number, one is selected to be the miner of the next coin   (max_possible_hash / hash =  total_miners / winning_miner).  The problem with this method is that it would require miners to be registered, possibly decreasing anonymity.

Another way would be to have a crawler(or several) traveling from full node to full node.  Upon arriving at a node it builds a block and does some sort of verification to see if it can be a valid block(eg. pick a rondom number, if number is less than threshold, block is valid).  If so the node publishes the block and recieves the block reward.  If not the crawler moves to a different node.  The problem with this is that there needs to be some method of ensuring that the crawler script is being executed honestly.

In additon to this it would be good to have a way to ensure that a person or organization could only run a single node, or this would just turn into a proof of diskspace scheme that would be vulnerable to centralization.  One way I have considered is to only allow one miner per IP adress, but this has the obvious flaw of destroying anonymity.  Not sure if there is a solution for this.

The inherent problem is that hashing power is more valuable the more BTC you have.

A pool with 1000 BTC can pay more per GHash than someone can earn on their own, unless they have 1000BTC themselves.

You could set a maximum, rather than keeping it scaling.

Anything more than 10 BTC would just give a multiplier of 10.

I am not sure how that helps much though.  Each pool would need 10 BTC to startup and then they can accept any amount of hashing at standard efficiency.

You could limit a pool's hash somehow.  If you have 25% of the BTCs, you can boost up to 50% of the hashing power, but not sure how best to handle that.

Sorry to keep flogging this horse, just want to get it out of my system..  

What if you used some kind of logarithmic scale, with regard to your Hash Rate * BTC Balance. ?

So that the effect is much more for small miners.. and diminishes for the larger miners.

Somehow 'levelling the playing field', and make it so that a small miner benefits more than a large miner.

So, as a simple idea..

Total Hashrate = Computer Hashrate * SquareRoot(BTC Balance)

Then combining into your previous example.

1GH with 10 BTC = effective 1GH*SQRT(10) = 1GH * 3.16 = 3.16GH

Then x2

2GH with 20BTC = effective 2GH * SQRT(20) = 2GH * 4.47 = 8.9GH

8.9 / 3.16 = 2.8 times larger only..

Maybe the equation could be stepped so that

BTC balance < 10 you use the original.
BTC balance < 100 you use the squareroot. (of the difference over 10 + original for 10)
BTC balance < 1000 you use the cuberoot.  (of the difference over 100 + squareroot up to 1000 + original for 10) etc.. so that the curve is continuous, like taxes..

This way small miners would have the greater advantage for pooling together, but larger miners wouldn't ?

I suppose Pools would then break into smaller pieces to gain as much TOTAL HASH RATE as possible, some simple equation would determine that, BUT '..Pools would then break into smaller pieces', allowing more players onto the chain.

..TierNolan.. ATTACK!

It would depend, I guess.  You could set it up so that to commit with a coin, you need to the private key.

If only 1 coin could be used at a time, then that would force the effect.  You have to create a transaction that has all your money in a single output.

There could be a timeout.  You can only use transaction outputs that are at least 1024 blocks old.

This would make it hard for pools to pool the coin.  They have to combine all their investors coins into a single coin.

I still think you have centralisation, but it is like a bank where you have to trust the pool.

Yes - i did think this.. the Product of HashPower and BTC balance has a few strange side properties..

BUT - it does mean trusting someone with your coins.

And, you can't sell your coins or spend them. A miner will have to pay out at some point ? A user will want to use his mined coins..

I know there are issues.. it just seemed like a very easy way of linking balances into the POW conundrum.

This means that if 2 people join forces, they increase their effective hashing power.

A has 10BTC and 1GH/s.  His effective rate is 10 * 1 = 10GH/s.

If he joins forces with another person with the same stats, then they have 20BTC and 2GH/s.  That is 40GH/s effective.

This is centralising.  Pools would "rent" BTC and hashing power.  A pool with 20% of the market could pay twice as much as a pool with 10% of the market.

Proof of burn means that your virtual rig is just as good as a "real" rig.

Wouldn't this approach just incentivize people using webwallets (hosted at mining pools) and not transfering real Bitcoins any more? Miners likely would pay interest for deposited coins and transactions would happen off-chain on centralized or decentralized ledgers, not on Bitcoin any more...

5/ STAKE YOUR WORK.. ?

Have been mulling this over and not sure if it can/can't work.

Basically it is a hybrid POW/POS system.

It is very simple.

You divide the current difficulty by the wallet balance of the miner. Minimum 1 btc balance used (even if you have less).

So - if you have less than 1 btc(or whatever alt-coin) you have to hit the current difficulty.

If you have 100 btc, it's 100 times easier for you..

Someone with twice as many coins, has twice as much POS power. POW still uses regular hashing.

What I was thinking is that it would be like buying ASIC equipment, so that everyone could just buy coins and increase their hash power.

Unlike current systems, it doesn't run out after you spend it. You don't have to have TXN outs that you haven't spent. It's always there.

Basically your hash power is now your 'Computer's Hash Rate * Your BTC Balance.'

A one man band with one computer hashing away at 1KHash, who had 1000btc, would have the 'effective' hash rate of 1MH.

I also thought this would affect the current Mining Pools.. as their hash rate would not be the sum of all the accounts that mined. It would be just the central miner's balance..

(I also thought that maybe you could have a separate coin exchanged on chain p2p, and that was your MiningPower, so that a market price would emerge.. The Total MP coins would equal hash rate.. or something.. but that's for another day..   )

Consensus (https://ripple.com/wiki/Consensus) might be a possible way too, unlike some of your other methods I am not so sure if it works for distributing currency units though, only to agree on a certain ordering.

Also one of the most obvious ones is a central authority. Probably not that applicable to Bitcoin, works with a LOT of current systems though.

Didn't know about proof-of-burn. seems to me like a great idea! If implemented, you could have your cloud miner running without wasting physical resources!