Decentralizing Mining - The future of BitShares Mining

[bytemaster]

What about 51% attacks? With the 6 month rule the overall hashing power will go down quite a lot compared to now. This makes it a lot easier for a single individual to pull off a successful attack.

It actually makes it harder because they could not finance the attack with the block rewards.   For example, suppose someone wanted to do a 51% attack today.  They could spend 100K / day on Amazon, but wouldn't be able to maintain the attack unless they had access to 100K * 180 days worth of capital. 

[jh00]

What about 51% attacks? With the 6 month rule the overall hashing power will go down quite a lot compared to now. This makes it a lot easier for a single individual to pull off a successful attack.

[bytemaster]

As I just braised this topic , so im clear

The only change to the PoW mechanisim will be in this " timing" factor ?

Effectivly of course there would be much recompiling of the miners and individuals running multiple instances , but where im not clear is around this  idea of a " background run " client .

Perhaps I will read the topic ha ha .

If the user is running Keyhotee as their Email client and there is a passive, low-priority thread that is always mining they will not really care, but in aggregate it will represent a significant amount of hash power that is fully decentralized.   Make sure the client is aware of battery powered devices and otherwise respect the user and it is win-win.   The software is free, but costs a couple dollars per month in electric costs that few will consider or care about. 

[digitalindustry]

As I just braised this topic , so im clear

The only change to the PoW mechanisim will be in this " timing" factor ?

Effectivly of course there would be much recompiling of the miners and individuals running multiple instances , but where im not clear is around this  idea of a " background run " client .

Perhaps I will read the topic ha ha .

[digitalindustry]

If i had to rate this as policy , its pretty good , especially if the user has the option to incrementally cash out with a penalty .

[bytemaster]

In any system , if a managing entity has to or consensus intends to provide direction , it is always best from a policy setting to do this though phased incentives .

On the " phased incentive" rule book , you could look at banning something as a failure .

So you start at a failure if you are proposing to ban anything from a policy point of view .

Then you phase incentives , and the better and more phased , the better and more effective your policy .

A solid insight, it avoids economic discontinuities and gives the market more room to adjust to changing conditions. 

[digitalindustry]

In any system , if a managing entity has to or consensus intends to provide direction , it is always best from a policy setting to do this though phased incentives .

On the " phased incentive" rule book , you could look at banning something as a failure .

So you start at a failure if you are proposing to ban anything from a policy point of view .

Then you phase incentives , and the better and more phased , the better and more effective your policy .

[bytemaster]

In economic old speak you want to raise the cost if pools and use that " energy" to subsidize individual miners .

Interesting .

What about the technicals , and how do you propose to enforce this in a open source environment .

On the Bitshare side I understand the hard coded 6 month system , but , oh wait , I think I understand .

Yes, that is exactly what is going on in economic speak

[bytemaster]

1. Initial difficulty and difficulty adjustment
Would you consider a dynamic difficulty adjustment? Means the difficulty will adjust block by block instead of every 2016 or 4032 blocks. It needs limiting the adjustment range, but I saw it is working well in some of the altcoins. Considering 5 mins block interval is relatively long, dynamic adjustment will be more flexible. And you can have a much higher initial difficulty to prevent what happened to Protoshares, then let the network adjust itself and not worrying hash power too low.

Yes, I already have dynamic difficulty adjustment in place based upon a continuous moving window.

2. Block mature in 6 months
It is good to prevent the cloud server, because people have to hold the bitshares for 6 months before they sell it.
But it is not effective to block pools. Pool can change the payout to p2pool, just like what 54.238.185.113 is doing now, let the rewards mature locally, instead of store in the pool. Something need to be done to block p2pool/immediate payment if you decide so.

This is easily prevented by requiring a single payout address for each block.

3. Solo mining lottery
It is easy to say that the rewards is same base on math. But after 4 years of Bitcoin, everyone is used to pool mining. I would say 90% of miners would prefer 0.5 stable payment everyday instead of a chance of hitting a block every 3 months. The difficulty and hash power is changing significantly time to time, even myself want to be paid for what I am contributing to the network right now. It is small amount everyday, but I know my miner is working.

The goal is that people shouldn't think about 'mining for a profit' and it is something that just happens automatically by downloading the default client.   Mining is a speciality and we want regular users to not even realize their client is doing it so they run a full node. 

Mining pools will still exist, they will just have much higher costs because they have to finance 6 months worth of mining. 

[digitalindustry]

I realize what you are trying to achieve with the 6 month maturity, but that really feels like a long time. Being able to make transactions in 90 days vs. 180 days seems more realistic. I just think people will lose interest if they are not able to utilize the fruits of their mining labor in a more timely manner. I do want to reduce the dependency of pools and initially was drawn to PTS when I heard about it on the podcast, a system with reputation and DACs, I was hooked. Felt like finding BTC back in 2011 all over again. When I mined for 3 days solo, it was very disappointing to receive zero (I know QQ right?) and then it immediately evolved into pools, or having to be a member of one to see any rewards. So yeah, that needs to be fixed if you are trying to not have the gaming of the system, botnets, etc. Maybe there could be a vesting period vs. maturity? If you need to spend earlier you take the penalty, but after X amount of time and you're 100%. I just feel quarterly would work better then bi-annually. Keep up the great work, I have a good feeling about this.

Yet another great idea!   If the Share Bond has a face value of 60 BTS but matures in 6 months in a linear manner, then in 1 month you could get 10 BTS (the other 50 BTS are paid as dividends) and in 3 months you would have 30 BTS... at the 6 month mark you get your full 60 BTS.    This keeps the shares liquid and makes holding them very valuable, but gives users the opportunity to cash out early for a penalty.   

So I think we can combine them all.  Random maturity date, linear early-redemption penalty.

An idea like that is so good it could have been mine. Lol

[digitalindustry]

In economic old speak you want to raise the cost if pools and use that " energy" to subsidize individual miners .

Interesting .

What about the technicals , and how do you propose to enforce this in a open source environment .

On the Bitshare side I understand the hard coded 6 month system , but , oh wait , I think I understand .

[bytemaster]

I realize what you are trying to achieve with the 6 month maturity, but that really feels like a long time. Being able to make transactions in 90 days vs. 180 days seems more realistic. I just think people will lose interest if they are not able to utilize the fruits of their mining labor in a more timely manner. I do want to reduce the dependency of pools and initially was drawn to PTS when I heard about it on the podcast, a system with reputation and DACs, I was hooked. Felt like finding BTC back in 2011 all over again. When I mined for 3 days solo, it was very disappointing to receive zero (I know QQ right?) and then it immediately evolved into pools, or having to be a member of one to see any rewards. So yeah, that needs to be fixed if you are trying to not have the gaming of the system, botnets, etc. Maybe there could be a vesting period vs. maturity? If you need to spend earlier you take the penalty, but after X amount of time and you're 100%. I just feel quarterly would work better then bi-annually. Keep up the great work, I have a good feeling about this.

Yet another great idea!   If the Share Bond has a face value of 60 BTS but matures in 6 months in a linear manner, then in 1 month you could get 10 BTS (the other 50 BTS are paid as dividends) and in 3 months you would have 30 BTS... at the 6 month mark you get your full 60 BTS.    This keeps the shares liquid and makes holding them very valuable, but gives users the opportunity to cash out early for a penalty.   

So I think we can combine them all.  Random maturity date, linear early-redemption penalty.

[Amazon]

1. Initial difficulty and difficulty adjustment
Would you consider a dynamic difficulty adjustment? Means the difficulty will adjust block by block instead of every 2016 or 4032 blocks. It needs limiting the adjustment range, but I saw it is working well in some of the altcoins. Considering 5 mins block interval is relatively long, dynamic adjustment will be more flexible. And you can have a much higher initial difficulty to prevent what happened to Protoshares, then let the network adjust itself and not worrying hash power too low.

2. Block mature in 6 months
It is good to prevent the cloud server, because people have to hold the bitshares for 6 months before they sell it.
But it is not effective to block pools. Pool can change the payout to p2pool, just like what 54.238.185.113 is doing now, let the rewards mature locally, instead of store in the pool. Something need to be done to block p2pool/immediate payment if you decide so.

3. Solo mining lottery
It is easy to say that the rewards is same base on math. But after 4 years of Bitcoin, everyone is used to pool mining. I would say 90% of miners would prefer 0.5 stable payment everyday instead of a chance of hitting a block every 3 months. The difficulty and hash power is changing significantly time to time, even myself want to be paid for what I am contributing to the network right now. It is small amount everyday, but I know my miner is working.

Is it possible to build an embedded p2pool inside the bitshares client with a fully optimized miner inside? The entire network working as one pool.

[CryptoN8]

I realize what you are trying to achieve with the 6 month maturity, but that really feels like a long time. Being able to make transactions in 90 days vs. 180 days seems more realistic. I just think people will lose interest if they are not able to utilize the fruits of their mining labor in a more timely manner. I do want to reduce the dependency of pools and initially was drawn to PTS when I heard about it on the podcast, a system with reputation and DACs, I was hooked. Felt like finding BTC back in 2011 all over again. When I mined for 3 days solo, it was very disappointing to receive zero (I know QQ right?) and then it immediately evolved into pools, or having to be a member of one to see any rewards. So yeah, that needs to be fixed if you are trying to not have the gaming of the system, botnets, etc. Maybe there could be a vesting period vs. maturity? If you need to spend earlier you take the penalty, but after X amount of time and you're 100%. I just feel quarterly would work better then bi-annually. Keep up the great work, I have a good feeling about this.

[phoenix]

What if the invested period was varied. Not sure how hard this would be to program in, but say, every block's reward would have one of six maturity dates from one to six months. Kind of like a CD. That way there would be capital interest in the market right away, but long term investors, too.

You could have a 'random maturity date' based upon the hash of the block found such that the average maturity date is 6 months.  This would have almost no effect on pools who's average maturity date would be 6 months, but individuals solo-mining may get lucky and have a 1 day or week maturity.

This would keep the mining loto effect for solo-miners without enabling pools!

Since you're aiming for an average time of 6 months, there would be some blocks that take even longer, but if you really believe in the long term value of Bitshares it'll be worth it to wait even a few more months