Bitcoin Forum
June 16, 2024, 02:38:26 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 [5]  All
  Print  
Author Topic: Why I support Jeff's BIP100  (Read 10529 times)
jonny1000 (OP)
Member
**
Offline Offline

Activity: 129
Merit: 13



View Profile
September 07, 2015, 10:47:17 AM
 #81

Possibly, but there may be a trade-off here.  Miners would also have less power to track changing demand (seasonal surges and declines) and so the voting mechanic will be less effective in increasing network security.

I do not think BIP100 or economic policy should be used to cater to seasonal demand variations.  Although I guess its imposible to draw a clear line between short term and long term demand variations.

Perhaps Meni's elastic blocksize limit with rollover pools idea can be used for this.
teukon
Legendary
*
Offline Offline

Activity: 1246
Merit: 1004



View Profile
September 07, 2015, 11:05:09 AM
 #82

Perhaps Meni's elastic blocksize limit with rollover pools idea can be used for this.

Ah yes, that might do the trick.
jonny1000 (OP)
Member
**
Offline Offline

Activity: 129
Merit: 13



View Profile
September 28, 2015, 08:41:36 PM
 #83

Yes.  Although I don't know if BIP100 and Meni's idea can occur at the same time, as people may say its too complicated.  We could do one and then the other.
DooMAD
Legendary
*
Offline Offline

Activity: 3808
Merit: 3160


Leave no FUD unchallenged


View Profile
September 28, 2015, 08:56:57 PM
 #84

Yes.  Although I don't know if BIP100 and Meni's idea can occur at the same time, as people may say its too complicated.  We could do one and then the other.

I was looking at some sort of hybrid between BIP100 and BIP106, so that the increase or decrease would take both the miner vote and the network traffic into account.  The change would only go ahead if the two were in alignment.  Also, the doubling/halving part might prove excessive, so felt that needed curtailing:

The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain.  Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often, if needed.  One possible route is to take the best elements of BIP100 and BIP106.  BIP100 only considers what benefits the miners and not the users.  BIP106 only considers what benefits the users and not the miners.  So neither is particularly balanced on its own.  If we can find a way of allowing half of the "vote" to go to the miners and half to an automated, algorithmic vote based on traffic volumes, then we maintain some kind of equilibrium that should (in theory, at least) benefit the network as a whole.

Code:
Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig to: 
    raise blocksize limit by 12.5%,
    lower blocksize limit by 12.5%,
    or remain at current blocksize limit. 

This vote, however, only counts for half of the total vote and the other half is determined by algorithm based on network traffic:

If more than 50% of block's size, found in the first 1008 of the last difficulty period, is more than 90% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize +12.5%

Else if more than 90% of block's size, found in the first 1008 of the last difficulty period, is less than 50% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize -12.5%

Else
    Network votes for keeping the same MaxBlockSize

The 12.5% part is open to negotiation, some think 10% is more reasonable (i.e. BIP105).  If every 1008 blocks is too fast, we could (for example) increase that to 2016 blocks, approximately every two weeks.  Tweaks are inevitable, but I feel it's something that could work if it's not too complex to code.
tommorisonwebdesign
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
September 29, 2015, 07:00:28 PM
 #85

Yes.  Although I don't know if BIP100 and Meni's idea can occur at the same time, as people may say its too complicated.  We could do one and then the other.

I was looking at some sort of hybrid between BIP100 and BIP106, so that the increase or decrease would take both the miner vote and the network traffic into account.  The change would only go ahead if the two were in alignment.  Also, the doubling/halving part might prove excessive, so felt that needed curtailing:

The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain.  Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often, if needed.  One possible route is to take the best elements of BIP100 and BIP106.  BIP100 only considers what benefits the miners and not the users.  BIP106 only considers what benefits the users and not the miners.  So neither is particularly balanced on its own.  If we can find a way of allowing half of the "vote" to go to the miners and half to an automated, algorithmic vote based on traffic volumes, then we maintain some kind of equilibrium that should (in theory, at least) benefit the network as a whole.

Code:
Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig to: 
    raise blocksize limit by 12.5%,
    lower blocksize limit by 12.5%,
    or remain at current blocksize limit. 

This vote, however, only counts for half of the total vote and the other half is determined by algorithm based on network traffic:

If more than 50% of block's size, found in the first 1008 of the last difficulty period, is more than 90% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize +12.5%

Else if more than 90% of block's size, found in the first 1008 of the last difficulty period, is less than 50% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize -12.5%

Else
    Network votes for keeping the same MaxBlockSize

The 12.5% part is open to negotiation, some think 10% is more reasonable (i.e. BIP105).  If every 1008 blocks is too fast, we could (for example) increase that to 2016 blocks, approximately every two weeks.  Tweaks are inevitable, but I feel it's something that could work if it's not too complex to code.
This seems like the best solution to me. I don't think it's fair that miners have as much influence over the price as proposed by BIP100. At least with this proposal the interests of bitcoin users are taken into account.

Signatures? How about learning a skill... I don't care either way. Everybody has to make a living somehow.
teukon
Legendary
*
Offline Offline

Activity: 1246
Merit: 1004



View Profile
September 30, 2015, 12:17:13 AM
 #86

The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain.  Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often, if needed.

Fortunately, both BIP100 and BIP101 are very smooth already; not even close to suddenly doubling or halving.

I reject the whole "if needed" approach.  If demand were high and supply were low then we'd effectively have to choose between small blocks (hundreds of competing payment processors) and large blocks (one payment processor, the majority miner).  Even with 1MB blocks it's possible to cheaply process many more transactions than would be required for the hundreds of competing payment processors scenario.

This seems like the best solution to me. I don't think it's fair that miners have as much influence over the price as proposed by BIP100. At least with this proposal the interests of bitcoin users are taken into account.

I don't see how "fairness" enters into the debate.  I'm much more interested in finding something which works and is robust.
Provably Fair Directory
Newbie
*
Offline Offline

Activity: 52
Merit: 0


View Profile WWW
September 30, 2015, 02:45:26 PM
 #87

the uncertainty with BIP100 too large.
chennan
Legendary
*
Offline Offline

Activity: 1316
Merit: 1004


View Profile
October 02, 2015, 03:46:21 AM
 #88

BIP 100 always has reminded me of what a Union represents in the US. Workers (in this case miners) will have a say so in the minimal wage for their job that they need to perform to get paid. If the "boss" doesn't comply (in this case, everyone who transacts in bitcoins), then the workers will go on strike. 

This could be very devastating for bitcoin in general. No workers means no security in transactions... Unions in the beginning meant to give people optimal working conditions and not promote a slave type of labor; since in this case we're talking about miners who use computers to do their work, this isn't necessarily valid.  I understand that miners are coming to the brink of whether they make a profit or not, but obviously something needs to be done to create a less costly way to mine coins.  If that were to happen then everything will be perfectly fine.

jonny1000 (OP)
Member
**
Offline Offline

Activity: 129
Merit: 13



View Profile
November 09, 2015, 08:18:23 PM
 #89

I have been thinking about BIP100 carefully.  I think the voting process in BIP100  is not consistent with the existing power structure so could be undermined. This is with respect to a vote for a decreases in the blocksize limit, with an 80% majority being required. In some circumstances (but not all) 50% of the miners can impose a lower limit anyway, if they collaborate and orphan all blocks above a certain size. (Please note the opposite is not true, as all full nodes, and not just miners, are required to implement an increase in the limit)  This fact needs to be reflected in the voting mechanism, otherwise the voting can be considered to ignore reality.

For example, if 79% vote for a decrease and 21% vote for an increase, then under BIP100 the limit is unchanged.  This "defeat" for the 79% could serve as a catalyst for collusion to impose the lower limit anyway and undermine the voting process.  I think BIP100 should be constructed in such a way to avoid this disconnect from the actual power in the mining industry.

In conclusion, these voting systems need to be constructed such that 50% of votes or less, should be required for a reduction in the limit and 50% of votes or more, should be required for an increase in the limit. Therefore, to avoid the perception of small block bias, I think a simple 50th percentile rule is best.

BIP100 should be modified to a simple 50th percentile voting system.
BitcoinNewsMagazine
Legendary
*
Offline Offline

Activity: 1806
Merit: 1164



View Profile WWW
November 09, 2015, 08:29:03 PM
 #90

Pools are voting for BIP100:


Decoded
Legendary
*
Offline Offline

Activity: 1232
Merit: 1030


give me your cryptos


View Profile
December 06, 2015, 10:55:25 AM
 #91

By thinking of bitcoin as a currency, everyone will day no to this. Currencies are meant to be stable, and be used like a ruler to measure the price of a good. If the scale of the ruler is changing each day, what's the point of that?

looking for a signature campaign, dm me for that
DooMAD
Legendary
*
Offline Offline

Activity: 3808
Merit: 3160


Leave no FUD unchallenged


View Profile
December 06, 2015, 11:58:03 AM
 #92

By thinking of bitcoin as a currency, everyone will day no to this. Currencies are meant to be stable, and be used like a ruler to measure the price of a good. If the scale of the ruler is changing each day, what's the point of that?

Bitcoin's stability doesn't stem primarily from the blocksize limit, though.  There are a multitude of factors affecting that, like the block reward and supply cap which won't be altered.  A variable blocksize only makes the system unstable if it's too large and we lose nodes or miners as a result.   The tricky part is determining how large is too large. 
Pages: « 1 2 3 4 [5]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!