"A Transaction Fee Market Exists Wihtout a Block Size Limit" - Peter R
https://www.youtube.com/watch?v=iKDC2DpzNbw&t=0h26m21s
Topic: #Blocksize Survey - page 5. (Read 16117 times)
winner is not clear on this one yet. plus number of votes are way too low.
BIP000 is clearly the winner.So why our poll shows that BIP101 by Gavin Andresen. in winning by huge margin? People don't know what they are voting for?
Honestly I wish we could implement voting system for all bitcoin users (in wallets or other bitcoin software), but I have no idea how to block 1 person for voting multiple times.
Maybe because bitcointalk is not representative of Bitcoin
winner is not clear on this one yet. plus number of votes are way too low.
BIP000 is clearly the winner.So why our poll shows that BIP101 by Gavin Andresen. in winning by huge margin? People don't know what they are voting for?
Honestly I wish we could implement voting system for all bitcoin users (in wallets or other bitcoin software), but I have no idea how to block 1 person for voting multiple times.
winner is not clear on this one yet. plus number of votes are way too low.
BIP000 is clearly the winner.
Small blockers should laugh at blocked streams as long as they can. It's their last year.
winner is not clear on this one yet. plus number of votes are way too low.
BIP000 is clearly the winner.
An interesting slide from a Mark Friedenbach presentation at Scaling Bitcoin. Quite interesting indeed, worth watching: https://youtu.be/TgjrS-BPWDQ?t=11093 Jeff Garzik is next, btw.
Here's this block: https://blockchain.info/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe
I wouldn't call it just interesting. Rather remarkable, as it shows exactly what people have been talking about. Most XT/BIP101 supporters aren't willing to admit or just don't understand this. Bitcoin in its essence does not scale efficiently. This is why technologies like the Lightning Network would be helpful. Even though such block is not a regular one, imagine a validation time of 2h 8min. Here's this block: https://blockchain.info/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe
As seen clearly while Garzik was presenting, we're heading towards 1 MB blocks. However, as of today, blocks are not full. He did nicely present potential problems that we might encounter at the 1 MB wall. The whole economic policy is going to drastically change.
I was just talking to some Derp who believes their average Euro-pipe
could easily support two gigabyte blocks from home
How can we deal with such colossal levels of sheer ignorance? Fire? Or just drink until we can't read their stupid words anymore?
So if we further alter juiceayres' amendment:
-snip-
This would alter the blocksize daily if required, but the maximum increase or decrease per week would be 12.5%
Is that something that would appeal to people on both sides of the fence?
I'm having trouble trying to comprehend what you exactly mean. You want the blocksize to re-adjust every day? Wouldn't it better to make a weekly recalculation and a increase of 10-20%? I think that aside from the exact percentage and potential ways of gambling the system, this might be one of the best solutions out there. Obviously we will also have a hard time deciding the exact percentage as many users will pitch into the debate. -snip-
This would alter the blocksize daily if required, but the maximum increase or decrease per week would be 12.5%
Is that something that would appeal to people on both sides of the fence?
(saying this one more time) Regardless of all of this, I do not agree to the proposed doubling and halving in BIP106 and will never do so. Going from e.g. 40MB to 80MB is drastic.
The only thinking behind the daily part was so that the system could deal with any short bursts of activity and then return to a smaller size when it ends. The main emphasis is still on the weekly adjustment. For example, if we're at 1MB now, this week the blocksize limit could fluctuate between 0.875MB and 1.125MB, but if we spend most of the week nudging the upper limit, next week it could be raised and we could hover between 1 and 1.27MB and so on. Or if (which seems more likely at the moment) we aren't filling the blocks and are mostly at the lower bound, next week the blocksize limit could vary between 0.766MB and 1MB. Keep the network fluid and adaptable, but still keep blocksizes small enough for full nodes and miners to cope. But if that's too complex, then we can just do it weekly. Mostly just seeing if anyone thought the idea had merit.
legendary
Activity: 1666
Merit: 1007
Professional Native Greek Translator (2000+ done)
winner is not clear on this one yet. plus number of votes are way too low.
An interesting slide from a Mark Friedenbach presentation at Scaling Bitcoin. Quite interesting indeed, worth watching: https://youtu.be/TgjrS-BPWDQ?t=11093 Jeff Garzik is next, btw.
Here's this block: https://blockchain.info/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe
I wouldn't call it just interesting. Rather remarkable, as it shows exactly what people have been talking about. Most XT/BIP101 supporters aren't willing to admit or just don't understand this. Bitcoin in its essence does not scale efficiently. This is why technologies like the Lightning Network would be helpful. Even though such block is not a regular one, imagine a validation time of 2h 8min. Here's this block: https://blockchain.info/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe
As seen clearly while Garzik was presenting, we're heading towards 1 MB blocks. However, as of today, blocks are not full. He did nicely present potential problems that we might encounter at the 1 MB wall. The whole economic policy is going to drastically change.
"and we all go work on Etherium."
Another design for 2nd layer for small-b bitcoin (+ why large-B Bitcoin won't scale):
http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
haha take dat forkers/scalers. ^^
http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
haha take dat forkers/scalers. ^^
An interesting slide from a Mark Friedenbach presentation at Scaling Bitcoin. Quite interesting indeed, worth watching: https://youtu.be/TgjrS-BPWDQ?t=11093 Jeff Garzik is next, btw.
Here's this block: https://blockchain.info/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe
Here's this block: https://blockchain.info/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe
So if we further alter juiceayres' amendment:
-snip-
This would alter the blocksize daily if required, but the maximum increase or decrease per week would be 12.5%
Is that something that would appeal to people on both sides of the fence?
I'm having trouble trying to comprehend what you exactly mean. You want the blocksize to re-adjust every day? Wouldn't it better to make a weekly recalculation and a increase of 10-20%? I think that aside from the exact percentage and potential ways of gambling the system, this might be one of the best solutions out there. Obviously we will also have a hard time deciding the exact percentage as many users will pitch into the debate. -snip-
This would alter the blocksize daily if required, but the maximum increase or decrease per week would be 12.5%
Is that something that would appeal to people on both sides of the fence?
(saying this one more time) Regardless of all of this, I do not agree to the proposed doubling and halving in BIP106 and will never do so. Going from e.g. 40MB to 80MB is drastic.
But trolls can't be downvoted here on BCT. All reasonable discussion drowns due to few trolls conquering the threads and driving others away. (people get tired of constant nonsense and ad-hominem attacks)
So if I say that the fork is not gaining speed (which it is not), am I supposedly a troll? People tend to spread wrong information around here, especially related to the debate. I've already said that the Core vs XT war needs to stop. There was enough ad-hominem and whatnot. BIP106:
BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap
https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac
BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap
https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac
Quote
+===Proposal 1 : Depending only on previous block size calculation===
+
+ If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize
+ Double MaxBlockSize
+ Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize
+ Half MaxBlockSize
+ Else
+ Keep the same MaxBlockSize
+
+ If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize
+ Double MaxBlockSize
+ Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize
+ Half MaxBlockSize
+ Else
+ Keep the same MaxBlockSize
This appears to be the most dynamic and acceptable solution so far. I wish, you add it in the poll as well as in the OP with a short description.
Might be a bit late for that, as I don't think you can change your vote now if you've already cast it. Maybe a new poll with all the options is needed.
I think BIP106 is definitely heading in the right direction, but will likely need some tweaking and balancing before it's ready to be implemented.
BIP106:
BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap
https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac
BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap
https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac
Quote
+===Proposal 1 : Depending only on previous block size calculation===
+
+ If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize
+ Double MaxBlockSize
+ Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize
+ Half MaxBlockSize
+ Else
+ Keep the same MaxBlockSize
+
+ If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize
+ Double MaxBlockSize
+ Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize
+ Half MaxBlockSize
+ Else
+ Keep the same MaxBlockSize
This appears to be the most dynamic and acceptable solution so far. I wish, you add it in the poll as well as in the OP with a short description.
Also a lot of interesting stuff here:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/
hehe ^^
The Decentralist Perspective, or Why Bitcoin Might Need Small Blocks
https://bitcoinmagazine.com/21919/decentralist-perspective-bitcoin-might-need-small-blocks/
https://bitcoinmagazine.com/21919/decentralist-perspective-bitcoin-might-need-small-blocks/
Quote
Well-known cryptographer and digital currency veteran Nick Szabo explained:
“In computer science there are fundamental trade-offs between security and performance. Bitcoin’s automated integrity necessarily comes at high costs in its performance and resource usage. Compared to existing financial IT, Satoshi made radical trade-offs in favor of security and against performance. The seemingly wasteful process of mining is the most obvious of these trade-offs, but it also makes others. Among them is that it requires high redundancy in its messaging. Mathematically provable integrity would require full broadcast between all nodes. Bitcoin can’t achieve that, but to even get anywhere close to a good approximation of it requires a very high level of redundancy. So a 1MB block takes vastly more resources than a 1MB web page, for example, because it has to be transmitted, processed and stored with such high redundancy for Bitcoin to achieve its automated integrity.”
“In computer science there are fundamental trade-offs between security and performance. Bitcoin’s automated integrity necessarily comes at high costs in its performance and resource usage. Compared to existing financial IT, Satoshi made radical trade-offs in favor of security and against performance. The seemingly wasteful process of mining is the most obvious of these trade-offs, but it also makes others. Among them is that it requires high redundancy in its messaging. Mathematically provable integrity would require full broadcast between all nodes. Bitcoin can’t achieve that, but to even get anywhere close to a good approximation of it requires a very high level of redundancy. So a 1MB block takes vastly more resources than a 1MB web page, for example, because it has to be transmitted, processed and stored with such high redundancy for Bitcoin to achieve its automated integrity.”
So flix? Any thoughts on the litterature i provided you?
Yes... I did not want to say anything, but since you insist: I was not impressed at all. Most were off-topic or only marginally referred to the blocksize issue.
I did not find a coherent presentation of the no-increase argument.
At least the one on the economics of tx fees was interesting...
oky
So flix? Any thoughts on the litterature i provided you?
Yes... I did not want to say anything, but since you insist: I was not impressed at all. Most were off-topic or only marginally referred to the blocksize issue.
I did not find a coherent presentation of the no-increase argument.
At least the one on the economics of tx fees was interesting...
your so-called 'Blockstream coin' is a near perfect proxy for Bitcoin represented in the main chain due to the 2-way peg. The main 'downside' is that it becomes much more difficult to correlate transactions to individual users and this drives those who wish to do so crazy.
It's becoming clear TPTB (ie sigint.google.mil and tla.mit.gov) have set a strategic goal of forcing most or all full nodes to be relocated in their data centers.
Can you imagine the Google/A16/GS/JPM board meetings where they concede Bitcoin's blockchain is going to be worth trillions?
Do you think they're happy with every Joe Sixcoins being able to run his own bank/stock market/credit union/payment rail?
'Oh Hell NO,' they said. And then deployed Hearn on his mission to expand node footprints until unsupportable almost anywhere outside of vulnerable, carefully-controlled colocation facilities.
These SHR MIC VC ratfuckers won't stop until they scour every last trace of cypherpunk influence from Bitcoin, and they are able to profit from correlating transactions to individual users.
I think it needs to be mentioned the war also seems to be on China. It is a perfectly rational fact to expect that most of the big time bankers backing these VC companies are not comfortable with +50% of the network being run from there. Mike Hearn has been extremely clear in his position that mining should be available only to those with the best bandwidth connection.
Excellent point about China. The military part of the complex wants to keep strategic rivals from dominating Bitcoin, while the industrial (crony capitalist) side wants to capture the value provided by progress towards crypto-minarchism.
Team XT kills both birds with one stone, so I take Blockstream's VC funding as them 'keeping their enemies closer.'
Yes. Choice is tyranny. War is peace. Freedom is slavery. Ignorance is strength.
Jump to: