Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 10:07:54 AM |
|
Lol you clearly still cant read with any proficiency. For how many month will it be 'the solution' in 2016, the year of the Great Halvening? April or even May?
You're thinking of proposals that people dislike, not proposals that have received a warm welcome. Pieter Wuille is highly respected, mainly because of his amazing computer science work so far. This sounds to be more of the same, and all you can do is lie and hate? I feel genuinely sorry for you Zara, it can't be much fun, for you or your friends, being such a bitter person.
|
Vires in numeris
|
|
|
hunnaryb
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 10:09:59 AM |
|
I don't understand any of this, maybe there can be something written for the less technical among us?
|
▇▇▇▇ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇
| | | |
|
|
|
Lauda (OP)
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 10:15:33 AM |
|
You're thinking of proposals that people dislike, not proposals that have received a warm welcome. Pieter Wuille is highly respected, mainly because of his amazing computer science work so far. This sounds to be more of the same, and all you can do is lie and hate? I feel genuinely sorry for you Zara, it can't be much fun, for you or your friends, being such a bitter person.
Just ignore anyone who ignores this: fixing malleability, improving upgradability; improving scaleability, and increasing capacity.
This is very important (the first 3). This proposal received a warm welcome on the conference.
I don't understand any of this, maybe there can be something written for the less technical among us?
There already was an airplane analogy. Re-read the whole thread. I've updated the thread title a bit.
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 10:16:13 AM |
|
It was never presented or intended to be "the solution" and merely a small peice of a puzzle in a comprehensive and holistic approach to addressing Scalability and capacity. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.htmlTL;DR: I propose we work immediately towards the segwit 4MB block soft-fork which increases capacity and scalability, and recent speedups and incoming relay improvements make segwit a reasonable risk. BIP9 and segwit will also make further improvements easier and faster to deploy. We’ll continue to set the stage for non-bandwidth-increase-based scaling, while building additional tools that would make bandwidth increases safer long term. Further work will prepare Bitcoin for further increases, which will become possible when justified, while also providing the groundwork to make them justifiable.
Concurrently, there is a lot of activity ongoing related to “non-bandwidth” scaling mechanisms. Non-bandwidth scaling mechanisms are tools like transaction cut-through and bidirectional payment channels which increase Bitcoin’s capacity and speed using clever smart contracts rather than increased bandwidth. Critically, these approaches strike right at the heart of the capacity vs autotomy trade-off, and may allow us to achieve very high capacity and very high decentralization.
Further out, there are several proposals related to flex caps or incentive-aligned dynamic block size controls based on allowing miners to produce larger blocks at some cost.
Finally--at some point the capacity increases from the above may not be enough. Delivery on relay improvements, segwit fraud proofs, dynamic block size controls, and other advances in technology will reduce the risk and therefore controversy around moderate block size increase proposals (such as 2/4/8 rescaled to respect segwit's increase). Bitcoin will be able to move forward with these increases when improvements and understanding render their risks widely acceptable relative to the risks of not deploying them. In Bitcoin Core we should keep patches ready to implement them as the need and the will arises, to keep the basic software engineering from being the limiting factor.
|
|
|
|
Zarathustra
Legendary
Offline
Activity: 1162
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 10:35:29 AM |
|
Lol you clearly still cant read with any proficiency. For how many month will it be 'the solution' in 2016, the year of the Great Halvening? April or even May?
You're thinking of proposals that people dislike, not proposals that have received a warm welcome. Pieter Wuille is highly respected, mainly because of his amazing computer science work so far. This sounds to be more of the same, and all you can do is lie and hate? I feel genuinely sorry for you Zara, it can't be much fun, for you or your friends, being such a bitter person. Your stupid projections. Are you crazy? We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.
|
|
|
|
Zarathustra
Legendary
Offline
Activity: 1162
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 10:42:14 AM |
|
"I think that right now capacity is high enough and the needed capacity is low enough that we don't immediately need these proposals, but they will be critically important long term." Is this a joke? What is long term? 1 month before the halving date oder 1 month after?
|
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 11:01:01 AM |
|
projections. Are you crazy? We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.
No developer is suggesting it is "the solution". The fact that you cannot see that after we keep clarifying and providing contrary evidence suggests you are acting irrationally. "I think that right now capacity is high enough and the needed capacity is low enough that we don't immediately need these proposals, but they will be critically important long term."
Is this a joke? What is long term? 1 month before the halving date oder 1 month after?
Serious people do not pretend to know the how quickly we will need to scale the capacity needs in the future. This is why a very responsible approach is outlined here- In Bitcoin Core we should keep patches ready to implement them as the need and the will arises, to keep the basic software engineering from being the limiting factor.
If we make sloppy and dumb capacity upgrades in fear and haste we don't have the right incentives to make the right tradeoffs and develop optimal solutions which benefit all. There is no harm in having tested backup plans if the need arises and demand increases more than expected. The paypal and Visa network have outages all the time and the ecosystem doesn't simply crumble in chaos. with bitcoin the worst fear is some transactions being delayed from confirmation while payment processors rely on 0 conf verification more heavily while an agreed upon and tested hardfork gets deployed. This is far less of an issue than the Visa payment network/paypal being down.
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 11:01:53 AM |
|
We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.
If this is your impression of being welcoming, then I'd certainly avoid any event where you were greeting the guests. And more doomsday deadline scaremongering, after last time? Come on now.
|
Vires in numeris
|
|
|
Zarathustra
Legendary
Offline
Activity: 1162
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 11:08:43 AM |
|
If we make sloppy and dumb capacity upgrades in fear and haste we don't have the right incentives to make the right tradeoffs and develop optimal solutions which benefit all. There is no harm in having tested backup plans if the need arises and demand increases more than expected.
Some say that a 'monster softfork' would be a dumber 'immediate' short term last minute solution than a simple increase of the block size, when everyone can see that the capacity is at the limit right now and the halving event is just 7 month away.
|
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 11:13:15 AM |
|
We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.
If this is your impression of being welcoming, then I'd certainly avoid any event where you were greeting the guests. And more doomsday deadline scaremongering, after last time? Come on now. It is almost as if he believes that the only thing holding bitcoin back is capacity...and as soon as we build the 100k seat stadium it will be filled. Even if these optimistic delusions are correct it would be disastrous for the bitcoin ecosystem to have that rapid of growth in such short order. I am so glad there are enough rational and calm developers contributing and who are aware of the nuances and trade offs in decentralization and security. Some say that a 'monster softfork' would be a dumber 'immediate' short term last minute solution than a simple increase of the block size, when everyone can see that the capacity is at the limit right now and the halving event is just 7 month away.
Define simple. Bitpays BiP 101 patch actually has more lines of code than the SW softfork.
|
|
|
|
Zarathustra
Legendary
Offline
Activity: 1162
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 11:13:39 AM |
|
You're thinking of proposals that people dislike, not proposals that have received a warm welcome. Pieter Wuille is highly respected, mainly because of his amazing computer science work so far. This sounds to be more of the same, and all you can do is lie and hate? I feel genuinely sorry for you Zara, it can't be much fun, for you or your friends, being such a bitter person.
Just ignore anyone who ignores this: Ah, the ignoring user changed the title of his thread.
|
|
|
|
Zarathustra
Legendary
Offline
Activity: 1162
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 11:15:22 AM |
|
We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.
If this is your impression of being welcoming, then I'd certainly avoid any event where you were greeting the guests. And more doomsday deadline scaremongering, after last time? Come on now. It is almost as if he believes that the only thing holding bitcoin back is capacity...and as soon as we build the 100k seat stadium it will be filled. More projections out of thin air. Crazy.
|
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 01:14:42 PM |
|
ETA update- http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011875.html"- Segwit BIP is being written, but has not yet been published. - Gregory linked to an implementation but as he mentions it is not completely finished yet. ETA for a Segwit testnet* is later this month, then you can test as well. Wladimir" I assume Wladimir is refering to rolling segwit into the main bitcoin testnet instead of being tested merely in elements sidechain testnet .
|
|
|
|
johnyj
Legendary
Offline
Activity: 1988
Merit: 1012
Beyond Imagination
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 03:33:05 PM |
|
Pieter Wuille is highly respected because he is one of the devs that made the right conservative approach during the 2013 fork. Still, his proposal can not be taken without careful review
We know that every large player here in bitcoin community never listen to anyone else but only themselves, so unless a proposal can be understand by them it will just be ignored. People ignore Gavin's solution just because they don't understand the potential risk for his radical change in block size limit. Similarly, if Pieter's solution is so complex (much more complex than Gavins) that it is not understandable for majority of the large players, it will just be ignored. You can never convince the large mining pools with those slides
|
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 04:05:03 PM |
|
Pieter Wuille is highly respected because he is one of the devs that made the right conservative approach during the 2013 fork. Still, his proposal can not be taken without careful review
We know that every large player here in bitcoin community never listen to anyone else but only themselves, so unless a proposal can be understand by them it will just be ignored. People ignore Gavin's solution just because they don't understand the potential risk for his radical change in block size limit. Similarly, if Pieter's solution is so complex (much more complex than Gavins) that it is not understandable for majority of the large players, it will just be ignored. You can never convince the large mining pools with those slides
Am I wrong to assume that the large mining pool owners aren't well versed in the rudimentary basics of bitcoin? If I can understand it, I am sure they can.
|
|
|
|
brg444
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 04:07:54 PM |
|
Pieter Wuille is highly respected because he is one of the devs that made the right conservative approach during the 2013 fork. Still, his proposal can not be taken without careful review
We know that every large player here in bitcoin community never listen to anyone else but only themselves, so unless a proposal can be understand by them it will just be ignored. People ignore Gavin's solution just because they don't understand the potential risk for his radical change in block size limit. Similarly, if Pieter's solution is so complex (much more complex than Gavins) that it is not understandable for majority of the large players, it will just be ignored. You can never convince the large mining pools with those slides
Am I wrong to assume that the large mining pool owners aren't well versed in the rudimentary basics of bitcoin? If I can understand it, I am sure they can. It's mostly a lack of communication and language barrier. (with regards to chinese mining pool)
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
johnyj
Legendary
Offline
Activity: 1988
Merit: 1012
Beyond Imagination
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 04:13:19 PM |
|
Back to the basic: How can you validate a transaction without the signature? You can not, otherwise a node will be able to spend anyone's coin and bitcoin will immediately worth nothing overnight
It seems that after the validation and the transaction is finalized in the block, if node can verify the validity of the block, then it requires no detailed transaction data, since everything in that block is regarded as valid
However, if a rogue node send out a block appears to be valid but with transactions with wrong signature, then if other nodes do not validate each transactions in the block, they have no way to know if those transactions are valid, if they approve those blocks and start to build block above this block then those invalid transactions can even spend satoshi's coins
Therefore bitcoin is designed so that any nodes are able to independently verify every transaction, so that it is secure on every node. And that will include lots of data in each block
In order to come over this limitation, Pieter suggested to redesign bitcoin, where the hashes of all the signature goes into the coinbase. But still, without the original transaction data together with signature, you have no way to prove that the hashes are correct, you would still need all those data to prove the validity of each hash. However, those data would be in another chain, then it will reduce the data on main chain, but put the data into a side chain. And in future, that side chain will have all the capacity problem that bitcoin chain have today, even more difficult to deal with
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 04:23:56 PM |
|
In order to come over this limitation, Pieter suggested to redesign bitcoin, where the hashes of all the signature goes into the coinbase. But still, without the original transaction data together with signature, you have no way to prove that the hashes are correct, you would still need all those data to prove the validity of each hash. However, those data would be in another chain, then it will reduce the data on main chain, but put the data into a side chain. And in future, that side chain will have all the capacity problem that bitcoin chain have today, even more difficult to deal with
1. Not a side chain, a parallel chain. For every header'ed block, there must be a corresponding SegWit block. Not a side chain. 2. SegWit chain is prunable. Future chain bloat not a problem. You haven't taken it all in yet (and neither have I)
|
Vires in numeris
|
|
|
brg444
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 04:26:29 PM |
|
In order to come over this limitation, Pieter suggested to redesign bitcoin, where the hashes of all the signature goes into the coinbase. But still, without the original transaction data together with signature, you have no way to prove that the hashes are correct, you would still need all those data to prove the validity of each hash. However, those data would be in another chain, then it will reduce the data on main chain, but put the data into a side chain. And in future, that side chain will have all the capacity problem that bitcoin chain have today, even more difficult to deal with
1. Not a side chain, a parallel chain. For every header'ed block, there must be a corresponding SegWit block. Not a side chain. 2. SegWit chain is prunable. Future chain bloat not a problem. You haven't taken it all in yet (and neither have I) To be exact it's more like a parallel merkle tree than a chain if I understand it correctly.
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
johnyj
Legendary
Offline
Activity: 1988
Merit: 1012
Beyond Imagination
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 04:27:00 PM |
|
Pieter Wuille is highly respected because he is one of the devs that made the right conservative approach during the 2013 fork. Still, his proposal can not be taken without careful review
We know that every large player here in bitcoin community never listen to anyone else but only themselves, so unless a proposal can be understand by them it will just be ignored. People ignore Gavin's solution just because they don't understand the potential risk for his radical change in block size limit. Similarly, if Pieter's solution is so complex (much more complex than Gavins) that it is not understandable for majority of the large players, it will just be ignored. You can never convince the large mining pools with those slides
Am I wrong to assume that the large mining pool owners aren't well versed in the rudimentary basics of bitcoin? If I can understand it, I am sure they can. Do you really understand what Pieter is suggesting? And the possible consequence in future if it is adopted? We have observed, even simply raise the blocksize limit to 8MB which is simple enough for anyone to understand will result in huge resistance, this kind of complex solution which requires decision makers to have deep understanding of the inner workings of blocks and nodes would never get serious acceptance if any at all
|
|
|
|
|