Bitcoin Forum
November 22, 2017, 01:15:08 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 [1337] 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2011303 times)
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
June 17, 2015, 07:38:34 PM
 #26721

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

I originally thought of Garzik's voting proposal that it was brilliant. But now I think adding this would be unnecessarily complex.

If there is a need to hold back blocsize, it should be a hard increase based on previous blocks in the style of difficulty change. We can then continue the situation where the only link to the real world is the timestamps.

The miners could agree on a soft limit (dont make larger blocks, but build on larger blocks from others). The soft limit could be communicated in a side channel outside bitcoin. Call it a miner cartel, but before you dismiss it, know that a cartel is a very weak economic construct, with possible attacks from inside and outside. Don't forget that each miner is free to choose which block to base his mining on, he chooses that based on self interest.

So dynamically incremented hard limit for security, market based soft limit.


giving miners a vote in terms of block size is paying them too much deference in terms of the market dynamics in Bitcoin. i've always said that no contingent is more powerful than another in Bitcoin.  everyone is important and needed and has power to a degree or so; users, merchants, miners, node operators.  which is why i always give that bucket analogy when i think in terms of which of those subspaces i would want to invest in.  some will always be more developed (filled) or over invested in than the others while the whole space can still be in a bull mkt w/o anyone of them being "in charge".  

I agree with this, what I was trying to get at is the outcome of this proposal (miner voting +IBLT) essentially forces or at least encourages maximum blocksize over time. This is in the interest of users and why I like the proposal.
1511356508
Hero Member
*
Offline Offline

Posts: 1511356508

View Profile Personal Message (Offline)

Ignore
1511356508
Reply with quote  #2

1511356508
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511356508
Hero Member
*
Offline Offline

Posts: 1511356508

View Profile Personal Message (Offline)

Ignore
1511356508
Reply with quote  #2

1511356508
Report to moderator
1511356508
Hero Member
*
Offline Offline

Posts: 1511356508

View Profile Personal Message (Offline)

Ignore
1511356508
Reply with quote  #2

1511356508
Report to moderator
techgeek
Hero Member
*****
Offline Offline

Activity: 826


View Profile
June 17, 2015, 07:48:30 PM
 #26722

so is the 20 mb going to happen before the unavoidable clogged confirmation times, or are we already in the process of something now?

I rather see this now then later in my view.

Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
June 17, 2015, 07:51:42 PM
 #26723

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

I originally thought of Garzik's voting proposal that it was brilliant. But now I think adding this would be unnecessarily complex.

If there is a need to hold back blocsize, it should be a hard increase based on previous blocks in the style of difficulty change. We can then continue the situation where the only link to the real world is the timestamps.

The miners could agree on a soft limit (dont make larger blocks, but build on larger blocks from others). The soft limit could be communicated in a side channel outside bitcoin. Call it a miner cartel, but before you dismiss it, know that a cartel is a very weak economic construct, with possible attacks from inside and outside. Don't forget that each miner is free to choose which block to base his mining on, he chooses that based on self interest.

So dynamically incremented hard limit for security, market based soft limit.


I think its worth expanding the obvious power the miners have, its not just: "dont make larger blocks, but build on larger blocks from others" as written but "dont make larger blocks, but build on larger blocks from others only if they are part of the longest chain as supported by the majority of nodes."

Yes, but it is at the same time in their interest. If they for some reason agree to have a limit, they could also agree to build on only blocks within the soft limit. I see no economical reason that this should lead to a fork, no more than in the current situation where two chains of near equal length (as defined in the protocol) appears.

EDIT: By the way, this IS the current reality, whatever the reference implementation says. You can complain that your orphan from last year should have been built on because it was slightly better. What is longest now matters, and there is randomness involved in the selection.

I cant see it leading to a fork ever, in effect I like the idea of carrells limiting block-size through a cooperative effort, provided they have no say on what nodes will accept, inevitably some one will break from it and mine bigger blocks for transaction fees, if it gives them a sense of control sure let them have it. considering most miners mine to the 750KB default I don't think anyone needs to optimize this much until the TX mem pool is a little bigger and block subsidy smaller.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
June 17, 2015, 07:56:39 PM
 #26724

so is the 20 mb going to happen before the unavoidable clogged confirmation times, or are we already in the process of something now?

I rather see this now then later in my view.

No, clogging can happen anytime, Gavan's proposal was for March next year.

not sure how Gmax and co would just quickly fix this if the clogging happened tomorrow. maybe the Chinese could increase the dealt from 750KB to 1MB and we could limp along until next year.

it just seems irresponsible to me to not put this change in now while the idea is debated.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 07:59:10 PM
 #26725

so is the 20 mb going to happen before the unavoidable clogged confirmation times, or are we already in the process of something now?

I rather see this now then later in my view.

No, clogging can happen anytime, Gavan's proposal was for March next year.

not sure how Gmax and co would just quickly fix this if the clogging happened tomorrow. maybe the Chinese could increase the dealt from 750KB to 1MB and we could limp along until next year.

it just seems irresponsible to me to not put this change in now while the idea is debated.

revised to January as earliest implementation.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 08:08:02 PM
 #26726

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

I originally thought of Garzik's voting proposal that it was brilliant. But now I think adding this would be unnecessarily complex.

If there is a need to hold back blocsize, it should be a hard increase based on previous blocks in the style of difficulty change. We can then continue the situation where the only link to the real world is the timestamps.

The miners could agree on a soft limit (dont make larger blocks, but build on larger blocks from others). The soft limit could be communicated in a side channel outside bitcoin. Call it a miner cartel, but before you dismiss it, know that a cartel is a very weak economic construct, with possible attacks from inside and outside. Don't forget that each miner is free to choose which block to base his mining on, he chooses that based on self interest.

So dynamically incremented hard limit for security, market based soft limit.


giving miners a vote in terms of block size is paying them too much deference in terms of the market dynamics in Bitcoin. i've always said that no contingent is more powerful than another in Bitcoin.  everyone is important and needed and has power to a degree or so; users, merchants, miners, node operators.  which is why i always give that bucket analogy when i think in terms of which of those subspaces i would want to invest in.  some will always be more developed (filled) or over invested in than the others while the whole space can still be in a bull mkt w/o anyone of them being "in charge".  

I agree with this, what I was trying to get at is the outcome of this proposal (miner voting +IBLT) essentially forces or at least encourages maximum blocksize over time. This is in the interest of users and why I like the proposal.

i get what you are saying but it assumes 2 things:

1.  voting is good
2.  IBLT is ready

i worry that voting can be gamed.  i don't see any proposed methods for the voting to even take place yet alone how to agree to it.  but "voting" via BIP100 requires the initial vote, by whatever agreed upon means (that in itself will be controversial), and then a second time via versioning of blocks (assuming the increase needs to reach a certain % before it gets turned on).
with Gavin's latest proposal, the "vote", only has to takes place once and via a means we already know works well; block versioning. 

i have hopes for IBLT as well but that seems like that will take a while and certainly not in time for what we need now.
Erdogan
Hero Member
*****
Offline Offline

Activity: 826


View Profile
June 17, 2015, 08:14:25 PM
 #26727

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

I originally thought of Garzik's voting proposal that it was brilliant. But now I think adding this would be unnecessarily complex.

If there is a need to hold back blocsize, it should be a hard increase based on previous blocks in the style of difficulty change. We can then continue the situation where the only link to the real world is the timestamps.

The miners could agree on a soft limit (dont make larger blocks, but build on larger blocks from others). The soft limit could be communicated in a side channel outside bitcoin. Call it a miner cartel, but before you dismiss it, know that a cartel is a very weak economic construct, with possible attacks from inside and outside. Don't forget that each miner is free to choose which block to base his mining on, he chooses that based on self interest.

So dynamically incremented hard limit for security, market based soft limit.


I think its worth expanding the obvious power the miners have, its not just: "dont make larger blocks, but build on larger blocks from others" as written but "dont make larger blocks, but build on larger blocks from others only if they are part of the longest chain as supported by the majority of nodes."

Yes, but it is at the same time in their interest. If they for some reason agree to have a limit, they could also agree to build on only blocks within the soft limit. I see no economical reason that this should lead to a fork, no more than in the current situation where two chains of near equal length (as defined in the protocol) appears.

EDIT: By the way, this IS the current reality, whatever the reference implementation says. You can complain that your orphan from last year should have been built on because it was slightly better. What is longest now matters, and there is randomness involved in the selection.

I cant see it leading to a fork ever, in effect I like the idea of carrells limiting block-size through a cooperative effort, provided they have no say on what nodes will accept, inevitably some one will break from it and mine bigger blocks for transaction fees, if it gives them a sense of control sure let them have it. considering most miners mine to the 750KB default I don't think anyone needs to optimize this much until the TX mem pool is a little bigger and block subsidy smaller.

You got it. In general, we should not be afraid of cartels, it is just a way to increase productivity. It is currently not much liked by the regulators, but it is in fact the regulators messing with the cartels that is the market distortion. And there is no regulator for mining.

tvbcof
Legendary
*
Offline Offline

Activity: 2324


View Profile
June 17, 2015, 08:17:49 PM
 #26728

...
Btw, in my coin's design the miners can not be paid with transaction fees that originate from prior balances because this is a source of censorship of transactions (even if the inputs are blinded by a mix because one blacklisted input in the mix could cause censorship of the entire mix). My design is 100% censorship free (no heuristic arguments, rather 100% provable).

Shit I am giving away too much of my design. I better STFU.

You will end up buying my coin if I create it, because it will blow your fucking mind or I mean to say the design will make your jaw drop to the floor and you will say, "I must buy this".

If your design is half as good as what I've been working on, I just might do that Smiley

Seriously, if I might be so bold as to suggest that you throw your ideas out there, some of them might be picked up and even enhanced in ways you don't initially imagine.  That has happened to me over the years.  If you don't get credit or money for them, so what?  Speaking only for myself these things are quite secondary.  If you are consumed with fame and fortune and what-not it cannot help but detract from your ability to focus on other things.  I suppose it could be argued that fame and fortune might spur one to work harder, but I'll bet that in most cases working harder is actually counter-productive to doing quality work in certain important ways.


rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
June 17, 2015, 08:18:25 PM
 #26729

giving miners a vote in terms of block size is paying them too much deference in terms of the market dynamics in Bitcoin. i've always said that no contingent is more powerful than another in Bitcoin.  everyone is important and needed and has power to a degree or so; users, merchants, miners, node operators.  which is why i always give that bucket analogy when i think in terms of which of those subspaces i would want to invest in.  some will always be more developed (filled) or over invested in than the others while the whole space can still be in a bull mkt w/o anyone of them being "in charge".  

I agree with this, what I was trying to get at is the outcome of this proposal (miner voting +IBLT) essentially forces or at least encourages maximum blocksize over time. This is in the interest of users and why I like the proposal.

i get what you are saying but it assumes 2 things:

1.  voting is good
2.  IBLT is ready

i worry that voting can be gamed.  you could argue that versioning is a form of voting i guess but it is different in that it is a commitment that only has to be done once by a miner to indicate the preference to double the block size acc to Gavin's proposal.  all that then needs to be done is to flip the switch after 75% of the mining network is demonstrating the upversioned blocks.

i have hopes for IBLT as well but that seems like that will take a while and certainly not in time for what we need now.

Voting can best be gamed when the process is hidden behind closed side channels between pools, developers or anything else. The advantage of putting voting into the blockchain is it makes the process transparent and visible to individual miners, which makes it much less exposed to gaming as individual miners can see this and respond.

The POW process is Bitcoin's voting process. Yes users, merchants, etc. should have influence, and they do, they can choose to run which ever client they want that follows whatever rules they want. But that is the external world interacting with Bitcoin and deciding how they want to interact with Bitcoin.

Bitcoin as a self-contained system has only one voting mechanism, POW blocks. If anyone wants to vote within Bitcoin's self contained world, stand-up a miner and point it to the pool that best follows your preferences. In many ways this is better than representative democracy, you are much more likely to find a pool you agree with than a US D or R candidate you agree with.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 17, 2015, 08:19:04 PM
 #26730

In general, we should not be afraid of cartels
That's only true in the sense that cartels are naturally unstable unless and until they get support from governments in the form of externalizing the cost of enforcement.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 08:27:39 PM
 #26731

giving miners a vote in terms of block size is paying them too much deference in terms of the market dynamics in Bitcoin. i've always said that no contingent is more powerful than another in Bitcoin.  everyone is important and needed and has power to a degree or so; users, merchants, miners, node operators.  which is why i always give that bucket analogy when i think in terms of which of those subspaces i would want to invest in.  some will always be more developed (filled) or over invested in than the others while the whole space can still be in a bull mkt w/o anyone of them being "in charge".  

I agree with this, what I was trying to get at is the outcome of this proposal (miner voting +IBLT) essentially forces or at least encourages maximum blocksize over time. This is in the interest of users and why I like the proposal.

i get what you are saying but it assumes 2 things:

1.  voting is good
2.  IBLT is ready

i worry that voting can be gamed.  you could argue that versioning is a form of voting i guess but it is different in that it is a commitment that only has to be done once by a miner to indicate the preference to double the block size acc to Gavin's proposal.  all that then needs to be done is to flip the switch after 75% of the mining network is demonstrating the upversioned blocks.

i have hopes for IBLT as well but that seems like that will take a while and certainly not in time for what we need now.

Voting can best be gamed when the process is hidden behind closed side channels between pools, developers or anything else. The advantage of putting voting into the blockchain is it makes the process transparent and visible to individual miners, which makes it much less exposed to gaming as individual miners can see this and respond.

The POW process is Bitcoin's voting process. Yes users, merchants, etc. should have influence, and they do, they can choose to run which ever client they want that follows whatever rules they want. But that is the external world interacting with Bitcoin and deciding how they want to interact with Bitcoin.

Bitcoin as a self-contained system has only one voting mechanism, POW blocks. If anyone wants to vote within Bitcoin's self contained world, stand-up a miner and point it to the pool that best follows your preferences. In many ways this is better than representative democracy, you are much more likely to find a pool you agree with than a US D or R candidate you agree with.

so then how do you deal with the IBLT issue given that we need a solution now?
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
June 17, 2015, 08:28:20 PM
 #26732

In general, we should not be afraid of cartels
That's only true in the sense that cartels are naturally unstable unless and until they get support from governments in the form of externalizing the cost of enforcement.

I'm not sure cartels is really the right analogy here.

A cartel in the traditional sense is a small number of large entities banding together to force everyone to follow their decisions.

But in Bitcoin, any miner not in the cartel could choose to issue larger blocks and capture the fees. That is how Bitcoin's open nature works. The only way a cartel could succeed here is if 51% of the hash rate pooled together and agreed to build a longest chain ignoring large blocks. But I would call this at 51% attack, not a cartel.
Erdogan
Hero Member
*****
Offline Offline

Activity: 826


View Profile
June 17, 2015, 08:30:24 PM
 #26733

In general, we should not be afraid of cartels
That's only true in the sense that cartels are naturally unstable unless and until they get support from governments in the form of externalizing the cost of enforcement.

EDIT: I was a bit quick to respond. Yes, If the cartel can collude with the government, they are set for a real monopoly. It is not only the cost, but that they can keep internal and external attackers in check by the force of law, (less kindly expressed as violence in contempt of human  rights).


Cartels are unstable. There is a ton of literature on the subject.

Just think about the internal pressure. A subset of the members can collude to fool the othes. A subset can collude with someone external. If the cartel does something stupid, outside forces will be quick to attack. For instance, if the cartel reduces production to hike prices, they will be bled from externals that have the higher market price, but not the volume constraints. If a cartel divide markets, the attacker will have only one competitor. The list goes on.

For bitcoin mining, there sure is a cartel if there is an economic point to it (large equipment orders for instance). But a shadow cartel with a subgroup from the first cartel and some others could easily appear.

Zarathustra
Legendary
*
Offline Offline

Activity: 1036



View Profile
June 17, 2015, 08:34:58 PM
 #26734

Chomsky's confrontation with a truther idiot:

https://www.youtube.com/watch?v=3i9ra-i6Knc

I watched it.

His arguments are:

1) If you don't do science through the establishment, then you are not doing science.

2) Only people trained in universities can be trusted to do peer review.

3) Bush was running the government (and not the DEEP STATE) and Bush's only objective was not "you are either for us or you are against us". He entirely sidesteps the point of 9/11 was to foist  "you are either for us or you are against us" on the entire world. And he substitutes a strawman, Hegelian dialectic for logic. He sidesteps the concept that the DEEP STATE plays many different elements against each other in order to retain control.

In short he is either knowingly acting as a gatekeeper, senile, or just not that smart. I would bet on the first conclusion.

I'll agree with your bet.  Classic controlled opposition.  

No, I think both of you conspiracy theorists are smarter than Chomsky. Chomsky is a slave of the establishment and both of you conspiracy theorists are free hero members of the society.
If you brake your leg or your neck, you should consult a quack instead of a university trained doctor of the establishment.
Erdogan
Hero Member
*****
Offline Offline

Activity: 826


View Profile
June 17, 2015, 08:41:44 PM
 #26735

In general, we should not be afraid of cartels
That's only true in the sense that cartels are naturally unstable unless and until they get support from governments in the form of externalizing the cost of enforcement.

I'm not sure cartels is really the right analogy here.

A cartel in the traditional sense is a small number of large entities banding together to force everyone to follow their decisions.

But in Bitcoin, any miner not in the cartel could choose to issue larger blocks and capture the fees. That is how Bitcoin's open nature works. The only way a cartel could succeed here is if 51% of the hash rate pooled together and agreed to build a longest chain ignoring large blocks. But I would call this at 51% attack, not a cartel.

To me it is the same, and, correct me if I am wrong, this is according to protocol. I guess the nodes also have a saying, but who could oppose such a decision?

Natalia_AnatolioPAMM
Full Member
***
Offline Offline

Activity: 154


View Profile
June 17, 2015, 09:13:23 PM
 #26736

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

I originally thought of Garzik's voting proposal that it was brilliant. But now I think adding this would be unnecessarily complex.

If there is a need to hold back blocsize, it should be a hard increase based on previous blocks in the style of difficulty change. We can then continue the situation where the only link to the real world is the timestamps.

The miners could agree on a soft limit (dont make larger blocks, but build on larger blocks from others). The soft limit could be communicated in a side channel outside bitcoin. Call it a miner cartel, but before you dismiss it, know that a cartel is a very weak economic construct, with possible attacks from inside and outside. Don't forget that each miner is free to choose which block to base his mining on, he chooses that based on self interest.

So dynamically incremented hard limit for security, market based soft limit.


giving miners a vote in terms of block size is paying them too much deference in terms of the market dynamics in Bitcoin. i've always said that no contingent is more powerful than another in Bitcoin.  everyone is important and needed and has power to a degree or so; users, merchants, miners, node operators.  which is why i always give that bucket analogy when i think in terms of which of those subspaces i would want to invest in.  some will always be more developed (filled) or over invested in than the others while the whole space can still be in a bull mkt w/o anyone of them being "in charge".  

I agree with this, what I was trying to get at is the outcome of this proposal (miner voting +IBLT) essentially forces or at least encourages maximum blocksize over time. This is in the interest of users and why I like the proposal.

 I enjoyed your dialog so much
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
June 17, 2015, 09:18:19 PM
 #26737

this should work. nice and simple and pleases Chinese miners w/o giving miners in general any votes:

https://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xe9o



If 75% of hashing power is producing up-version blocks

AND after some brave miner decides to actually produce a >1MB block.

8MB max block size (chinese miners were unhappy with 20 for not-entirely-clear reasons)
Earliest fork date 11 Jan 2016 (miners and others want sooner rather than later)
Activation when 750 of last 1,000 blocks are up-version (version 0x20000004 to be compatible with sipa's new versioning bits scheme)
2 week 'grace period' after 75% threshold reached before first >1MB block allowed to be mined
8MB cap doubles every two years (so 16MB in 2018, etc: unless there is a soft fork before then because 16MB is too much)

Not sure why limiting the date is necessary. I feel like we should be able to pull this off sooner, especially if we are backed into a corner by some kind of big rally.

i agree but miners need time to switch over and indicate so with the versioning.

Sure. But doesn't the 2 week grace period after 75% imply enough time?

https://www.youtube.com/watch?v=nuHfVn_cfHU

Gavin's solution is very good, and the 2-week grace period a smart move. The reason for this is that it gets the most people on-board with the >1MB change in a controlled manner. It is axiomatic that 100% of miners cannot be in the first 75% to upgrade even if they all wanted to. The 2-week period focuses minds on a known deadline and will likely see a "hockey-stick" uptick in the adoption curve. I would expect 85-90% mining power behind the change before the first >1MB block is mined. If 90% was the original target then Bitcoin's ecosystem growth, supported by the majority, could be stymied by a mere 11% of hold-out miners. The grace period also allows for non-mining nodes to upgrade who are not paying close attention to the whole process.

I like Jeff's BIP 100 with the miner voting, but not sure about the 90% he mentions because of the concern above.
Also, I really don't like a fixed date for everyone to upgrade (although this is far better than no change planned at all). Not using block versioning to change the 1MB means applying a sub-standard software solution for politically correct reasons, i.e. just so people can say "Aha, the users control Bitcoin and are telling the miners what to do." We already know the user consensus on a dozen btc and reddit polls, ecosystem business feedback, and now at least 50% of mining power opinion. So the change should be done as safely as possible. Gavin is perusing this path.

Probably the biggest reason that Core Dev is prepared to let the 1MB limit be constantly hit is that they think they can manage the situation. Perhaps they need to look up the word "hubris" in the dictionary.

A big bazooka in Core Dev's (fairly small) armory needed to "manage" a blocks-limit-full situation is prior roll-out of a change to purge unconfirmed tx from node mempools. This would in theory blunt some of the nasty effects in Mike's Crash Landing scenario.

So, no surprise that a pull request exists to do this:
https://github.com/bitcoin/bitcoin/pull/6281

Quote
Restrict the maximum memory pool size to avoid potential DoS issues.
The mechanism is simply to recursively remove the transactions which have the lowest priority until the memory pool is below the maximum size.

(my emphasis)
Hmm, DoS issues like ordinary users legitimately trying to use Bitcoin after tx are backing up when free block-space has vanished?

However, what appears to be a bed of roses rapidly turns into a bed of thorns...

Quote
@sipa ah so if a wallet transaction is evicted from the mempool the conflict tracking stuff will all break? that's nasty
the rabbit's hole of things to fix gets ever deeper

Their bazooka has a barrel bent into a U-shape.

Another big concern about mempool limiting is the implications for IBLT, which is Bitcoin's best hope for challenging the likes of Visa and MC in the medium, not long-term.
Randomly ejecting unconfirmed tx, or allowing a user-configurable max-mempool-size, creates non-uniform mempools. This seriously degrades the potential for IBLT, especially when miners want to clear most of the unconfirmed tx, to maximize revenue when the block reward is lower.

Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
June 17, 2015, 09:28:29 PM
 #26738

In general, we should not be afraid of cartels
That's only true in the sense that cartels are naturally unstable unless and until they get support from governments in the form of externalizing the cost of enforcement.

I'm not sure cartels is really the right analogy here.

A cartel in the traditional sense is a small number of large entities banding together to force everyone to follow their decisions.

But in Bitcoin, any miner not in the cartel could choose to issue larger blocks and capture the fees. That is how Bitcoin's open nature works. The only way a cartel could succeed here is if 51% of the hash rate pooled together and agreed to build a longest chain ignoring large blocks. But I would call this at 51% attack, not a cartel.

there is no reason to be part of the 51% cartel in this eg. one of the miners will stop cooperating because it leaves money on the table and whoever breaks rank can profit by pretending to support it and earn more fees by processing bigger blocks giving the 51% advantage to the network.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
June 17, 2015, 09:29:05 PM
 #26739

Probably the biggest reason that Core Dev is prepared to let the 1MB limit be constantly hit is that they think they can manage the situation. Perhaps they need to look up the word "hubris" in the dictionary.

I think they want to make sure a hard fork is already needed around the same time they are ready to launch Blockstream's LN and SC changes. This would make it easier to push the changes through. i.e. "OK, transactions recently hit the 8MB limit and we need to increase the limit today, here are some additional updates to include in the fork".

If there is no pressing need for another hard fork (because the blocksize issue was already dealt with), then the entire discussion is focused on if people want to make a drastic change, and there is no rush to do so. Combining the two might accelerate the process.

For a VC backed firm, that has limited time to demonstrate adoption or revenue, running into a wall where it takes 2 years just to convince the Bitcoin ecosystem to change for you, can be a killer.
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
June 17, 2015, 09:32:19 PM
 #26740

In general, we should not be afraid of cartels
That's only true in the sense that cartels are naturally unstable unless and until they get support from governments in the form of externalizing the cost of enforcement.

I'm not sure cartels is really the right analogy here.

A cartel in the traditional sense is a small number of large entities banding together to force everyone to follow their decisions.

But in Bitcoin, any miner not in the cartel could choose to issue larger blocks and capture the fees. That is how Bitcoin's open nature works. The only way a cartel could succeed here is if 51% of the hash rate pooled together and agreed to build a longest chain ignoring large blocks. But I would call this at 51% attack, not a cartel.

there is no reason to be part of the 51% cartel in this eg. one of the miners will stop cooperating because it leaves money on the table and whoever breaks rank can profit by pretending to support it and earn more fees by processing bigger blocks giving the 51% advantage to the network.

Exactly, it is why the argument that a cartel might form to limit the blocksize and ignore the protocol limit, is unlikely to succeed.

BTW, does anyone know what the status of IBLT is? This one change (which doesn't require a fork) would do a lot for the network.
Pages: « 1 ... 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 [1337] 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 ... 1558 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!