Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) - page 33.

BitUsher

legendary

Activity: 994

Merit: 1035

Quote from: VeritasSapere on December 15, 2015, 06:16:20 PM

Lets say hypothetically we both support BIP103 and so does the economic majority, we would most likely still need to go against the "developer consensus" of Core. In order to have it implemented. This of course changes when or if Core changes their tune, though presently that does not seem to be the case. Surely there would even be a limit to your patience in regards to increasing the blocksize, even if just hypothetically, since we can not predict the future.

So you are suggesting the developers can never find consensus with any modest scaling proposal ?.. Segwit is already proving you wrong there... but good thing the developers are irrelevant when it comes to deciding on increasing the blocksize anyways , they just write the code... and this is what you don't seem to understand ... the reason the miners haven't agreed with 101 or Xt is because they don't agree with it and think its too aggressive. They respect the developers opinions because they aren't obtuse and are very knowledgeable in the incentive structures and risks with scaling themselves.

Miners are the ones that hold the majority of the power. Right now I see up to 5% hashing power possibly supporting XT.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: BitUsher on December 15, 2015, 06:07:03 PM

Quote from: VeritasSapere on December 15, 2015, 05:51:47 PM

Quote from: BitUsher on December 15, 2015, 05:48:01 PM

Quote from: VeritasSapere on December 15, 2015, 05:41:16 PM

I am not waiting for anyone, I am running XT nodes and mining in support of BIP101, well until slush got DDOS for mining BIP101 that is. I also was not talking about hardrive space, the size of the blocks are relevant to bandwidth and latency which I agree are the primary limitations for the block size limit.

https://github.com/bitcoin/bips/commit/23208ea690c0f1c2b0faa2e82df98f4a6cf7b404

Reflects a BIP that follows the evidence from past historical trends. Do you deny the data?

If you are running XT nodes than you are indeed waiting for others as the code itself needs a miner "minor"super-majority to be activated. Just change the code and start the fork now with your friends. There is nothing holding you back, just 1 line of code.

In regards to BIP103, I refuse to "trust" the core developers to implement this. I will believe it when I see it.

I prefer to move with consensus, we need to give this more time to play out. When we do split however it will be much more then just me and a few friends (that was intended as a snarky joke right?). We will be taking the economic majority with us and the most important businesses as well. Since they are in support of BIP101.

https://bitco.in/forum/threads/who-is-for-and-against-expanding-the-block-size-reasonably-soon.119/

You might want to check out Bitcoin unlimited as well:

https://bitco.in/forum/forums/bitcoin-unlimited.15/
http://www.bitcoinunlimited.info/articlesOfFederation

The data doesn't come from the core devs. Do you deny the data that BIP 103 is based upon?
That email thread is very misleading and doesn't accurately represent the change in individuals opinions or the nuanced statements they are making.
Do you really believe that the majority of the miners will agree to XT or BIP101 without 99.5% of the developers support?

I am not denying anything, I have even said on record that I would even support BIP103 when implemented. It is good to keep in mind that the starting point for these proposals are not necessarily already at the limit of our technology today, I think this influences the predictions for growth.

I have reject the concept of "developer consensus" I am finding that this small group of people are becoming more and more irrelevant in terms of what the best path for Bitcoin into the future should be.

Lets say hypothetically we both support BIP103 and so does the economic majority, we would most likely still need to go against the "developer consensus" of Core, in order to have BIP103 implemented. This of course changes when or if Core changes their tune, though presently that does not seem to be the case. Surely there would even be a limit to your patience in regards to increasing the blocksize, even if just hypothetically.

For me actually the most important issue at play here is about the governance of Bitcoin, the blocksize debate has just brought this to the surface. I believe this is part of a greater political awaking within the Bitcoin community and part of a necessary process for the evolution and growth of the Bitcoin protocol as a whole.

BitUsher

legendary

Activity: 994

Merit: 1035

Quote from: VeritasSapere on December 15, 2015, 05:51:47 PM

Quote from: BitUsher on December 15, 2015, 05:48:01 PM

Quote from: VeritasSapere on December 15, 2015, 05:41:16 PM

I am not waiting for anyone, I am running XT nodes and mining in support of BIP101, well until slush got DDOS for mining BIP101 that is. I also was not talking about hardrive space, the size of the blocks are relevant to bandwidth and latency which I agree are the primary limitations for the block size limit.

https://github.com/bitcoin/bips/commit/23208ea690c0f1c2b0faa2e82df98f4a6cf7b404

Reflects a BIP that follows the evidence from past historical trends. Do you deny the data?

If you are running XT nodes than you are indeed waiting for others as the code itself needs a miner "minor"super-majority to be activated. Just change the code and start the fork now with your friends. There is nothing holding you back, just 1 line of code.

In regards to BIP103, I refuse to "trust" the core developers to implement this. I will believe it when I see it.

I prefer to move with consensus, we need to give this more time to play out. When we do split however it will be much more then just me and a few friends (that was intended as a snarky joke right?). We will be taking the economic majority with us and the most important businesses as well. Since they are in support of BIP101.

https://bitco.in/forum/threads/who-is-for-and-against-expanding-the-block-size-reasonably-soon.119/

You might want to check out Bitcoin unlimited as well:

https://bitco.in/forum/forums/bitcoin-unlimited.15/
http://www.bitcoinunlimited.info/articlesOfFederation

The data doesn't come from the core devs. Do you deny the data that BIP 103 is based upon?
That email thread is very misleading and doesn't accurately represent the change in individuals opinions or the nuanced statements they are making.
Do you really believe that the majority of the miners will agree to XT or BIP101 without 99.5% of the developers support? Hearn and Gavin don't want to even support XT anymore ... do you have other devs willing to maintain the repo?

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: BitUsher on December 15, 2015, 05:48:01 PM

Quote from: VeritasSapere on December 15, 2015, 05:41:16 PM

I am not waiting for anyone, I am running XT nodes and mining in support of BIP101, well until slush got DDOS for mining BIP101 that is. I also was not talking about hardrive space, the size of the blocks are relevant to bandwidth and latency which I agree are the primary limitations for the block size limit.

https://github.com/bitcoin/bips/commit/23208ea690c0f1c2b0faa2e82df98f4a6cf7b404

Reflects a BIP that follows the evidence from past historical trends. Do you deny the data?

If you are running XT nodes than you are indeed waiting for others as the code itself needs a miner "minor"super-majority to be activated. Just change the code and start the fork now with your friends. There is nothing holding you back, just 1 line of code.

In regards to BIP103, I refuse to "trust" the core developers to implement this. I will believe it when I see it.

I prefer to move with consensus, we need to give this more time to play out. When we do split however it will be much more then just me and a few friends (that was intended as a snarky joke right?). We will be taking the economic majority with us and the most important businesses as well. Since they are in support of BIP101.

https://bitco.in/forum/threads/who-is-for-and-against-expanding-the-block-size-reasonably-soon.119/

You might want to check out Bitcoin unlimited as well:

https://bitco.in/forum/forums/bitcoin-unlimited.15/
http://www.bitcoinunlimited.info/articlesOfFederation

BitUsher

legendary

Activity: 994

Merit: 1035

Quote from: VeritasSapere on December 15, 2015, 05:41:16 PM

I am not waiting for anyone, I am running XT nodes and mining in support of BIP101, well until slush got DDOS for mining BIP101 that is. I also was not talking about hardrive space, the size of the blocks are relevant to bandwidth and latency which I agree are the primary limitations for the block size limit.

https://github.com/bitcoin/bips/commit/23208ea690c0f1c2b0faa2e82df98f4a6cf7b404

Reflects a BIP that follows the evidence from past historical trends. Do you deny the data?

If you are running XT nodes than you are indeed waiting for others as the code itself needs a miner "minor"super-majority to be activated. Just change the code and start the fork now with your friends. There is nothing holding you back, just 1 line of code.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: tvbcof on December 13, 2015, 11:27:52 PM

Quote from: VeritasSapere on December 13, 2015, 11:13:42 PM

I consider Mike Hearn, Gavin Andresen, jtoomim and the theZerg to better align with my believes and world view as developers compared to the Core developers you mention. I prefer their understanding of free market economics and Bitcoin governance specifically.

Totally! I call again to 'stop worrying and love the blockchain fork' (put more amusingly than I was able by...um...that very bright Israeli mining algo specialist who's name escapes me at the moment.) It would be great for all concerned to focus on what is important to them and not be bothered by the other side.

Now is a great time to do it while Bitcoin is relatively small not having yet been economically necessary on a broad scale. It is also fairly clear in most people's minds what is the right direction for their goals, and equally importantly, things seem to be pretty binary between a bloating system which gains strength from a broad userbase, and a tight system which derives strength from broad infrastructure support distribution.

Edit: Oh ya, Meni Rosenfeld (or something close to that.)

I think tvbcof said it well, he was able to show merit in both positions, there are not a lot of people within the Bitcoin space that are able to do this, including myself, so well done for that tvbcof.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: BitUsher on December 15, 2015, 05:36:21 PM

Quote from: VeritasSapere on December 15, 2015, 05:31:08 PM

Under the BIP101 schedule it would take more then twelve years in order to even reach 133MB blocks. The presumption is that within twelve years the technology will have advanced and this will be considered "small".

Hard drive space is the least of my and other devs concerns with blocksize. Why presume future technology when bandwidth hasn't scaled correspondingly as you suggest in the past? Shouldn't we look towards past historical trends of evidence as an indication?

Quote from: VeritasSapere on December 15, 2015, 05:36:03 PM

This is why I am starting to prefer to just split the network and allow the market to decide over the long term which chain will be considered superior.

Agreed. Just do it already. What are you waiting for? Most people are already well entrenched in their positions as we have been discussing this for years.

I am not waiting for anyone, I am running XT nodes and mining in support of BIP101, well until slush got DDOS for mining BIP101 that is. I was also not talking about hardrive space, the size of the blocks are relevant to bandwidth and latency which I agree are the primary limitations for the block size limit.

Slush will re enable BIP101 mining soon before January at least, and hopefully some major companies will make a move soon which will allow this split to occur. It seems like this is what Gavin was hinting towards I hope in one of his latest posts.

Quote from: Gavin Andresen

Be a little patient... there is stuff happening I've promised not to talk about yet. You aren't the only one unhappy about the priorities of the Bitcoin Core project....

BitUsher

legendary

Activity: 994

Merit: 1035

Quote from: VeritasSapere on December 15, 2015, 05:31:08 PM

Under the BIP101 schedule it would take more then twelve years in order to even reach 133MB blocks. The presumption is that within twelve years the technology will have advanced and this will be considered "small".

Hard drive space is the least of my and other devs concerns with blocksize. Why presume future technology when bandwidth hasn't scaled correspondingly as you suggest in the past? Shouldn't we look towards past historical trends of evidence as an indication?

Quote from: VeritasSapere on December 15, 2015, 05:36:03 PM

This is why I am starting to prefer to just split the network and allow the market to decide over the long term which chain will be considered superior.

Agreed. Just do it already. What are you waiting for? Most people are already well entrenched in their positions as we have been discussing this for years. It isn't like your changes are difficult to code or anything... the code is already done and in the wild. All you need is one project maintainer to leach off of core's github.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: BitUsher on December 15, 2015, 05:32:11 PM

Quote from: forevernoob on December 15, 2015, 05:25:19 PM

Well I'm not entirely against hard forks. But I don't think we should rush any hard fork decisions at this point.
Hopefully like you say in the future the new tech will make LN work without huge blocks.

Don't worry , there is definitely not going to be a rush with segwit and relaynetwork improvements being a softfork ..expect 6months to 1 year.
This is why Gavin was freaking out. We aren't at capacity now, but realistically will be sometime in 2016 and a fee market will start to take hold raising prices.
Smart business people should consider this and start creating trustless "off-the chain " solutions like changetip + CLTV contracts as workarounds when these capacity limits are hit.... it is coming, my guess march to may 2016 we will start see tx fees increasing.

I do disagree with this. You do seem reasonable though unlike some of the other Core advocates here. I think there is a major and fundamental ideological disagreement about the future of Bitcoin. This is why I am starting to prefer to just split the network and allow the market to decide over the long term which chain will be considered superior.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: forevernoob on December 15, 2015, 05:29:57 PM

Quote from: VeritasSapere on December 15, 2015, 05:16:54 PM

This is an example of the nirvana fallacy at work, an 8000x increase in throughput in twenty years from now, I would certainly consider a significant increase in the scale of Bitcoin. Compared to leaving the blocksize at one megabyte. It is worth thinking about the practical difference even a small increase would make for the economy as a whole. Some of these engineers seem to be to academic in these questions and not actually grounded in the practical reality of the world.

With side chains the possibilities for scaling Bitcoin are endless.
Why risk a dangerous fork if it doesn't solve the scaling issue?
What you describe is a increase of blocksize not a scaling solution.

Increasing the blocksize does increases the throughput of the Bitcoin blockchain, I certainly would consider that a scaling solution. I think it is more dangerous not to do any hard forks considering how important this mechanism is for the governance of Bitcoin.

BitUsher

legendary

Activity: 994

Merit: 1035

Quote from: forevernoob on December 15, 2015, 05:25:19 PM

Well I'm not entirely against hard forks. But I don't think we should rush any hard fork decisions at this point.
Hopefully like you say in the future the new tech will make LN work without huge blocks.

Don't worry , there is definitely not going to be a rush with segwit and relaynetwork improvements being a softfork ..expect 6months to 1 year.
This is why Gavin was freaking out. We aren't at capacity now, but realistically will be sometime in 2016 and a fee market will start to take hold raising prices.
Smart business people should consider this and start creating trustless "off-the chain " solutions like changetip + CLTV contracts as workarounds when these capacity limits are hit.... it is coming, my guess march to may 2016 we will start see tx fees increasing.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: BitUsher on December 15, 2015, 05:18:28 PM

Quote from: forevernoob on December 15, 2015, 05:03:59 PM

I didn't get the 2+4+8MB part.
Are you talking about a hard fork?

Yes, the devs are weighing in on complex solutions like flex cap and Adam Back's 2-4-8 proposal or other hard fork solutions. The LN devs need over 8MB to make the caching layer scale practical or worthwhile. To out-compete Visa tps they discussed 133MB size blocks with LN. Hopefully those sizes are never needed or we live in a future where new tech makes them "small"

https://lightning.network/lightning-network.pdf

Under the BIP101 schedule it would take more then twelve years in order to even reach 133MB blocks. The presumption is that within twelve years the technology will have advanced and this will be considered "small". I have even suggested changing BIP101 so that it starts at 2MB, that way you would have 2-4-8 within a six year period and it would then take another twenty years to reach 133MB blocks, this would lower the potential max blocksize limit as well. I figured some of the people here at least would like such a solution, I bring it up only as a compromise, though it does seem like Core is completely unwilling to compromise with the other side of this debate, so this is unlikely to happen, I suspect we will see Bitcoin split.

It is also good to point out that the blocksize limit does not actually determine the size of the blocks, in the same sense that blocks are only filling up now yet we have had this limit for a long time, the limit was even set at 32MB earlier in its history and this was also not a problem, the blocksize limit was only added as a temporary anti spam measure. I would like to add here as well that after twenty years the block size can of course be changed again, though I suspect the landscape will be very different by then.

forevernoob

hero member

Activity: 687

Merit: 500

Quote from: VeritasSapere on December 15, 2015, 05:16:54 PM

This is an example of the nirvana fallacy at work, an 8000x increase in throughput in twenty years from now, I would certainly consider a significant increase in the scale of Bitcoin. Compared to leaving the blocksize at one megabyte. It is worth thinking about the practical difference even a small increase would make for the economy as a whole. Some of these engineers seem to be to academic in these questions and not actually grounded in the practical reality of the world.

With side chains the possibilities for scaling Bitcoin are endless.
Why risk a dangerous fork if it doesn't solve the scaling issue?
What you describe is a increase of blocksize not a scaling solution.

forevernoob

hero member

Activity: 687

Merit: 500

Quote from: BitUsher on December 15, 2015, 05:18:28 PM

Quote from: forevernoob on December 15, 2015, 05:03:59 PM

I didn't get the 2+4+8MB part.
Are you talking about a hard fork?

Yes, the devs are weighing in on complex solutions like flex cap and Adam Back's 2-4-8 proposal or other hard fork solutions. The LN devs need over 8MB to make the caching layer scale practical or worthwhile. To out-compete Visa tps they discussed 133MB size blocks with LN. Hopefully those sizes are never needed or we live in a future where new tech makes them "small"

https://lightning.network/lightning-network.pdf

Well I'm not entirely against hard forks. But I don't think we should rush any hard fork decisions at this point.
Hopefully like you say in the future the new tech will make LN work without huge blocks.

BitUsher

legendary

Activity: 994

Merit: 1035

Quote from: forevernoob on December 15, 2015, 05:03:59 PM

I didn't get the 2+4+8MB part.
Are you talking about a hard fork?

Yes, the devs are weighing in on complex solutions like flex cap and Adam Back's 2-4-8 proposal or other hard fork solutions. The LN devs need over 8MB to make the caching layer scale practical or worthwhile. To out-compete Visa tps they discussed 133MB size blocks with LN. Hopefully those sizes are never needed or we live in a future where new tech makes them "small"

https://lightning.network/lightning-network.pdf

Quote from: theymos on December 15, 2015, 05:16:58 PM

When I heard yesterday that btcdrak was made a moderator of /r/btc, my first thoughts were "Maybe /r/Bitcoin finally has a bit of competition" and "I wonder how long that'll last". The answer: probably not very long. As someone (iCEBREAKER?) predicted, these people will just keep forking themselves into oblivion.

Shame, btcdrak is a really smart and prolific guy. https://www.youtube.com/watch?v=kjP6hezfpUI

theymos

administrator

Activity: 5222

Merit: 13032

When I heard yesterday that btcdrak was made a moderator of /r/btc, my first thoughts were "Maybe /r/Bitcoin finally has a bit of competition" and "I wonder how long that'll last". The answer: probably not very long. As someone (iCEBREAKER?) predicted, these people will just keep forking themselves into oblivion.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: forevernoob on December 15, 2015, 05:11:28 PM

Quote from: VeritasSapere on December 15, 2015, 05:08:17 PM

This meme that Bitcoin can not scale is false, it is perpetuated by the Core developers who maintain the nirvana fallacy in engineering. Bitcoin does not scale efficiently, but it certainly can scale. We just need to increase the blocksize. To answer your question, this does require a hard fork, hard forks are the only way to increase the blocksize.

Hard forks are also an important governance mechanism within Bitcoin which allow us to resolve fundamental differences and disagreements, even if that might mean splitting Bitcoin, at least that is better then the tyranny of the majority or even minority in this case.

I thought BitcoinXT max out at 8GB's per block? How is that scaling?

This is an example of the nirvana fallacy at work, an 8000x increase in throughput in twenty years from now, I would certainly consider a significant increase in the scale of Bitcoin. Compared to leaving the blocksize at one megabyte. It is worth thinking about the practical difference even a small increase would make for the economy as a whole. Some of these engineers seem to be to academic in these questions and not actually grounded in the practical reality of the world.

marcus_of_augustus

legendary

Activity: 3920

Merit: 2349

Eadem mutata resurgo

Quote

Bitcoin does not scale efficiently, but it certainly can scale. We just need to increase the blocksize. To answer your question, this does require a hard fork, hard forks are the only way to increase the blocksize.

Hard forks are also an important governance mechanism within Bitcoin which allow us to resolve fundamental differences and disagreements, even if that might mean splitting Bitcoin, at least that is better then tyranny of the majority.

... these are your talking points, and the limit of your understanding of what you think you know about bitcoin, let alone anything of the technology.

You are doing an admirable job of banging on incessantly, in the way of propaganda, upon these points but nothing else, nor adding to any solutions. Go invent your own altcoin if you hate the Core developers with such venom.

Engineering projects are inevitably the worse off when politicians and lawyers try to politicise the technology. If you want to use a monetary system that has been politicised and legislated to death, use the US Federal Reserve's debt notes system.

forevernoob

hero member

Activity: 687

Merit: 500

Quote from: VeritasSapere on December 15, 2015, 05:08:17 PM

This meme that Bitcoin can not scale is false, it is perpetuated by the Core developers who maintain the nirvana fallacy in engineering. Bitcoin does not scale efficiently, but it certainly can scale. We just need to increase the blocksize. To answer your question, this does require a hard fork, hard forks are the only way to increase the blocksize.

Hard forks are also an important governance mechanism within Bitcoin which allow us to resolve fundamental differences and disagreements, even if that might mean splitting Bitcoin, at least that is better then the tyranny of the majority or even minority in this case.

I thought BitcoinXT max out at 8GB's per block? How is that scaling?

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: forevernoob on December 15, 2015, 05:03:59 PM

Quote from: VeritasSapere on December 15, 2015, 04:52:19 PM

I do not consider the Lighting Network as an alternative to increasing the blocksize, this is also comes down to ideology however. Though I do not consider moving the majority of transactions off the Bitcoin blockchain as a solution to scaling the Bitcoin blockchain itself. A solution to creating a Peer-to-Peer Electronic Cash System already exists, its called Bitcoin. We just need to allow it to operate at scale like it was always intended to be.

Hate to break it to ya, but Bitcoin doesn't scale.

Quote from: BitUsher on December 15, 2015, 04:55:59 PM

The Lightning Network won't be very useful with just segwit alone in the longterm .

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

Segwit + LN + Relay Network Improvements + 2+4+8MB limit increase + more off the chain solutions and than other solutions layers ontop for scalability.

I don't get the 2+4+8MB part.
Are you talking about a hard fork?

This meme that Bitcoin can not scale is false, it is perpetuated by the Core developers who maintain the nirvana fallacy in engineering. Bitcoin does not scale efficiently, but it certainly can scale. We just need to increase the blocksize. To answer your question, this does require a hard fork, hard forks are the only way to increase the blocksize.

Hard forks are also an important governance mechanism within Bitcoin which allow us to resolve fundamental differences and disagreements, even if that might mean splitting Bitcoin, at least that is better then the tyranny of the majority or in this case the tyranny of a minority.

Topic: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) - page 33. (Read 378980 times)