please delete | Bitcointalksearch.org

Theb

hero member

Activity: 1680

Merit: 655

Quote from: bob123 on July 23, 2018, 03:15:31 AM

Since 1) and 2) already has been commented, i'll focus on 3) and 4).

Quote from: SapphireSpire on July 22, 2018, 06:04:46 PM

3. Adjust the block reward according to the mining difficulty.

This would destroy the 'fixed supply' property of bitcoin.
You could easily generate more bitcoin by simply inserting more hash power into the bitcoin.

This would have a negative effect on the price (dollar value would drop + volatility would heavily increase since the whole supply and supply injected into the network hourly would vary extremely).

I will have to agree, if this kind of system is implemented you are giving the miners the chance to take advantage of the block reward, they could easily obtain more Bitcoin. They could also easily choose when they will mine or not depending on what block reward is given based on the level of difficulty they will have which will also be bad to the network overall.

KonstantinosM

hero member

Activity: 1492

Merit: 763

Life is a taxable event

Quote from: SapphireSpire on July 22, 2018, 06:04:46 PM

...I've come up with a few ideas:

1. Keep transactions as small and simple as possible- 2 input/2 outputs, 200 bytes or less.

2. Minimize the block time by keeping the mining difficulty as low as possible without jeopardizing network stability and consensus. This will also help decentralize mining.

3. Adjust the block reward according to the mining difficulty.

4. Adjust the block size according to the mempool size so miners can keep up with high transaction volume.

1. Is impossible due to people having to consolidate their inputs. Not all your bitcoin is (or should be) stored in a single private key and address pair. If you have 1 bitcoin and 10 private keys/ public addresses and you want to spend all of that, it's way more efficient, and easier to do 1 transaction using all these inputs than it is to do 10 different transactions which are going to get picked up and put into a block in different times.

2. This would make the supply of bitcoin variable. One of the core principles of bitcoin is to protect against central bank schemes/ monetary supply inflation. 2.b. This will not help decentralize mining, we're talking about orders of magnitude of time until you would get a single block. If now you got a single block in 1000 years, and it is reduced to 100 years, you'll still probably die blockless.

3. Again, no fixed supply of Bitcoin

4. Has already been discussed. I don't want to have to download store and validate 10 Terabytes every month on my computer.

nc50lc

legendary

Activity: 2534

Merit: 6080

Self-proclaimed Genius

Welp, shared ideas from a random member could be a gold mine.
Even the simplest simple-thoughts can be as great as well-processes ideas.

But frankly, most of these (OP) has already been discussed thoroughly.

Quote from: SapphireSpire on July 22, 2018, 06:04:46 PM

2. Minimize the block time by keeping the mining difficulty as low as possible without jeopardizing network stability and consensus. This will also help decentralize mining.

This will also destroy the fixed supply property
but maybe, the Author wants to tell us that all of those four (list) to work together to patch the negative effects of implementing just one.
Combine #2 and #3 and there's a possible work around to increase the block time without destroying the fixed supply.
Combining all of them will pose a threat to the seemingly perfect decentralized setup we currently have.

Overall, it's a bad idea.

bob123

legendary

Activity: 1624

Merit: 2481

Since 1) and 2) already has been commented, i'll focus on 3) and 4).

Quote from: SapphireSpire on July 22, 2018, 06:04:46 PM

3. Adjust the block reward according to the mining difficulty.

This would destroy the 'fixed supply' property of bitcoin.
You could easily generate more bitcoin by simply inserting more hash power into the bitcoin.

This would have a negative effect on the price (dollar value would drop + volatility would heavily increase since the whole supply and supply injected into the network hourly would vary extremely).

Quote from: SapphireSpire on July 22, 2018, 06:04:46 PM

4. Adjust the block size according to the mempool size so miners can keep up with high transaction volume.

This also wouldn't help the network at all.
If the blocksize would be adjusted relative to the transactions inside the mempool (which mempool? Each node has a different mempool. How would you reach consensus?) 0 to 1 sat/B transactions would be standard.
This would open up new attack vectors, since there won't be any mechanism against spam. The current mechanism relys on an attacker paying massive amounts of money to keep a spam attack ongoing.

We could also simply remove all transactions fees in this case. Same consequences.

TheQuin

hero member

Activity: 2576

Merit: 883

Freebitco.in Support https://bit.ly/2I9BVS2

Quote from: SapphireSpire on July 22, 2018, 06:04:46 PM

1. Keep transactions as small and simple as possible- 2 input/2 outputs, 200 bytes or less.

That would be counterproductive. Transactions that have many inputs and/or outputs are more efficient as there is less overhead than sending multiple transactions. A lot of the network congestion that occurred at the end of last year was caused by Coinbase NOT batching their transactions and spamming the network with lots of small high fee transaction.

bitmover

legendary

Activity: 2352

Merit: 6089

bitcoindata.science

Quote from: SapphireSpire on July 22, 2018, 06:04:46 PM

2. Minimize the block time by keeping the mining difficulty as low as possible without jeopardizing network stability and consensus. This will also help decentralize mining.

I think that statistically this does not make sense. As pools have more hashpower, they will solve more blocks and this will not help decentralize mining.

Ethereum has a smaller blocktime, but their mining is more centralized.

Also, smaller blocktime leads to more involuntary forks, which is not good for the network.

SapphireSpire

jr. member

Activity: 49

Merit: 38

nothing to see

Topic: please delete (Read 256 times)