Gold collapsing. Bitcoin UP.

[bitsko]

based on that bsv roadmap id like to call for BU devs to help implement parallel block validation on BSV.

what does the BU members think?

 

[_bc]

Two things caught my eye:

"Limited support for the original sighash algorithm to ensure any legacy transaction that have been kept offline become valid on BSV again"

and

"Ancestor limit"

Does anyone know what type of legacy transactions would come back online?

And what would an "ancestor limit" do?

@shadders ?

 

[RollieMe]

> And what would an "ancestor limit" do?

I'm assuming (probably wrongly) that it's the limit set on how many dependencies a tx can have within a single block. ie a tx that spends a tx output that was generated in the same block that spends a tx output generated in the same block etc etc. I think the BTC/BCH limit is around 30 or so from memory - I didn't catch if BSV had alread lifted it previously.

A higher limit would allow more 'powerful' loop unrolling amongst other things - ie more complex scripts using the same basic op codes.

 

[_bc]

Thanks. I hope you're right.

 

[Zarathustra]

New road map out https://bitcoinsv.io/2019/04/17/the-roadmap-to-genesis-part-1/

"We have previously signalled an intent to raise the cap to 512MB however after consultation with the Bitcoin Association (the owner of the Bitcoin SV project) and miners representing a significant majority of hash rate it has been decided that the Bitcoin SV software will implement a default of 2GB in July. "

haters r gunna pop soon.

Renaissance of the Genesis ...

Congratulations @Otaci , @shadders and friends!


I love him who laboureth and inventeth, that he may build the house for the Overman, and prepare for him earth, animal, and plant: for thus seeketh he his own down-going
(...)
I love him who scattereth golden words in advance of his deeds, and always doeth more than he promiseth: for he seeketh his own down-going

Thus spake Zarathustra (short version)

Full version:

Zarathustra, however, looked at the people and wondered. Then he spake thus:

Man is a rope stretched between the animal and the Overman--a rope over an abyss.

A dangerous crossing, a dangerous wayfaring, a dangerous looking-back, a dangerous trembling and halting.

What is great in man is that he is a bridge and not a goal: what is lovable in man is that he is an OVER-GOING and a DOWN-GOING.

I love those that know not how to live except as down-goers, for they are the over-goers.

I love the great despisers, because they are the great adorers, and arrows of longing for the other shore.

I love those who do not first seek a reason beyond the stars for going down and being sacrifices, but sacrifice themselves to the earth, that the earth of the Overman may hereafter arrive.

I love him who liveth in order to know, and seeketh to know in order that the Overman may hereafter live. Thus seeketh he his own down-going.

I love him who laboureth and inventeth, that he may build the house for the Overman, and prepare for him earth, animal, and plant: for thus seeketh he his own down-going.

I love him who loveth his virtue: for virtue is the will to down-going, and an arrow of longing.

I love him who reserveth no share of spirit for himself, but wanteth to be wholly the spirit of his virtue: thus walketh he as spirit over the bridge.

I love him who maketh his virtue his inclination and destiny: thus, for the sake of his virtue, he is willing to live on, or live no more.

I love him who desireth not too many virtues. One virtue is more of a virtue than two, because it is more of a knot for one's destiny to cling to.

I love him whose soul is lavish, who wanteth no thanks and doth not give back: for he always bestoweth, and desireth not to keep for himself.

I love him who is ashamed when the dice fall in his favour, and who then asketh: "Am I a dishonest player?"--for he is willing to succumb.

I love him who scattereth golden words in advance of his deeds, and always doeth more than he promiseth: for he seeketh his own down-going.

I love him who justifieth the future ones, and redeemeth the past ones: for he is willing to succumb through the present ones.

I love him who chasteneth his God, because he loveth his God: for he must succumb through the wrath of his God.

I love him whose soul is deep even in the wounding, and may succumb through a small matter: thus goeth he willingly over the bridge.

I love him whose soul is so overfull that he forgetteth himself, and all things are in him: thus all things become his down-going.

I love him who is of a free spirit and a free heart: thus is his head only the bowels of his heart; his heart, however, causeth his down-going.

I love all who are like heavy drops falling one by one out of the dark cloud that lowereth over man: they herald the coming of the lightning, and succumb as heralds.

Lo, I am a herald of the lightning, and a heavy drop out of the cloud: the lightning, however, is the OVERMAN.--

 

[Norway]

Great work @Otaci & @shadders!

 

[lunar]

 

[Norway]

Unbounded

 

[Zarathustra]

"Hi Mike,
I'm glad to answer any questions you have. If I get time, I ought to write a FAQ to supplement the paper.
There is only one global chain.

The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than thatwith existing hardware for a fraction of the cost. It never really hits a scale ceiling. If you're interested, I can go over the ways it would cope with extreme size. By Moore's Law, we can expect hardware speed to be 10 times faster in 5 years and 100 times faster in 10. Even if Bitcoin grows at crazy adoption rates, I think computer speeds will stay ahead of the number of transactions."

 

[Zangelbert Bingledack]

@Zangelbert Bingledack If we want to be entirely objective, no one here or on reddit seemed to mind massive ad hominem arguments against Bitcoin Core team members, but somehow Craig Wright deserves unbiased treatment now?

You make an excellent point except that it is backwards:

I don't recall a single ad hominem against Core here. We were skeptical of Core's motives, certainly, but most here didn't use that as an excuse to dismiss their arguments out of hand.

Despite our deep mistrust and much rancor we evaluated their every talking point, we understood their worldview in detail, and we refuted it piece by piece in almost every conceivable way in these pages. I think many of us could recite the whole litany of Core talking points in all their shifty variations, even the changes they went through every few months. We could argue their points better than they could themselves. This is the polar opposite of ad hominem.

And this is exactly what hasn't happened with Craig Wright. His writing style, his overall presentation, the set of allegations and enigmas around him, his brash demeanor, his unproven claim of Satoshihood, his many promises and threats, his lawsuits, his tidal wave of patents, his non-cypherpunkish attitude, and the general perception on social media that he's a force for ill has been allowed to pass as an excuse for ignoring his work, dismissing his insights, and refusing to read him in the necessary detail to understand what he is even getting at, let alone to engage with the arguments - let alone to engage with them in detail except a few pieces of low-hanging fruit chosen for the sole purpose of justifying dismissal of all the rest. This is exactly what the fallacy of ad hominem is about.

Ad hominem, especially in such a quintessential and comprehensive form, is a classic sign that tribalism has won out over the pursuit of truth.

I realize his work is voluminous, his points subtle and sometimes complex, his communication style vexing and at times even atrocious (though vastly improved recently), and the expertise needed to evaluate his claims both far broader and far deeper than for Core.

I never said it was easy, but I do say it is necessary for anyone who wants to understand Bitcoin. This is the man who created Bitcoin, and he's far more advanced in his thinking than anyone ever thought his old persona Satoshi was. While I realize it isn't socially kosher to lay it out in such stark terms, at some point we have to ask whether we are here to get to the bottom of matters or not.

With that, while I could critique Craig Wright's weaknesses nearly as strongly, I feel it would be irresponsible not to reaffirm my honest assessment: that no one else is remotely close to the level of detailed thought, classically informed wisdom, far-ranging generalist understanding (that is nonetheless conspicuously Bitcoin-focused), a frankly inhuman level of erudition and devotion to study, and the apparent decades of e-cash and Bitcoin/Metanet-related trial and error, research, simulation, rumination, building, systematization, and real world experience he brings.

While this may sound like high praise, I have my own strengths I'm equally proud of; there are no heroes here, just business. Knowing who to learn from is too important a matter to be left to tribal impulses. Re-read the post; you know it to be true!

 

[rocks]

New road map out https://bitcoinsv.io/2019/04/17/the-roadmap-to-genesis-part-1/

"We have previously signalled an intent to raise the cap to 512MB however after consultation with the Bitcoin Association (the owner of the Bitcoin SV project) and miners representing a significant majority of hash rate it has been decided that the Bitcoin SV software will implement a default of 2GB in July. "

It was pointed out earlier that pruning for full nodes is available. This allows a node that has already caught up to the head of the network to operate from a UTXO set that it has verified and is keeping track of.

However, if a new node is trying to join the network, is it able to catchup to the current block and function if the only blocks available were pruned? My understanding is today that answer is, no.

Note, this isn't just for transaction data. It's possible with really large blocks that most miner and full nodes will drop large OP_RETURN data for cost purposes, or simply because they don't want to pay the network traffic.

In that case new nodes need to be able to join a network using some form of merkel blocks with a mix of available transactions and merkel tree hashes where transactions are not available.

Until the ability for client software to handle this, it does seem risky to enable very large datasets. 2GB blocks is 1PB a year, I know large scale systems, there is a non trival cost to not just storing, but processing and serving that volume of data. It will be pruned by online nodes, which means new nodes need to be able to handle a pruned history.

 

[Bloomie]

This is the man who created Bitcoin

You were doing well until you got to this part

 

[Norway]

It was pointed out earlier that pruning for full nodes is available. This allows a node that has already caught up to the head of the network to operate from a UTXO set that it has verified and is keeping track of.

However, if a new node is trying to join the network, is it able to catchup to the current block and function if the only blocks available were pruned? My understanding is today that answer is, no.

Note, this isn't just for transaction data. It's possible with really large blocks that most miner and full nodes will drop large OP_RETURN data for cost purposes, or simply because they don't want to pay the network traffic.

In that case new nodes need to be able to join a network using some form of merkel blocks with a mix of available transactions and merkel tree hashes where transactions are not available.

Until the ability for client software to handle this, it does seem risky to enable very large datasets. 2GB blocks is 1PB a year, I know large scale systems, there is a non trival cost to not just storing, but processing and serving that volume of data. It will be pruned by online nodes, which means new nodes need to be able to handle a pruned history.

[doublepost=1555540097][/doublepost]

there is a non trival cost to not just storing, but processing and serving that volume of data.

Yes, it's for big businesses. Not for hobbyists.
Datacenter. Not RasPi. Not laptop.

A good friend and co-owner in my company ran the mining pool who mined the first Bitcoin Classic block - on a laptop! When he and his friend discovered how much hashpower their laptop was serving as a pool, they freaked out. The responsibility they had with their shitty infrastructure dawned upon them, lol.

 

[Norway]

You were doing well until you got to this part

Still don't get it. Ok, you'll get it later.

 

[Christoph Bergmann]

@Zangelbert Bingledack If we want to be entirely objective, no one here or on reddit seemed to mind massive ad hominem arguments against Bitcoin Core team members, but somehow Craig Wright deserves unbiased treatment now?

I remember this thread discussing far more about core ideas with blocksize than slandering core devs. Remember the endless discussions with Jonny?

Now, with the csw slander, we are hardly able to discuss big blocks, because this is what bsv is about, and when saying bsv, we say csw, and ...

 

[lunar]

@rocks bit out of my range to answer that, maybe @Otaci?

edit although reading norways post from a non technical perspective, i'd have to agree, This is an economic system, if it's to function, all sectors must be profitable. This is the pact of the greatest economic experiment the world has ever seen. If the service provides value to the whole, then the free market will create.

But the blog does mention.

• Restoration of original OP_RETURN functionality (with a fix for the OP_1 OP_RETURN vulnerability)

Perhaps before my time, but I don't remember any changes. Does anyone know whats the difference to the old functionality?

 

[shadders]

And what would an "ancestor limit" do?

@shadders ?

Be removed.
[doublepost=1555548970,1555548079][/doublepost]

But the blog does mention.

• Restoration of original OP_RETURN functionality (with a fix for the OP_1 OP_RETURN vulnerability)

Perhaps before my time, but I don't remember any changes. Does anyone know whats the difference to the old functionality?

It used to just exit the script and evaluate pass or fail based on what was on the stack. As any other script would. That allowed you to use op_1 op_return in scriptsig which will always allow you spend no matter what is in scriptpubkey. IIRC it was gavin and satoshi that changed to it make op_return always fail the script as a quick bug fix. One solution is to make it illegal in scriptsig but at the time the code didn't treat scriptsig and scriptpubkey as seperate invocations of the script engine. It concatenated them with an op_codeseperator in between and ran both scripts in a single invocation. So the proper fix would have been more complex and error prone.

 

[rocks]

It is interesting to watch the cheering on various platforms over exchanges removing BSV. The only way I think you could view the number of exchanges mattering is if your experiences and vision for Bitcoin was limited to price speculation only, and that you saw no other utility to Bitcoin beyond speculation and trading. If that was true, then yes exchange support would matter and being de-platformed would 'kill' a coin.

This is of course utter nonsense, but to me it further exposes those who do not understand Bitcoin at all. If Bitcoin is to have any value it will be through utility and usage, that has always been the case and SN said so from day one.

In fact, I'd argue that the crypto space as a whole has found zero real world usage so far, and as a result BSV loses nothing by being disconnected from it. It will grow and thrive on its own merits detached from the crypto space or not.

BTW, today you can trade 10 BTC for 1,000 BSV, just saying.

 

[Norway]

@Griffith
Fair warning:
If you don't sort out BUIP113 and BUIP114 so they treat BSV as equal to or better than BCH, I will bring a proposal to drop support for BCH.

 

[Griffith]

@Norway Please actually read the BUIPs in their current form and not just the titles. I know you haven't. Because if you had read them, then you would realize that removing BCH support also removes BSV support because BSV never had a BUIP to officially support it. The BUIP that did this for BCH was BUIP 063. BSV is still considered a BCH HF in the organizations eyes as far as BUIPs are concerned. The current 113 is a vote to elevate it to the same status of BCH. the 114 vote is to remove the HF configs for BSV from the BUCash client. to make the coin "equal" to BCH i would suggest voting yes on 113 since that is exactly what the BUIP does.

if both 113 and 114 pass, two clients will be published, BUCash and another BUBSV (we havent actually named it yet but u get the point). the code is the same except the BUBSV client has BSV configured by default.
if 113 passes and 114 does not, bsv gets its own client as described above and it can also be configured via HF params in the BUCash client.
if both fail then BSV support is removed from the BUCash client and it does not get its own client.