What happens if BU fails VS What happens if SegWit fails

[Carlton Banks]

SegWit per se may not be dangerous, but it could open doors for the privatization of Bitcoin. This could make Bitcoin controllable by few and goes against one of the main principals of Bitcoin.

You don't mean privatisation, Bitcoin is already privately owned (in a similar way to how shareholders own businesses)

Your suggestion to "just" increase to 2-4MB is bizarre.

1. Validation attacks on blocks more than 1 MB mean Segwit is needed before any blocksize increases
2. Segwit increases the blocksize to 4MB anyway



Some claim that limiting sigops on both the base blocks and the witness blocks is a workable solution to validation attacks, but this could prevent the witness blocks from reaching capacity, making some part of the 3MB witness blocks redundant.

Claims that attacking non-Segwit addresses are equally incorrect; that attack can be performed today. It doesn't work at 1MB, so no-one tries. After Segwit activation, the situation will be identical to today; only the base 1MB can be attacked with a sigops validation attack, not the witness blocks. Miners could detect and drop transactions that attempt validation attacks.

[1715014479]

1715014479

[1715014479]

1715014479

[1715014479]

1715014479

[1715014479]

1715014479

[franky1]

^ look at him talking about something he doesnt understand

segwit only works for people using segwit keys. anyone sticking with native keys can still cause signop issues within blocks.
the only way to avoid sigop issues in blocks is that 0% .. ZERO .. again ZERO(emphasised 3 times) users have funds on native tx's.

segwit does not disarm native transactions so sigop and malleability will continue.
segwit only disarms the innocent that voluntarily move funds to segwit tx's.. it does not disarm the malicious users

segwits 4mb wight is not a real 'feature' that all bitcoin users get to benefit from.

firstly only IF 100% of users use segwit keys, they would notice about a 2.1mb transaction one time boost.
the other 1.9mb is spare and unusable for anyone until future features ar added that append trivial data to the end of a tx for things like
confidential tx's

if the base block sticks to 1mb. the max expectation is ~4500tx with 2.1mb weight.
then if confidential payment codes and other features append data.. its still 4500tx but bloated to take up the spare space of the 4mb weight

[jonald_fyookball]

  Regarding BU people are more concerned about the risk of an technical problem. 

The opponents of BU are small block advocates that prefer the average user be
able to run a full node than be able to transaction on chain and are more
concerned about having transaction fees pay be able to pay for security
in the future even though that concern is decades away.

While I fully disagree with both of those reasons, at least they have some inkling of plausibility.
However I haven't seen any credible argument for the possibility of a technical problem with BU.

 

[franky1]

  Regarding BU people are more concerned about the risk of an technical problem. 

The opponents of BU are small block advocates that prefer the average user be
able to run an LN node for hop charging profit, rather than be able to transaction on chain.. and are more
concerned about having transaction fees pay themselves rather than pay for security
in the future even though that concern is decades away.

While I fully disagree with both of those reasons, at least they have some inkling of plausibility.
However I haven't seen any credible argument for the possibility of a technical problem with BU.

 

FTFY

[jonald_fyookball]

  Regarding BU people are more concerned about the risk of an technical problem. 

The opponents of BU are small block advocates that prefer the average user be
able to run an LN node for hop charging profit, rather than be able to transaction on chain.. and are more
concerned about having transaction fees pay themselves rather than pay for security
in the future even though that concern is decades away.

While I fully disagree with both of those reasons, at least they have some inkling of plausibility.
However I haven't seen any credible argument for the possibility of a technical problem with BU.

 

FTFY

I was attempting to be diplomatic and impartial...but thank you

[kiklo]

just to clarify kilo's point because he appears to be a hott head that runs in different directions rather than explaining the point rationally

pink flower said

I think youre misinformed or youre misinforming others about the Lightning Network. BTC Core doesnt have a monopoly on what layer is built on the network if segwit is activated. There are other groups who are already coding other executions of it.

well core have already positioned themselves as a ringfence around the pools with their "fibre" nodes.
if pools adopt segwit then the segwit pools will white list the "fibre" nodes as their way to maximise propagation efficiency.

segwit is known to blacklist nodes they dislike and whitelist other nodes. known to not relay certain transactions.

 so they can be biased against any smart contract that is not produced by LN(blockstreams version of second layer smart contracts) by  not relaying those to pools.
causing the issues for opposing second layer services by not being able to settle or set up channels in a timely manner. because their transactions will not be added to pools mempool or refused to enter a block
(much like core loving pools refuse to do 'first seen, first added' for transactions. and instead biasedly add transactions by who sent it and how much is paid(BTCC does this))

with core being the upstream filters (gmaxwells own words) and also demonstrated in cores own userguide.. core have set themselves up to centralise the network.

try reading the documentation and code whilst wearing a critical /logical thinking cap. and not a fanboy cap.
dont think about the limited benefits, promotional sales pitches.. look for the fine print limitations and realities.
EG
https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/

If you still don’t wish to upgrade, it is possible to use a newer Bitcoin Core release as a filter for older Bitcoin Core releases.

meaning you have to have a segwit node. to be able to be accepted by the other nodes.. and you are then able to whitelist your own non segwit node. (basically other peers will reject you unless you pretend you are a segwit node)

In this configuration, you set your current Bitcoin Core node (which we’ll call the “older node”) to connect exclusively to a node running Bitcoin Core 0.13.1 or later (which we’ll call the “newer node”). The newer node is connected to the Bitcoin P2P network as usual. Because the newer node knows about the segwit changes to the consensus rules, it won’t relay invalid blocks or transactions to the older node—but it will relay everything else.

When using this configuration, please note that the older node, if it uses Bitcoin Core defaults, will not see transactions using segwit features until those transactions are included in a block.

Configuration:

For the newer node, start it normally and let it sync the blockchain. At present, you cannot use a pruned node for this purpose because pruned nodes will not act as relay nodes. You may optionally start the newer node with either or both of the following command line parameters so that it treats the older node as special (these options may also be placed in Bitcoin Core’s configuration file):

  -whitebind=<addr>
       Bind to given address and whitelist peers connecting to it. Use
       [host]:port notation for IPv6

  -whitelist=<netmask>
       Whitelist peers connecting from the given netmask or IP address. Can be
       specified multiple times. Whitelisted peers cannot be DoS banned
       and their transactions are always relayed, even if they are
       already in the mempool, useful e.g. for a gateway

For the older node, first wait for the newer node to finish syncing the blockchain and then restart the older node with the following command line parameter (this may also be placed in the Bitcoin Core configuration file):

-connect=<IP_address_or_DNS_name_of_newer_node>

if you think the image is some anti core propaganda wallpaper from reddit.. check where the image is coming from (hint here is the link)
https://bitcoincore.org/assets/images/filtering-by-upgraded-node.svg

there are other little tip-bits of agenda hinted at in the userguide. how segwit will reject blocks that are not produced by segwit pools ensuring core has control of the network

If segwit reaches locked-in, you still don’t need to upgrade, but upgrading is strongly recommended. The segwit soft fork does not require you to produce segwit-style blocks, so you may continue producing non-segwit blocks indefinitely. However, once segwit activates, it will be possible for other miners to produce blocks that you consider to be valid but which every segwit-enforcing node rejects; if you build any of your blocks upon those invalid blocks, your blocks will be considered invalid too.

oh and by the way.
when pools make segwit blocks.. they wont be organically backward compatible. they will need to be 'filtered' to be presentable in a manner old nodes can understand.

meaning if segwit has a bug. the you cant just turn off segwit nodes and go back to old nodes which will understand the blockchain.
pools then have to do the filtering of the blocks while they too downgrade which can cause alot of disruption. due to them having to move funds back to native key types and other things to undo a segwit activation

where as a bu pool simply make blocks under 0.999mb without needing to downgrade/filter or move funds back. because BU uses the same mechanisms and transactions that were around for 2009-2016


p.s
if you feel my post is just a wall of text and you have not bothered reading it simply because its a wall of text. then you obviously dont have the concentration span to read userguides or code. this lack of attention span reduces your ability to understand bitcoin fully, so work on it

LOL, and you call me a hothead , my pompous comrade.  


 

FYI:  In the Words of Hot Rod, May God Rest his Soul.

[kiklo]

SegWit per se may not be dangerous, but it could open doors for the privatization of Bitcoin. This could make Bitcoin controllable by few and goes against one of the main principals of Bitcoin.

1. Validation attacks on blocks more than 1 MB mean Segwit is needed before any blocksize increases
2. Segwit increases the blocksize to 4MB anyway

Actually it would make more sense to increase the blocksize First before ever adding segwit.

Your Saint G.Maxwell has been quoted in the past saying blocksize increases would be needed after segwit.

I will tell you why they should do it first, their is a Security vulnerability in the LN whitepaper,
where if you can trigger a delay in the Blockchain's ability to process transactions , you can delay LN, until the timelocks have been released
and wait for it .............. STEAL THE BTC RIGHT OFF OF THE BLOCKCHAIN!!!

Larger the blocksize the safer the community from that direct vulnerability.  

So Blocksize should be increased first, but they know no one wants segwit and would ignore it completely ,
which is why all of this effort to force it down everyone's throat.  

 

FYI:
Segwit 4MB is not the same as a 4MB blocksize increase.
Segwit only gives a usable 1.7 MB of the current style blockchain which is theoretical , (may be higher , may be less.)
A direct 4MB blocksize increase without segwit would give 4X the current transaction capacity, which would actually hold BTC for years and keep transactions Onchain and completely avoid LN Offchain Counterfeit coins.

[Wind_FURY]

I admit that I still try to wrap my mind around the technical discussions about Bitcoin but knowing that there is politics involved here still makes me doubt what the hard fork to BU, Classic or XT is really all about. There has to be something like a power grab here. Also the argument that the Bitcoin Unlimited developers are not as good as the Core developers and contributors deserves notice.

[franky1]

I admit that I still try to wrap my mind around the technical discussions about Bitcoin but knowing that there is politics involved here still makes me doubt what the hard fork to BU, Classic or XT is really all about. There has to be something like a power grab here. Also the argument that the Bitcoin Unlimited developers are not as good as the Core developers and contributors deserves notice.

until you read the code and grasp the concepts of bitcoin. you will be stuck in the social drama of politics.
dont be so easy to grab onto some human and kiss their ass because of X or Y.
one day that human wont be here, but bitcoin will. so care more about bitcoin and less about the human

learn what the code does and let the code help you make your decisions.

core code is not a simple fix. its about changing the network topology and favouring nodes (centralising)

other implementations such as xt, classic, bitcoinj, btcd, bu and half a dozen others  are not about kings or gaining control of the network. they ALL want to use consensus to have all implementations on the same level playing field where nodes have the independent decentralised power, not devs not miners.

the whole point of bitcoin is that its not reliant on some central team of decision makers

so instead of playing the social games of which team is better. instead think.
let there be many teams so that none have power and only the nodes form a consensus of what should move forward.

that way the 'teams' become more like workers rather than managers. where the teams work to find the best solutions to bitcoin problems. instead of fighting to be kings and herding sheep in only a direction they want

[jonald_fyookball]

There has to be something like a power grab here. 

Ya think?   

Ask yourself: What company raised $71M in venture capital, wants to be "a leading provider of blockchain technologies", and hired many
of the prominent developers of the core bitcoin repository?

hint: It rhymes with "cock dream".

[hv_]

SegWit per se may not be dangerous, but it could open doors for the privatization of Bitcoin. This could make Bitcoin controllable by few and goes against one of the main principals of Bitcoin.

1. Validation attacks on blocks more than 1 MB mean Segwit is needed before any blocksize increases
2. Segwit increases the blocksize to 4MB anyway

Actually it would make more sense to increase the blocksize First before ever adding segwit.

Your Saint G.Maxwell has been quoted in the past saying blocksize increases would be needed after segwit.

You do not know anything - poor mate.

'Saint' can be called s.o. who is already dead  ...  banned is not enough.

 

[kiklo]

You do not know anything - poor mate.

'Saint' can be called s.o. who is already dead  ...  banned is not enough.

 

@hv_
Were you born this stupid, or do you have to work at it.  

 

FYI:
It was used as a form of parody, Dufus.  
Implying that CB Worships G.Maxwell believing all of his lies as gospel.

[hv_]

You do not know anything - poor mate.

'Saint' can be called s.o. who is already dead  ...  banned is not enough.

 

@hv_
Were you born this stupid, or do you have to work at it.  

 

FYI:
It was used as a form of parody, Dufus.  
Implying that CB Worships G.Maxwell believing all of his lies as gospel.

I'm just PoSting this shit to match your quality expectations - no PoW needed for you . sorry

[kiklo]

I'm just PoSting this shit to match your quality expectations - no PoW needed for you . sorry

I have no expectations of you , I know you are stupid. 

 

[kiklo]

BOOM BABY !!!

And there it is !! 


Gavin Andresen: “Run Bitcoin Unlimited” To Solve “Destructive Congestion”

https://cointelegraph.com/news/gavin-andresen-run-bitcoin-unlimited-to-solve-destructive-congestion

Run Bitcoin Unlimited. It is a viable, practical solution to destructive transaction congestion.

and what does he think of Segwit.

He added that Segregated Witness technology was “too little,” offering a block size increase of only two megabytes, which “would get hit before wallets and users adopt.”

 

[franky1]

the ~2.1mb POTENTIAL that segwit offers is:
only 4500tx/~2.1mb IF 100% of users have moved funds to segwit keys. and continue to only use segwit keys (not gonna happen)

its not going to change right at activation day.
its not going to change just by using a specific node.

it will only change when people move funds to a segwit key and then use segwit keys only,
and only grows at small amounts depending on how popular the use of segwit keys are UPTO the max POTENTIAL


so lets explain it. in regards to impact on tx demand

the mempool is nearly always well above 4500tx of unconfirmed tx's(2mb) in the mempool.
https://blockchain.info/charts/mempool-size?daysAverageString=7&timespan=1year
ever since october the lowest the mempool has been was 3mb+(meaning 4mb DEMAND if you include the 1mb that do get confirmed)

there is also currently 47million unspent outputs that would need to be spend to move everyone over to segwit keys
http://statoshi.info/dashboard/db/unspent-transaction-output-set

so even if segwit activated lets say tonight.. nothing changes.
lets say people downloaded segwit nodes and took a few days to sync
and then lets say EVERYONE (even the holders from 8 years ago) moved their funds to segwit keys.

do you understand the congestion it would cause to get funds moved to segwit keys before full benefit of segwit can be seen
imagine it everyone trying to move funds all at the same time...


then once everyone moved across.. that >3mb+(average demand) after everything has cooled off, results in still not enough even with the 1.1mb extra "boost" segwit offers

however just increasing the blocksize to 4mb without the bait and switch will alleviate things and people dont need to move funds to special new keytypes to see the benefit.


segwit REQUIRES people to move funds to new special keypairs that are not tested on bitcoins mainnet and do offer a new attack vector by manually copy and pasting the segwit keys from a segwit node to a native node and then messing with it as a 'anyonecanspend'

yep core might filter out tx's being sent automatically by a segwit nod to native node. but they cant stop manual copy and pasting between a segwit node and native node.


in short. segwit opens up new attack vectors. doesnt guarantee 100% utility of segwit and doesnt disarm the malicious users.

p.s my over use of HR lines are for those with short attention spans who fail to read code/literature about how bitcoin works simply because 'its too long'

[jonald_fyookball]

BOOM BABY !!!

And there it is !! 


Gavin Andresen: “Run Bitcoin Unlimited” To Solve “Destructive Congestion”

https://cointelegraph.com/news/gavin-andresen-run-bitcoin-unlimited-to-solve-destructive-congestion

Run Bitcoin Unlimited. It is a viable, practical solution to destructive transaction congestion.

and what does he think of Segwit.

He added that Segregated Witness technology was “too little,” offering a block size increase of only two megabytes, which “would get hit before wallets and users adopt.”

 

Gavin rules.   

It really boggles my mind why people are listening to people like Gregory Maxwell over Gavin.
I think taking $71M in venture capital is a far more reliable indicator of a biased agenda
than 1 visit to the CIA.  Call me crazy.



 
 

[Wind_FURY]

Again it is all politics. Gavin started playing the game when he started campaigning for XT. Maybe he thinks he can reenter the scene when the network does the hard fork to Bitcoin Unlimited. All their moves always have a hidden purpose.

If you think about it both sides are doing the power grabbing depending on your point of view. On one side it is Blockstream and on the other it is Roger Ver and the Chinese miners who are supporting Bitcoin Unlimited.

[franky1]

Again it is all politics. Gavin started playing the game when he started campaigning for XT. Maybe he thinks he can reenter the scene when the network does the hard fork to Bitcoin Unlimited. All their moves always have a hidden purpose.

If you think about it both sides are doing the power grabbing depending on your point of view. On one side it is Blockstream and on the other it is Roger Ver

no they're not.

xt, classic, bu and the other dozen nodes want ONE network where everyone is on the same playing field and using consensus.

its only blockstream that have bypassed real consensus by going soft.
its only blockstream that have nodes set up as upstream filters to control what non segwit nodes see/receive
its only blockstream that have played around with its banning and whitelisting protocols.

here is gmaxwell trying his hardest to get those not wanting to follow gmaxwell to split away.. but they laughed at him and refused to split away because that would just give gmaxwell what he wants..

What you are describing is what I and others call a bilateral hardfork-- where both sides reject the other.

I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.

The ethereum hardfork was bilateral, probably the only thing they did right--

READ CODE, read stats,
stop defending the humans

and the Chinese miners who are supporting Bitcoin Unlimited.

X% are with segwit
X% are with BU
X% are with classic
but ~60%.. yep well over 50% are UNDECIDED

so do not classify the 50-60% undecided as being in any camp just to suit some biased brand camp social games

[Kakmakr]

Seeing this i wounder why there is no big support for a third solution. Just buy some time by increasing the Size to 2 or 4 MB and look for a better and more permanent solution.

Because this does not fit Blockstreams agenda to implement the Lightning Network. Their investors wanted them to come up with a long term solution for scaling Bitcoin and not just a temporary patch. A lot of salaries were paid to develop this solution and a lot of pride is involved too.

So in the end, it boils down to money again and not what the people wants.

The miners wants miners fees in the future and they do not think running payment channels off-chain will sustain their business in the future. < money again >