Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
Could someone hit me with a cluestick please, because I don't get why mining has a factor that scales automatically as-needed (difficulty vs hashrate), yet no one has an idea on how to do something similar for block sizes? Why can't block sizes just auto-scale up (or down) based on demand?
Great to see Melbustus & solex make it into the letter. Cool!Hi guys, I'll be watching this thread and translating your insights into Spanish, as always.
Here's an example: http://elbitcoin.org/analfabetismo-economico-en-la-discusion-por-el-tamano-de-los-bloques/
By the way, many of you are already celebrities in the Spanish speaking world.
Glad to see the thread lives! The near future for both bitcoin & global economies should be quite exciting, this is a good place to discuss it all.
I've never liked the voting aspect of 100 and I still don't.
Whether we as a community or they as miners know for sure whether or not the voting is gameable is for the most part irrelevant. The fact the the miners are rushing to vote for 100 itself should be illuminating. To me this means they "think" it might give them an extra lever of power over the system which means one day they will try to utilize that power. That can't be a good thing. And it's totally unnecessary.
There's also the aspect of predictability. With 101, we know what the path is exactly to 8GB. That provides the kind of certainty the market price would love, assuming no technical glitches. No such thing with 100.
Finally, given the steep divide between different BIPS, it seems to me the obvious choice is the one no one lobbies for, which is no limit.
Whether we as a community or they as miners know for sure whether or not the voting is gameable is for the most part irrelevant. The fact the the miners are rushing to vote for 100 itself should be illuminating. To me this means they "think" it might give them an extra lever of power over the system which means one day they will try to utilize that power. That can't be a good thing. And it's totally unnecessary.
There's also the aspect of predictability. With 101, we know what the path is exactly to 8GB. That provides the kind of certainty the market price would love, assuming no technical glitches. No such thing with 100.
Finally, given the steep divide between different BIPS, it seems to me the obvious choice is the one no one lobbies for, which is no limit.
I believe that such popularity of BIP 100 with miners is recognition by them of the need to keep TX's on mainchain and the importance of fees longterm.
In essence, that means the end of SC's and quite possibly LN, if I'm right.
This one is really sad to me. One of my early heroes in the space was Stefan Thomas, now with Ripple Labs. In this podcast, one hears firsthand how the original freedom loving concept of "gateways" run by anonymous owners has been perverted to that of being run by banks and other financial institutions.
This just shows how powerful and insidious the siren song of fiat money can twist ones thinking. There is an attempt going on right now in Bitcoin to accomplish the same thing. All you have to do is substitute the word gateway with either LN Hub or CitiSC.
In essence, that means the end of SC's and quite possibly LN, if I'm right.
This one is really sad to me. One of my early heroes in the space was Stefan Thomas, now with Ripple Labs. In this podcast, one hears firsthand how the original freedom loving concept of "gateways" run by anonymous owners has been perverted to that of being run by banks and other financial institutions.
This just shows how powerful and insidious the siren song of fiat money can twist ones thinking. There is an attempt going on right now in Bitcoin to accomplish the same thing. All you have to do is substitute the word gateway with either LN Hub or CitiSC.
Melbustus
Active Member
- Aug 28, 2015
- 237
- 884
Agreed. I prefer BIP100 to doing nothing, but 101 seems preferable for exactly those reasons: simplicity and predictability.
Most parameters and algorithms in Bitcoin are set-up with engineering simplicity, and future transparency, in mind. Take the supply curve, for example... A 50% reduction every 210,000 blocks is super simple to code, understand, test/simulate/debug/model/etc. It's certainly possible (see various alt-coins) to develop a smoother algorithm, one which wouldn't threaten economic discontinuities (as some like to say with regard to these course once-every-four-years halvings), but it would necessarily be more complex, and potentially introduce dynamics that are not easy to understand, or which could be intentionally gamed.
The design tradeoff Bitcoin has made since day-0 has been to keep the engineering simple and let the market figure out the economics. In that vein, no blocksize limit at all seems the most fitting to me, as it lets miners set their own profit-maximizing fees without any artificial technical constraints. But if that doesn't happen, BIP101 seems most in line with the type of simplicity and predictability that Bitcoin exhibits in its other parameters.
majamalu
Active Member
- Aug 28, 2015
- 144
- 775
That's true. BIP 100 is a mess, but at least it would take power from developers and put it in the hands of a group that is less homogenous, more subject to competition and more interested in the growth of Bitcoin as it was designed by Satoshi.
Furthermore, BIP 100 may show that having the block size limit defined by developers makes no sense, and will probably open the door to a definitive solution (like BIP101).
Last edited:
BIP101 > BIP100 > 1 MB
The biggest problem I see with BIP100 is the 21% attack. 51% of the hash power can already effectively limit the block size by orphaning any block larger than Q_max. Why would we want to make the network more susceptible to this attack vector? However, assuming the BIP100 proposal is adjusted to use the median vote (or something similar), I find BIP100 tolerable although far from ideal.
To me, BIP101 is based on the ideology that the limit is an anti-spam measured (it's original rationale) and thus should be so far above the average transactional demand that its economic effects are negligible. BIP101 helps us to gradually transition into the unlimited block size scenario.
BIP100, on the other hand, seems to hand additional power to miners to use the block size limit to distort the natural fee market. With BIP100, I suspect we would end up with both higher fees and slower growth than we would with BIP101, all other variables equal. If miners want to coordinate a lower max block size, why don't they do it with a soft limit on top of BIP101?
The biggest problem I see with BIP100 is the 21% attack. 51% of the hash power can already effectively limit the block size by orphaning any block larger than Q_max. Why would we want to make the network more susceptible to this attack vector? However, assuming the BIP100 proposal is adjusted to use the median vote (or something similar), I find BIP100 tolerable although far from ideal.
To me, BIP101 is based on the ideology that the limit is an anti-spam measured (it's original rationale) and thus should be so far above the average transactional demand that its economic effects are negligible. BIP101 helps us to gradually transition into the unlimited block size scenario.
BIP100, on the other hand, seems to hand additional power to miners to use the block size limit to distort the natural fee market. With BIP100, I suspect we would end up with both higher fees and slower growth than we would with BIP101, all other variables equal. If miners want to coordinate a lower max block size, why don't they do it with a soft limit on top of BIP101?
what are your thoughts on this new paper?:
https://www.reddit.com/r/bitcoin_uncensored/comments/3iv8z4/miner_advantages_in_uncapped_block_size_fee/
this is important:
"However, due to the Poisson-distributed character of block mining, if thenetwork’s block validation time is less than the mining variance (which for Poisson events is identical to the expectedblock time value T= 600s) then temporal advantage effects will balance out over long time periods.
http://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
https://www.reddit.com/r/bitcoin_uncensored/comments/3iv8z4/miner_advantages_in_uncapped_block_size_fee/
this is important:
"However, due to the Poisson-distributed character of block mining, if thenetwork’s block validation time is less than the mining variance (which for Poisson events is identical to the expectedblock time value T= 600s) then temporal advantage effects will balance out over long time periods.
http://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
- Aug 22, 2015
- 1,558
- 4,693
Difficulty can be changed reliably because there is a very good approximation of the global hash rate (blocks solved per unit time).
Demand for Bitcoin usage (transactions) is a much fuzzier, subjective assessment. Consider these examples:
- buying a car with BTC
- buying a coffee
- a Counterparty XCP smart-contract settlement
- a micropayment (10 mins of wifi usage)
- a Satoshidice bet-bot payment
- coinsetter.eu trying to make the case for no block limit by spamming the network
There is no good definition of demand, which feeds into the global debate that there is no good definition of ideal block size limit: except to let the market decide within the constraint of computing technology.
Last edited:
The new paper:
- Builds on top of my paper "A Transaction Fee Market Exists Without a Block Size Limit."
- It addresses Dave Hudson's criticism[1] that miner's "don't orphan their own blocks." It does this by making the propagation impedance a function of the ratio of the miner's hash rate, h, to the total network hash rate, H.
- It shows that although miner's with a large portion of the network hash rate have an advantage over small miners, this advantage decreases as the block reward drops or as total fees increases.
I still need to read the paper slowly to follow all of dpinna's math and the other results...
[1] To make the math tractable, my paper above made the simplifying assumption that the chance a miner mined two blocks in a row was small enough to ignore.
I made a comment here: https://www.reddit.com/r/Bitcoin/comments/3iuz3r/on_the_nature_of_miner_advantages_in_uncapped/
congratulations!
his work is a testimony to yours and builds off of it. i think your paper ought to be accepted by the Scaling Conference coming up.
his work is a testimony to yours and builds off of it. i think your paper ought to be accepted by the Scaling Conference coming up.
I don't know what is going on with the conference. I wrote a second follow-up email to the Planning Committee Chair today:
*************
Hello Pindar,
This is a follow-up from my email last Saturday about what proposals had been accepted for presentation at to the Scaling Bitcoin conference in Montreal.
The conference is now less than two weeks away and presenters need to know (a) who they are, and (b) how much time they have, so they can create PowerPoint presentations, book flights, and reserve accommodations.
Furthermore, I would love to see the titles of presentations and the names of presenters for this conference. The only proposals I have seen so far were:
1. The submission of a 16-page paper for a presentation about the "Transaction Fee Market."
2. The submission of an abstract for a presentation about the "Relay Network."
3. The submission of a two-sentence proposal for a presentation about "Non-bitcoin Transactions."
As far as I know, none of these submissions have been accepted yet. Please correct me if I am wrong.
I think I speak for more than just myself when I say that it would be very helpful to get clarity on these now-urgent details.
Best regards,
Peter
************
Source: http://lists.linuxfoundation.org/pipermail/bitcoin-workshops/2015-August/000012.html
*************
Hello Pindar,
This is a follow-up from my email last Saturday about what proposals had been accepted for presentation at to the Scaling Bitcoin conference in Montreal.
The conference is now less than two weeks away and presenters need to know (a) who they are, and (b) how much time they have, so they can create PowerPoint presentations, book flights, and reserve accommodations.
Furthermore, I would love to see the titles of presentations and the names of presenters for this conference. The only proposals I have seen so far were:
1. The submission of a 16-page paper for a presentation about the "Transaction Fee Market."
2. The submission of an abstract for a presentation about the "Relay Network."
3. The submission of a two-sentence proposal for a presentation about "Non-bitcoin Transactions."
As far as I know, none of these submissions have been accepted yet. Please correct me if I am wrong.
I think I speak for more than just myself when I say that it would be very helpful to get clarity on these now-urgent details.
Best regards,
Peter
************
Source: http://lists.linuxfoundation.org/pipermail/bitcoin-workshops/2015-August/000012.html
I think that Peter R work pretty much kill the "fee pressure" argument in favour of keeping 1MB max size.
In fact, at least on btc dev ml, the usage of such reasoning against block max size increase is almost vanished. It was really present previously.
Now the main concern against BIP 101 is centralization. We should find something as effective as Peter's paper also for this matter.
The problem is that there's no clear and rational definition of what centralization risk means, and it seems no one is interested or is able to provide it.
In fact, at least on btc dev ml, the usage of such reasoning against block max size increase is almost vanished. It was really present previously.
Now the main concern against BIP 101 is centralization. We should find something as effective as Peter's paper also for this matter.
The problem is that there's no clear and rational definition of what centralization risk means, and it seems no one is interested or is able to provide it.
