Gold collapsing. Bitcoin UP.

[Norway]

@awemany doesn't agree that the bitcoin miners form a near complete graph. That's probably why he didn't like the IBS concept.

I hope people are aware of how the network is, and that the observer nodes used for science are not describing what happens between miners if they are not well connected themselves.

 

[Peter R]

ah yes, now i remember. the tx throughput was an issue only with ABC, is that it? well then, my apologies and great job.

still though, most of your team members are in favor of keeping the current limit right now. for me, i need to see continuous increases in the limit with each upgrade or a permanent solution to be fully onboard with a certain implementation.

Then let's get this done. I am fine with any of:

• BIP101-like solution (doubling block-size limit automatically every year, for example)
• BIP100/BUIP-055-like solution (miner voting / miner signalling)
• Emergent consensus a la BU
• Dynamic block size limit based on median block size

Maybe nailing down a permanent solution should be the next workshop sponsored by BU.

 

[sickpig]

still though, most of your team members are in favor of keeping the current limit right now. for me, i need to see continuous increases in the limit with each upgrade or a permanent solution to be fully onboard with a certain implementation.

I'm not. For once we could go as up as 64MB or even 128MB now w/o incurring in the problems SV is experiencing.

Having said that what I think would be great to have is something like the idea @imaginary_username's put out there for debate. i.e. something that solve the problem for good.

 

[wrstuv31]

But Bitmain? What is their goal?

They are separating themselves from an actor with a vision threatening to theirs. It looks like they have done the sobering analysis that they don't want to take the risk on building a SHA-256 world money, so they are diversifying while trying to unload on public markets.

It's in SVs best interest to simply let ABC be centralized, the only thing giving ABC a chance at being currency, is the threat of SV which keeps the hashrate around. Why would an over invested holder of 1M ABC want to compete with miners to set the rules that define their primary investment. They want rules that they control. Why would the ABC hierarchy want to mine if they didn't have to? They've already demonstrated they prefer and are willing to rely on private, hard coded solutions to consensus issues.

Of course, devs who have been promised the opportunity to build the ABC network see the changes as justified and proper. May the chain with the best killer apps win!
[doublepost=1542734797][/doublepost]

I haven't seen them behave dishonorably even once.

The honest actor lies in public. Everyone lies, that is inevitable.

 

[cypherdoc]

BIP100/BUIP-055-like solution (miner voting / miner signalling)

if those are anything like BIP9, which failed, i'm not in favor of that. as i thought we worked out long ago in this thread, miner voting can be gamed, as it is costless. the example is BIP66 and the fork created from a "supposed" 95% miner concensus to go foward with it. bottom line was that some miners just lied. along with SPV mining.

 

[AdrianX]

The reason I don't go on and on about Bitmain is because in this conflict (even since the real small blockers) I haven't seen them behave dishonorably even once.

I observed the opposite, BU was a viable implementation before Segwit 2X, BU was a viable option on the day of the BCH fork. BU is still objectively the most viable implementation of the Bitcoin protocol. Bitmain has abandoned much of the research and innovations that have come out of BU.

Bitmain has opted for the same centralized governance model as Core only this time they are the most influential voice in the process. Bitmain has overreached their intentions are now exposed.

@freetrader I'm disappointed. Bitmain has expressed exactly how dishonest they are.

The way voting in bitcoin works is similar to a democracy. Only it's 1 hash cycle 1 Vote, you need to vote before the election, not after it.

ABC's proposal was put forward with an activation date and a bunch of BTC miners about 70% of them voted against it. (a bunch of investors too, and, in fact, about 90% of BU member if I count the votes against CTOR as a vote against CTOR.

The ABC cult, right up to the election closed, accused the voting miners of attacking BCH. What nonsense.

Sound money is money everyone can use, and an attack is changing rules that undermine that vision. (neither the ABC or the SV proposal was an attack.)

After the vote, some outside authority stepped in to force the ABC rule set. Whoever is in control of forcing that outcome crossed the line and caused the split. They are incompetent leaders.

 

[wrstuv31]

I'm sure all the abandoned BU innovations will be available on the ABC chain in well under 18 months.

 

[AdrianX]

I do agree that it's cool to see them produce these big blocks. The network is quite robust, even when nodes are dog slow and under extreme stress like they are now (reports are that the 64 MB block took ~30 min to propagate).

It's a false prize. They seem incompetent to me if they are not using something like graphene or Xthin and they have not employes the optimizations @theZerg and other BU developers have made, they are just showing off how fast their internet connection and computers are.

Scaling happens when you fear not being able to extend the Chain Tip, having no limit is the risk and a threat of being left behind. Growth and scaling is driven by the risk-reward value judgment you need to make as a business to remain competitive. @deadalnix, when he explains why you need a limit, is ignorant of how BU solved the problem.

Here is the solution to the problem, https://www.bitcoinunlimited.info/technologies/parallel-validation.

@deadalnix @freetrader the solution is not to add the block size to the block headers and
Merkle tree roots smart talk.

nChain I think are just as incompetent as ABC I think if @Peter R test efforts were running on the hardware and internet connection the SV miners are using it would perform orders of magnitude better. as far as I can tell SV are not using any "compression" like Graphene and I hate that word "compression" as nothing is being compressed it's just the word people use to say to imply not relaying the same transaction twice.

Miners are not compressing anything when they send a transaction once. and you are being 50% less efficient when you send it twice.

@sickpig thanks for all your work too, you are an unsung hero in this momentous effort. can you tell is SV is using compression technology or are those 0.1 type blocks resending transactions?
[doublepost=1542739140,1542738518][/doublepost]

I'm sure all the abandoned BU innovations will be available on the ABC chain in well under 18 months.

I'm not. they focust on building a stadium fisr and filling

Someone else made this analogy already elsewhere , but it's like saying "I'm going to test my shotgun by going to this mall and shooting people."

If you bring a shotgun to the mall for "testing", don't be surprised if a SWAT team takes your ass out.

It's not a shotgun you've taken the metaphor too far, it's a fee paying transaction using a sound money network.

 

[freetrader]

BU was a viable implementation before [...]

As far as the miners willing to put money on the line were concerned, BU was not a viable implementation as the only client for a fork to break the 1MB limit.

 

[AdrianX]

Dynamic block size limit based on median block size

this is potentially bad, why BIP101 and this? I think a Dynamic block size limit based on median block size if it is for the last 3 blocks would prevent a poison block attack, But more practically I think ABC should implement parallel block validation it is more effective at neutralizing poison block attacks.

I don't think it is block size that will be used in a poison block attack but hard to validate transactions are the poison. (we should incentivize miners to charge for them)

If I was to take @imaginary_username idea and improve on it, I would rather see Dynamic block validation time limit based on median block validation times, or something like that, where the time to validate the last block you mind is published in the next block you mined. (obviously, the idea as is and needs to be flushed out as its susceptible to cheating)

I think BIP101 with an aggressive skedule (akin to a projection of moore's law is adequate)
[doublepost=1542740833,1542740046][/doublepost]

if those are anything like BIP9, which failed, i'm not in favor of that. as i thought we worked out long ago in this thread, miner voting can be gamed, as it is costless. the example is BIP66 and the fork created from a "supposed" 95% miner concensus to go foward with it. bottom line was that some miners just lied. along with SPV mining.

@cypherdoc BUIP135 and a market where investors who benefit from the change can bid up the future price of the coin, and investors who don't want it can bid up the future price of not adding it. Results in investor led changes that create value, small pet projects are not enabled sacrificing actual growth for technical growth can be assessed by the market before a centralized development team decides what's best and forces the change.

Developers should be at the bottom of the value creation pyramid they should prove themselves on merit, not their incumbent position. The smart ones should build ideas that create value and then benefit if they make good choices not see themselves as bitcoin protocol changers developers.

The past problems can be improved on, we don't need to keep trying other things we can work with the knowledge we have got from past failures.
[doublepost=1542741124][/doublepost]

As far as the miners willing to put money on the line were concerned, BU was not a viable implementation as the only client for a fork to break the 1MB limit.

False dichotomy, make Bitcoin better by improving the better implementation. No need to troll BU while you work on ABC. BU was winning the 1MB war.

 

[cypherdoc]

the Multicoining BTC miners can't seem to decide whether they want profit or ideology. what a dilemma:

https://cash.coin.dance/blocks/hashrate
[doublepost=1542742518][/doublepost]

the Multicoining BTC miners can't seem to decide whether they want profit or ideology. what a dilemma:

https://cash.coin.dance/blocks/hashrate

or, given the across the board price plummets, lose less money or lotsa money. not good for the IPO.

 

[BldSwtTrs]

Is BTC price reacting to the fact that SV has more hashrate than ABC?

 

[lunar]

First of many.

https://www.sec.gov/news/press-release/2018-185


"FOR IMMEDIATE RELEASE
2018-18-5

The Securities and Exchange Commission today announced that TokenLot LLC, a self-described “ICO Superstore,” and its owners will settle charges that they acted as unregistered broker-dealers. This is the SEC’s first case charging unregistered broker-dealers for selling digital tokens after the SEC issued The DAO Report in 2017 cautioning that those who offer and sell digital securities must comply with the federal securities laws.
.......
Without admitting or denying the SEC’s findings, TokenLot, Kugel, and Lewitt consented to the SEC’s order and agreed to pay $471,000 in disgorgement plus $7,929 in interest, and they will retain an independent third party to destroy TokenLot’s remaining inventory of digital assets. Kugel and Lewitt also agreed to pay penalties of $45,000 each and agreed to industry and penny stock bars and an investment company prohibition with the right to reapply after three years."

 

[79b79aa8]

@freetrader, in political and also in economic life, it often happens that not only is interference counted as a negative, but also merely the potential for interference.

for example, the problem with a benevolent dictator is not that he actually represses you (let's say he doesn't). it's that he could, if he changed his mind.

similarly, the (or a) problem with the open market committee is not that it actually inflates the monetary base by 10% p.a. (let's say it doesn't). it's that it could, if its members changed their mind.

the fundamental premise of bitcoin's game theory -- that bitcoin cannot depend on any one actor -- is being violated in all of its live chains. perhaps least on the BTC chain. or perhaps the system has to always be considered as a whole.

 

[solex]

Firstly, @theZerg, @Peter R, @Peter Tschipper and I set up the Gigablock Testnet, a geographically distributed actual network of nodes based on BU (8 miners and 12 transactions generators) and proved we can achieve 1GB block in size even if not in a sustained fashion.

We go through all the software bottleneck we found and remove it one by one. The most significant was the one that was limiting transactions admission to the mempool to a mere 100 transactions per second.

All that improvements have been ported to the BU code base, others are in the pipeline and we are testing it.

So we do think 64MB blocks are possible. We do think that 1GB are possible. More to the point we produced 1GB block. So saying that "no one thought" it was possible is plain wrong.

I'm not going to "like" @sickpig's post. I'm going to quote it as it is the most important post here in days of argument. No team in the world has done more than BU for blockchain scaling!

BU's developers have found and solved bottlenecks which other teams don't even know exist. The BU code has had parallel block validation for 2 years, yet this is still missing from ABC and SV.
It is great that SV pushed a proxy Core client to its limit and found where performance tails off on a main-net, in real-world conditions.
Their result meshes with what the BU devs have known theoretically for a long time.

Further, just because they are publically aggressive about high capacity scaling, it does not mean BU is any less committed also.

 

[cypherdoc]

Is BTC price reacting to the fact that SV has more hashrate than ABC?

if SV wins, then suddenly BTC may have a problem.

 

[BldSwtTrs]

I agree but I find surprising that the whole market understand this. To me it should be a realization just for the happy fews for now.

 

[sgbett]

Andrew's and Bitcoin Unlimited's CDS working for sound money (BCH):

https://old.reddit.com/r/btc/comments/9yrwk0/zero_conf_forfeits_zcf_on_electron_cash_pull/

Wouldn't this be the first realisation of using OP_CDS to destroy the notion of miners as common carriers? In this model now miners are responsible for policing double spends - for deciding intent and metering the punishment?

Seems a start move away from 0-conf being secure as a function of tx-value / merchant risk.

Most of all though, this really seems screwed up:

"In this scheme, the idea is that the security deposit money can be spent by a miner"

So ... if a merchant is successfully double spent... a miner gets paid?

 

[Jonathan Vaage]

I'm getting a little tired if waiting. Please let me know if anyone in here has an interest in some OTC trading given the lack of options from the exchanges. I'm thinking only pre-fork coins split exclusively with post-fork coinbase (no new opcode taint). I have some BCHABC coinbase from BTC.com to share for this purpose. Offering 1 BCHABC for 5 BCHSV. Any takers?

Edit: ticker typo

 

[satoshis_sockpuppet]

Maybe nailing down a permanent solution should be the next workshop sponsored by BU.

Imho nailing down a permanent solution should be done ASAP. I think the miners and devs are still underestimating the effect of a fixed blocksize for builders and investors.
After years of fighting against core, people have a lot of distrust for "we will change it sometime". (Seen in this thread a lot by SV proponents).