So who the hell is still supporting BU?

[lurker10]

BU is going to win this fight.

Try to guess what happens next!   

Depends on stubbornness of Core devs and if they are willing to redefine what Bitcoin is, namely, the miners hashing sha256 establish the longest chain consensus part of definition.
If Core devs have an agenda to win at any cost, they will create a different hashing algo client, I think LukeJr already did it with Keccak, and Bitcoin will fork into sha256 and Keccak two chains.
If Core devs give up, users will happily continue to use the chain that old good sha256 miners are hashing.
Do you have a different view?

[1714131907]

1714131907

[1714131907]

1714131907

[1714131907]

1714131907

[lurker10]

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.

There are many complaints about high fees and long queue waiting times. The market does give a fuck and miners are going to answer its demands.

[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?

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.

Ok , thx that you stayed on and just w/o any insult.

Try this: If e.g. A stock price tested against a barrier two times, will it hold 3rd for sure?

[Eodguy149]

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.

There are many complaints about high fees and long queue waiting times. The market does give a fuck and miners are going to answer its demands.

In the market there is always a cause and an effect, it will definitely be interesting to see how this all pans out. Something has to give but I'm not entirely sure what it is yet.

[kiklo]

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!  

@iCEBREAKER,

1. Are you suggesting an ENTIRE Coin network block updating to unlimited because YOU claim 1 developer can't update their code to work with BTC unlimited.
Keyword : You Claim,

Because here is what the Electrum Developer said

Voegtlin explained that he has no strong position on the preferred block size limit itself – though he regrets that technical discussion has taken a backseat lately.
“I am not in a position to tell what the best block size is,” Voegtlin said

Plus he has no problem updating electrum for Segwit, which you posers claim can reach ~4 Megabyte block size.
Like the rest of the world update or get left behind.  I have no doubts electrum would be updated to work with BU , in short order.


But guess what in the real world when a Vendor is unable to make a product work, we move to a product that does work.  
http://www.newsbtc.com/2016/10/16/electrum-x-newer-much-faster-variant-electrum-server/

A much faster version of Electrum Server is now available.
The reimplementation of Electrum Server, called Electrum X is the creation of Neil Booth which he claims to be 10 times faster than the Electrum Server.

 

[iCEBREAKER]

Try this: If e.g. A stock price tested against a barrier two times, will it hold 3rd for sure?

Stock prices follow random walks.  Stock prices are not experiments.  They do not support or disprove a hypothesis.

You don't seem to have a clear understanding of how science works.

I can't imagine living in such a dark, demon-haunted world.

I'm truly sorry you never received a proper education.

Here, read this.

https://explorable.com/falsifiability

Let there be light!  



kiklo,

The O(n^2) sigop attack cannot be mitigated with Electrum X or by simply buying a faster Xeon server.

As Gavin said, we need to move to Schnorr sigs to get (sub)linear sig validation time scaling.

And AFAIK moving to Schnorr sigs at minimum requires implementing Core's segwit soft fork.

Informed Bitcoiners like Adam Back and the rest of Core plan to do segwit first, because it pays off technical debt and thus strengthens the foundation necessary to support increased block sizes later.

[hv_]

Try this: If e.g. A stock price tested against a barrier two times, will it hold 3rd for sure?

Stock prices follow random walks.  Stock prices are not experiments.  The do not support or disprove a a hypothesis.

You don't seem to have a clear understanding of how science works.

I can't imagine living in such a dark, demon-haunted world.

I'm truly sorry you never received a proper education.

Here, read this.

https://explorable.com/falsifiability

Let there be light!  



kiklo,

The O(n^2) sigop attack cannot be mitigated with Electrum X or by simply buying a faster Xeon server.

As Gavin said, we need to move to Schnorr sigs to get (sub)linear sig validation time scaling.

And AFAIK moving to Schnorr sigs at minimum requires implementing Core's segwit soft fork.

Informed Bitcoiners like Adam Back and the rest of Core plan to do segwit first, because it pays off technical debt and thus strengthens the foundation necessary to support increased block sizes later.

Let ICi believe in random walks and sience is answer to all issues. He does not even get how to communicate in civilized manner.
Riddle for you: What distribution do you need for your stock market random walk or ( same task) what one is underlying to the real ( not academic ) economics like bitcoin experiment (e.g. acceptance probability)?

[kiklo]

kiklo,

The O(n^2) sigop attack cannot be mitigated with Electrum X or by simply buying a faster Xeon server.

As Gavin said, we need to move to Schnorr sigs to get (sub)linear sig validation time scaling.

And AFAIK moving to Schnorr sigs at minimum requires implementing Core's segwit soft fork.

Informed Bitcoiners like Adam Back and the rest of Core plan to do segwit first, because it pays off technical debt and thus strengthens the foundation necessary to support increased block sizes later.

So you are saying their Developer is not competent enough to find a solution.
I think if the Developer of electrum was actually worried about it , he would have mentioned it when asked point blank on the blocksize issue.
(His biggest issue is he just wants the debate over so he knows which direction the network is going.)

Segwit is not going to happen , the miners are not giving up their livings just so Core can take over BTC with an iron fist.
So unless Core is forcing a fork, they better start looking for other solutions , like BU.
And if they do force a fork , my money is on the Chinese miners crushing them.

 

FYI:
Electrum is 5% to 10% of the BTC users, it is an all volunteer group, they receive no funding.
So neither BTC core or the Miners are really worried about them or their users.

FYI2:
https://www.buybitcoinworldwide.com/wallets/#hot-wallets

[Lauda]

There are many complaints about high fees and long queue waiting times. The market does give a fuck and miners are going to answer its demands.

If you're complaining about TX fees of 15-30 cents, you don't have money to move the market.

In the market there is always a cause and an effect, it will definitely be interesting to see how this all pans out. Something has to give but I'm not entirely sure what it is yet.

This BU stuff has zero relevance to the price.

And AFAIK moving to Schnorr sigs at minimum requires implementing Core's segwit soft fork.

Yes, Segwit would make that upgrade quite easier. I think that is one of the current plans post-Segwit anyways.

[kiklo]

There are many complaints about high fees and long queue waiting times. The market does give a fuck and miners are going to answer its demands.

If you're complaining about TX fees of 15-30 cents, you don't have money to move the market.

Poor people outnumber rich people , they can move to a coin with cheaper TX fees, and that will affect the market.

And AFAIK moving to Schnorr sigs at minimum requires implementing Core's segwit soft fork.

Yes, Segwit would make that upgrade quite easier. I think that is one of the current plans post-Segwit anyways.

Hmm, the fact that segwit will never be activated , just can't get past that furball you call a brain.

 

FYI:
BTC unlimited hit 31.3% , segwit never got over 30%,
Tide has shifted. 

[iCEBREAKER]

The O(n^2) sigop attack cannot be mitigated with Electrum X or by simply buying a faster Xeon server.

As Gavin said, we need to move to Schnorr sigs to get (sub)linear sig validation time scaling.

And AFAIK moving to Schnorr sigs at minimum requires implementing Core's segwit soft fork.

Informed Bitcoiners like Adam Back and the rest of Core plan to do segwit first, because it pays off technical debt and thus strengthens the foundation necessary to support increased block sizes later.

So you are saying their Developer is not competent enough to find a solution.
I think if the Developer of electrum was actually worried about it , he would have mentioned it when asked point blank on the blocksize issue.

Electrum devs cannot change the fact Bitcoin uses Lamport sigs.  As currently implemented, Lamport sig validation scales quadratically with tx size.

Nobody can fix that until we have segwit and may then change to Schnorr sigs.

Source:

[hv_]

The O(n^2) sigop attack cannot be mitigated with Electrum X or by simply buying a faster Xeon server.

As Gavin said, we need to move to Schnorr sigs to get (sub)linear sig validation time scaling.

And AFAIK moving to Schnorr sigs at minimum requires implementing Core's segwit soft fork.

Informed Bitcoiners like Adam Back and the rest of Core plan to do segwit first, because it pays off technical debt and thus strengthens the foundation necessary to support increased block sizes later.

So you are saying their Developer is not competent enough to find a solution.
I think if the Developer of electrum was actually worried about it , he would have mentioned it when asked point blank on the blocksize issue.

Electrum devs cannot change the fact Bitcoin uses Lamport sigs.  As currently implemented, Lamport sig validation scales quadratically with tx size.

Nobody can fix that until we have segwit and may then change to Schnorr sigs.

Source:

Too sad, that science dictates to have SW first and than Schnorr... What a pity!

[Lauda]

Poor people outnumber rich people , they can move to a coin with cheaper TX fees, and that will affect the market.

Economic majority != poor people.

Hmm, the fact that segwit will never be activated , just can't get past that furball you call a brain.

You are a delusional troll. You don't understand the fact that I don't really care whether Bitcoin upgrades to it or not. These TX fees don't have any effect on me, and they wouldn't even in the case of them growing 10-100 fold.

Too sad, that science dictates to have SW first and than Schnorr... What a pity!

If the right people were being listened to, that's the direction in which we would go.

[d5000]

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.

I heard from Luke's BIP. A block size of 300 kB (if I remember right) is far too low for now - I think that would already be a decision in favour of a digital gold without "regular on-chain payment functionality" which I highly doubt it will work.

But the rest of the plan goes into the right direction. Exactly such a BIP (Segwit and then 17% increase every year) would be my preferred way to solve the problem. I would even propose such a BIP myself but would need the support of Bitcoin experts as I'm not a programmer and so nobody would take me seriously

[classicsucks]

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.

There are many complaints about high fees and long queue waiting times. The market does give a fuck and miners are going to answer its demands.

In the market there is always a cause and an effect, it will definitely be interesting to see how this all pans out. Something has to give but I'm not entirely sure what it is yet.

http://moneyandstate.com/the-true-cost-of-bitcoin-transactions/

Erik Voorhees says that TIME and SANITY are the biggest costs to Bitcoin users. Good point, I know I'm frustrated! "Take me away Monero-baby..."

[classicsucks]

*XT gets rekt*
*Classic gets rekt*

*time passes*

Try to guess what happens next!  

This time it's different. This time Core got "rekt". They can keep putting out sh*t releases all they want, it won't change reality.

Keep on putting lipstick on that pig, and put her right in the front of your shop window. Maybe try a bow on her head?

[jbreher]

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").

::sigh:: You sure are persistent in your preening pedantic posturing. And you _still_ have not answered the question, posed thrice. I'll even modify the time for you:

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.,  10 minutes) 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?

[-ck]

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.,  10 minutes) to verify but is otherwise valid;
2) a 'normal' valid block that does not take an inordinate amount of time to verify; and

By the way, as far as I can understand the bitcoind code as I read it (and no doubt I will be corrected if I'm wrong which is fine), this is an attack vector that "choosing between them" is the least of your problems because it cannot process them both concurrently and then decide that (2) has finished long before it has finished processing (1). This means that if a (1) block hits even 1us before the (2), bitcoind will sit there processing it until it has finished before it can process (2). While this is purely a limitation of the software as it currently stands that it cannot process multiple blocks concurrently in a multithreaded fashion due to the coarse grained locking in the software, it doesn't change the fact there is no way to deal with this at present. It would require a drastic rewrite of the existing code to make the locking fine grained enough to do this, or a new piece of software written from the ground up; both of which carry their own risks.

[jbreher]

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.,  10 minutes) 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.

By the way, as far as I can understand the bitcoind code as I read it (and no doubt I will be corrected if I'm wrong which is fine), this is an attack vector that "choosing between them" is the least of your problems because it cannot process them both concurrently and then decide that (2) has finished long before it has finished processing (1). This means that if a (1) block hits even 1us before the (2), bitcoind will sit there processing it until it has finished before it can process (2). While this is purely a limitation of the software as it currently stands that it cannot process multiple blocks concurrently in a multithreaded fashion due to the coarse grained locking in the software, it doesn't change the fact there is no way to deal with this at present. It would require a drastic rewrite of the existing code to make the locking fine grained enough to do this, or a new piece of software written from the ground up; both of which carry their own risks.

I guess the bitcoind devs have never worked with multithreading then*? Such a pity. And such a cutting-edge 1990's technology. If inordinately large signature transactions ever become A Thing, miners employing bitcoind will be bankrupted by smarter miners.

C'est la guerre. To the wiser go the spoils.

*Yes, unnecessarily provocative. But it certainly points out just one more instance where devs are working on the wrong things.

[-ck]

I guess the bitcoind devs have never worked with multithreading then*? Such a pity. And such a cutting-edge 1990's technology. If inordinately large signature transactions ever become A Thing, miners employing bitcoind will be bankrupted by smarter miners.

C'est la guerre. To the wiser go the spoils.

*Yes, unnecessarily provocative. But it certainly points out just one more instance where devs are working on the wrong things.

It is a bit too harsh. While I'm continually frustrated by some of the limitations of the bitcoind client and the lack of emphasis on things that I am concerned about (since mining with it is my personal interest), it does not pay credence to how such code realistically evolves and the difficulties of keeping massive rewrites safely in check while evolving the client in multiple directions. I'm not much of a c++ coder myself so I can't do anything much to help but at least I do understand what's involved in maintaining such a massive project. It is impossible to know what issues will become problematic in the future when first starting a project; they only become apparent as it evolves and need to be tackled in a methodical manner. Emphasis has only been placed on speed of block processing, propagation, and work template generation in recent times and the improvement is already substantial but has a very long way to go. If the client was written from the ground up now with emphasis in those areas, knowing what we already do now know, it would no doubt look very different. Some things, though, are protocol limitations and not the client. Things like the quadratic scaling issue are in the current bitcoin protocol design and no amount of client rewrites without a protocol change will get around that. I'm not arguing for one only. Both need to be addressed.