So who the hell is still supporting BU?

[franky1]

Nobody said anything about your grammar, and your embarrassing mistakes were more than a typo. After all, nobody deletes their post just because they made a typo.

if all you can do is knit pick someones wording but not the code concept. then read the code concept

[1715012739]

1715012739

[1715012739]

1715012739

[1715012739]

1715012739

[d5000]

Both sides - "big blockers" and "segwitters" - have valid arguments in my opinion.

Segwit = big blocks. They are not opposing sides.

Well, "big blockers" for me are the guys that want to stay on-chain even with microtransactions and want 8 MB or even larger blocks now - and so run Bitcoin Unlimited. Segwit means "bigger blocks than now", but not really big blocks (<4 MB).

So the goal should be to find an agreement (Satoshi Roundtable Consensus 2?) on block size [...]

Simple: Segwit then implement a hard fork for a base block size increase to 1.5 or 2 MB.

Yes, that would be an ideal solution. However I am not aware of an initiative that actually has the goal to convince the miners that are blocking Segwit from that kind of solution. If there is any and there are news about it, I would be glad with you or anybody else providing me a link to it ...

[iCEBREAKER]

The incentives are what they are. Sure some miner can play the role of 'attacker', and include a transaction that takes an inordinate amount of time to validate. My claim is that incentives are aligned to render this a non-problem.

Riddle me this: built off a parent of the same block height, a miner is presented -- at roughly the same time:
1) an aberrant block that takes an inordinate amount of time to verify but is otherwise valid;
2) a 'normal' valid block that does not take an inordinate amount of time to verify; and
3) an invalid block.
Which of these three do you suppose that miner will choose to build the next round atop?

Your question is poorly constructed because you do not define what qualifies as an "inordinate amount of time to verify."

Riddle me this: built off a parent of the same block height, a miner is presented -- at roughly the same time:
1) an aberrant block that takes an inordinate amount of time (e.g.,  hour) to verify but is otherwise valid;
2) a 'normal' valid block that does not take an inordinate amount of time to verify; and
3) an invalid block.
Which of these three do you suppose that miner will choose to build the next round atop in order to maximize profit?

Another poorly constructed question demonstrating you lack the basic background required to pose interesting questions, much less form valid conclusions, on this topic.

If you paid attention during the Grand Schism you'd already know what in the context of 10 minute block targets constitutes an "inordinate amount of time to verify."

Hint: your example is off by more than an order of magnitude.  So your question is not only uninteresting, it's entirely meaningless.

Once again you've shown yourself to be out of your depth.  Once again your fanciful reach has greatly exceeded your dimwitted grasp.  In other words, you are a great fit for Team Unlimite_.   

For the sake of pity charity and the benefit of lurkers I will again spoon feed you like a baby the facts you should already know, given your proven propensity to pontificate.

Miners' decisions depend on their goals, motivations, and levels of expertise, the amount of fees in the blocks, their software/hardware/network configuration/capabilities/limitations, what they expect other miners to do and/or their strategy for attacking other miners (game theory), etc.  For example, a computationally 999.657k hard block construed in order to clean up a bunch of UXTO dust was intentionally mined by F2pool not very long ago.  That functionality would be lost if we used Gavin's artificial 100k/tx limit.

Any more silly questions?   

Are you now ready to  join us here in the real world, where O(n^2) attacks are a problem, or are you going to stick with the wishful thinking, hand-waving, and "Because Mining Incentives!" slogan?

[classicsucks]

...A BUNCH OF DELETED AD HOMENEM ATTACKS ...

Are you now ready to  join us here in the real world, where O(n^2) attacks are a problem, or are you going to stick with the wishful thinking, hand-waving, and "Because Mining Incentives!" slogan?

OFFTOPIC, BUDDY. 

Why don't you go create some 1MB spam transactions on testnet so the adults can continue discussing how we're going to save Bitcoin from being a useless relic of the past?

Malicious transactions are possible on the Bitcoin network. This has been known for years. It's not a valid argument for keeping the blocksize back in the Stone Age.

Returning to the topic at hand, has anyone looked at this chart lately?
https://blockchain.info/charts/transaction-fees?timespan=all&daysAverageString=7

Seven day average of total transaction fees. We're at roughly 120BTC per day in fees right now. That's no small potatoes.

[iCEBREAKER]

Malicious transactions are possible on the Bitcoin network. This has been known for years. It's not a valid argument for keeping the blocksize back in the Stone Age.

Returning to the topic at hand, has anyone looked at this chart lately?
https://blockchain.info/charts/transaction-fees?timespan=all&daysAverageString=7

Seven day average of total transaction fees. We're at roughly 120BTC per day in fees right now. That's no small potatoes.

The threat of malicious transactions is one of many valid reasons to keep max_blocksize compatible with a diffuse/diverse/defensible/resilient (ie decentralized) network.

Gavin explained why, in perfectly clear English.

120BTC per day in fees is great news.

That will help fee markets develop and is a sign Bitcoin is starting to work as it was designed to.

[jbreher]

The incentives are what they are. Sure some miner can play the role of 'attacker', and include a transaction that takes an inordinate amount of time to validate. My claim is that incentives are aligned to render this a non-problem.

Riddle me this: built off a parent of the same block height, a miner is presented -- at roughly the same time:
1) an aberrant block that takes an inordinate amount of time to verify but is otherwise valid;
2) a 'normal' valid block that does not take an inordinate amount of time to verify; and
3) an invalid block.
Which of these three do you suppose that miner will choose to build the next round atop?

Your question is poorly constructed because you do not define what qualifies as an "inordinate amount of time to verify."

Riddle me this: built off a parent of the same block height, a miner is presented -- at roughly the same time:
1) an aberrant block that takes an inordinate amount of time (e.g.,  hour) to verify but is otherwise valid;
2) a 'normal' valid block that does not take an inordinate amount of time to verify; and
3) an invalid block.
Which of these three do you suppose that miner will choose to build the next round atop in order to maximize profit?

Another poorly constructed question demonstrating you lack the basic background required to pose interesting questions, much less form valid conclusions, on this topic.

...

Any more silly questions?   

blah blah blah blah blah

Here's another question, though it be not so silly:

Riddle me this: built off a parent of the same block height, a miner is presented -- at roughly the same time:
1) an aberrant block that takes an inordinate amount of time (e.g.,  hour) to verify but is otherwise valid;
2) a 'normal' valid block that does not take an inordinate amount of time to verify; and
3) an invalid block.
Which of these three do you suppose that miner will choose to build the next round atop in order to maximize profit?

[iCEBREAKER]

an aberrant block that takes an inordinate amount of time (e.g.,  hour) to verify but is otherwise valid

Nobody is going to construct, much less accept and mine on, a block that takes 60 minutes to verify.

You'd already know this if you weren't an ignorant bumbling idiot.

You can't even dog paddle yet, so stay in the kiddie pool and out of the deep end, OK?   

[jbreher]

an aberrant block that takes an inordinate amount of time (e.g.,  hour) to verify but is otherwise valid

Nobody is going to construct, much less accept and mine on, a block that takes 60 minutes to verify.

Exactly. Precisely my point. Now if nobody is going to construct, much less accept and mine on a block that takes 60 minutes to verify, then why are we in a panic over blocks that will take 60 minutes to verify?

As I said, mining incentives are already aligned in order to render the quadratic sig hash time issue a non-problem.

So now that you've correctly identified one of the blocks that will not be built atop, you still have not weighed in with which of the three blocks a rational miner would build atop. Care to guess?

[hv_]

Trying to be mostly neutral and searching for a unifying solution, I see SW supporters running out of convincing arguments and try hiding behind polemic and insult not only here but even in most SW loving forum there is lot of confusion

https://np.reddit.com/r/Bitcoin/comments/5ukz58/segwit_is_a_softfork_to_miners_without_supporting/

+ all efforts to claim SW is THE no brainer solution and needs to be just waived through because core knows better and is fully tested and disclaimer free

+ seeing BU expands adoption (despite not 'fully' tested), SW stalls:

One can only conclude, so far, SW is Not the no brainer and needs either  to be entirely reviewed or abandoned.

[lurker10]

BU is going to win this fight.

[kiklo]

Trying to be mostly neutral and searching for a unifying solution, I see SW supporters running out of convincing arguments and try hiding behind polemic and insult not only here but even in most SW loving forum there is lot of confusion

https://np.reddit.com/r/Bitcoin/comments/5ukz58/segwit_is_a_softfork_to_miners_without_supporting/

+ all efforts to claim SW is THE no brainer solution and needs to be just waived through because core knows better and is fully tested and disclaimer free

+ seeing BU expands adoption (despite not 'fully' tested), SW stalls:

One can only conclude, so far, SW is Not the no brainer and needs either  to be entirely reviewed or abandoned.

Correct a Person Has No Brain if they Want Segwit.  

Segwit Supporter  



 


FYI:
BTC miners will Block Segwit
LTC may not be so lucky,
Charlie Lee claims he can force segwit on them no matter how the miner vote.
http://www.newsbtc.com/2017/02/17/charlie-lee-potentially-enforcing-litecoin-segwit-activation-bitcoiners-concerned/
Also threatening to change their PoW,
https://np.reddit.com/r/Bitcoin/comments/5uf679/charlie_lee_people_dont_realize_what_segwit_is/ddtrbxe/

[iCEBREAKER]

an aberrant block that takes an inordinate amount of time (e.g.,  hour) to verify but is otherwise valid

Nobody is going to construct, much less accept and mine on, a block that takes 60 minutes to verify.

Exactly. Precisely my point. Now if nobody is going to construct, much less accept and mine on a block that takes 60 minutes to verify, then why are we in a panic over blocks that will take 60 minutes to verify?

As I said, mining incentives are already aligned in order to render the quadratic sig hash time issue a non-problem.

So now that you've correctly identified one of the blocks that will not be built atop, you still have not weighed in with which of the three blocks a rational miner would build atop. Care to guess?

No idea why you are babbling about nonsense like 60 minute verification times.  Might as well go full retard red herring and ask what happens if a 60 day or 60 year block happened.

The problem here is you have no idea where the grey area between reasonable and inordinate is, despite having the required knowledge spoon fed to you like a baby ("F2pool's ~1mb tx took 4 min on Electrum server, which would fall behind the network given ~2.5mb tx").

You don't even seem to be aware verification times vary according to the miners' node software and server hardware/network capabilities, nor of the fact such power imbalances may be used maliciously against other miners.  Did you sleep through the discussion about the GFOC?

Miners' decisions depend on their local conditions, counterparty obligations, goals, motivations, and levels of expertise, the amount of fees in the blocks, their software/hardware/network configuration/capabilities/limitations, what they expect other miners to do and/or their strategy for attacking other miners (game theory), etc.

It appears you are committed to remaining somewhere other than here in the real world where O(n^2) attacks are a problem, and going to stick with the wishful thinking, hand-waving, and "Because Mining Incentives!" slogan.

Good luck with that!   

[lurker10]

Price is tracking BU's odds to win. Bitcoin economic majority = market wants BU and on-chain scaling now.

[franky1]

Charlie Lee claims he can force segwit on them no matter how the miner vote.
http://www.newsbtc.com/2017/02/17/charlie-lee-potentially-enforcing-litecoin-segwit-activation-bitcoiners-concerned/

coblee and gmaxwell do have a trick up their sleeve.
its called a bilateral split. commonly known as an intentional altcoin creation.

yep both know that they can cause a bilateral split even in a soft scenario

Of course I would rather we all work together for the best for Litecoin. But the checks and balances that exists within Bitcoin/Litecoin gives users the ability to overrule miners if needed. Most people are not aware of this and think that miners are in control.

 If there is some reason when the users of Bitcoin would rather have it activate at 90% .. then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

yep.. they are willing to cause an intentional altcoin to get segwit activated..even in a soft scenario

yet. if willing to go to the extremes of causing an alt to get what they want. they should have saved 2 years of bickering and just went with a PROPER full node and pool consensus which would not result naturally in an altcoin.
(but with the same stupid chance some numpty might want to push the issue into causing an altcoin, which they now admit is the same for soft)

that way by doing a full node AND pool consensus they could have also included the features the community really wanted in the first place. thus giving the entire network a real confidence of positive movement of onchain scaling.

[iCEBREAKER]

*XT gets rekt*

*time passes*

*Classic gets rekt*

*time passes*

BU is going to win this fight.

Try to guess what happens next!   

[hv_]

*XT gets rekt*

*time passes*

*Classic gets rekt*

*time passes*

BU is going to win this fight.

Try to guess what happens next!  

Yeah. You convinced me again. You find two measurements and extrapolate the future out of this. Great brain!
 

Edit: So we should go long always at the end of every trend?

[Lauda]

Well, "big blockers" for me are the guys that want to stay on-chain even with microtransactions and want 8 MB or even larger blocks now - and so run Bitcoin Unlimited. Segwit means "bigger blocks than now", but not really big blocks (<4 MB).

I consider everything above 1 MB as 'big blocks'. This is due to the narrative of the 'small blockists' (to call them that) who want 1 MB or even less right now (see luke-jr BIP).

Yes, that would be an ideal solution. However I am not aware of an initiative that actually has the goal to convince the miners that are blocking Segwit from that kind of solution. If there is any and there are news about it, I would be glad with you or anybody else providing me a link to it ...

Well, you can't really convince the miners when there isn't a HF proposal that properly does this post-segwit. The only BIP that increases the block size sometime and builds on-top of Segwit is luke-jr's. However, that one does't see any growth until a few years into the future.

Price is tracking BU's odds to win. Bitcoin economic majority = market wants BU and on-chain scaling now.

Bullshit and you know it. The market gives zero fucks about this trashware called BU.

[Eodguy149]

I would love to see everyone come together and focus on a reasonable compromise. So much divisiveness in the world, sad to see that it is reflected in the digital world as well.

[iCEBREAKER]

*XT gets rekt*

*time passes*

*Classic gets rekt*

*time passes*

BU is going to win this fight.

Try to guess what happens next!  

Yeah. You convinced me again. You find two measurements and extrapolate the future out of this. Great brain!
 

Edit: So we should go long always at the end of every trend?

You are confusing "measurements" with the resolutions of the XT and Classic experiments.

Instruments take measurements, experiments test hypotheses.

What an appallingly ignorant display of your lack of basic familiarity with the philosophy of science.

I didn't say anything about "the end of every trend."  My point is obviously specific to the resolution of the Unlimite_ measurement experiment.

Please try to stay focused on the subject at hand and not wander off into lazy universal generalities about what we should or should not "always" do.

[IadixDev]

To me the problem with LN is not LN itself, but that there should be no ambiguity on the fact that it's not the same than bitcoin network. It's more this confusion that i find disturbing, like saying writing data in a cache is "just the same" than writing the data disk but just much faster .. Well no it's not the same thing done faster, it's faster precisely because it doesn't do the thing that take the more time and give all the security to the data.

With LN it's a bit the same confusion saying it's just the same than bitcoin network but faster, or more scalable, yes it's faster, and it can scale processing of off chain transaction, but it's still not the same than the real bitcoin network, and it's faster precisely because it bypass the actual processing of the mining node and the global validation through distributed proof of work. And it doesn't solve anything of the actual bitcoin scaling issue. Just bypass it in condition that are still safe in most case, but the case where it matter should be more clear.

It's not even 'just like a system of cache', because if it was so, it would be totally transparent to all the application using the network, the bitcoin network and LN network should be all the time completely synchronized with each other, even if that involve synchronizing with off chain operation. If there is not 100% certainty that the state in the LN network is 100% synchronized all the time with the onchain data, and that operation in the LN network based on out of date data is invalidated, it's not acting like a simple system of cache. Because it can matter in certain case if the operation is happening inside of the LN network or onchain. The two not exactly equivalent. And there could be a difference between asking the balance of an address on the main network and inside of LN network.

But again i think there is room for LN like things, and i don't think 100% of all use of bitcoin need to happen onchain on a fully synchronized local application, and there is room for off chain things, but need to be no ambiguity that the two are completely different things, LN is not solving the true bitcoin scaling problem, and operations happening inside of LN do not provide the same level of security than true on chain operations, even if they are faster and scale better.

And i'm not sure the developers and team are making such a good job at making this clear, and the case where it can matter if the transaction is happening in LN or onchain. And more trying to make it look like it's the same thing but made faster, but it's faster precisely because it's not doing the same thing and bypass the part that actually take the more time.