Gold collapsing. Bitcoin UP.

[torusJKL]

Imagine with me folks, for one second, a world in which the status of mempool congestion is delivered to the public alongside the local weather.

I hope we will never see mempool congestion anymore on BSV.

 

[Zarathustra]

> This upgrade will launch a whole new mining API, originally designed by Andrew Stone and Johan van der Hoeven, and collaboratively updated with the BSV Node team.

This is good news! I remember reading about this API earlier. It really is a significant improvement from the original getblocktemplate/submitblock.

Congratulation @theZerg ! BSV appreciates your work!
@Otaci - @shadders - @theZerg would be my dream (lead development) team ...

 

[Richy_T]

Try to look at the whole picture and reconsider this theory. Your money is on the line here.

It's the big picture I'm concerned about. But BSV is so cheap that I have no issues keeping hold of what I already have.

 

[rocks]

I see no risks for the future.. and with a fixed protocol who cares about the licence of a particular implementation?

https://github.com/bitcoin-sv/bitcoin-sv/blob/master/LICENSE

That license as written (IANAL) does appear to allow for BSV forks on a go forward basis, but does not allow for either: a) prior forks from the genesis block (BTC/BCH) and b) all alt chains deriving from a different genesis blocks.

If that license remains then this seems fine. The question is if there is a risk of it being changed. There is precedent for this for other projects that were OSS but later moved to closed source. A good example is Open Solaris and ZFS, Sun opened them to OSS but Oracle latter moved to closed source. The process is everything prior to the license change remains OSS, and only new additions are considered proprietary. It is why we have a thriving zfs ecosystem today, which btw is not compatible with Oracle's zfs.

So I'm fine with it. I can see why everyone else in the crypto space wouldn't, but they choose broken chains that do not follow Satoshi's vision.

 

[cypherdoc]

I believe the intention of the Open BSV license is to prevent competing chains like BCH and BTC from using their technology.

that's the "stated" intention. I worry about the unstated intention. we have to plan for worst case scenario.

I haven't read the Open BSV license,

the part @kostialevin posted above makes me even more worried. based on that, any slight bsv generated v. 0.1/0.2 modifications to the protocol to facilitate removing the limit or invoking new opcodes would be protected under the new bsv open license.

So then, in the BSV split again scenario, both branches could run the software in compliance with the licensing.

if you split to another chain, you're going to have to create a new ticker. the original chain could then argue in court you're violating the BSV license.
[doublepost=1558380780][/doublepost]imo, this whole new bsv open source license thing is totally unnecessary for purity of motive. nchain should be able to defend its innovations and the BSV chain via its patents and patents alone.

 

[satoshis_sockpuppet]

Is there a reason for writing '"Bitcoin blockchain" with block x at height n' instead of 'the blockchain with genesis block y with block x at height n'?

 

[rocks]

Despite the whining over lack of ARM support, shadders response is spot on. This is how real successful startups operate, you focus on how your product is being used and invest in making that better. It is amazing that others in the crypto space do not understand that and instead focus on their own interests over the market's

 

[cypherdoc]

why should the Bitcoin community allow a for profit nChain to administer the open source license when the non profit MIT was doing a perfectly good job of it?

 

[shadders]

You don't have to... Anyone can fork the code... The restriction is retrospective. It does not apply going forward.

 

[rocks]

Is there a reason for writing '"Bitcoin blockchain" with block x at height n' instead of 'the blockchain with genesis block y with block x at height n'?

The difference probably does not matter, but that does seem to be the most accurate way to specify it.

 

[sgbett]

FWIW, I read it as ostensibly ensuring scaling cannot be back ported to BCH, BTC etc impossible to know if there is any nefarious future intention or not. I'd assume good faith until proven otherwise.

 

[rocks]

You don't have to... Anyone can fork the code... The restriction is retrospective. It does not apply going forward.

The history on this is @cypherdoc was the first to raise the alarm on Blocksteam back in 2014 (or maybe even 2013) and the conflict of interests that this created. At the time everyone assumed what is essentially BSV's current roadmap and everyone assumed there was full consensus on scaling and adding functionality back in (opcodes, usage).

No one's worst case scenario assumed what ended up happening. If you go to bitcointalk or reddit (uncensored history) the consensus was clear, and no one thought this could happen. But cypherdoc correctly raised warnings, and those concerns were proven right.

I tend to be optimistic and assume the best in other actors. That has bitten me more than once both in life and investments. My read on the license says there isn't a problem given the way it is written, but cypherdoc's inclination to be careful is valid given the history here. None of this is a statement on nChain, just the history of the space in general.

 

[cypherdoc]

You don't have to... Anyone can fork the code... The restriction is retrospective. It does not apply going forward.

if part of the BSV community hard forks away due to some rogue move by you and nchain, they're going to have to use a new ticker symbol on exchanges. that means you have an identical, let's say BSX chain, trying to bootstrap with the exact same source code minus the rogue change. this new chain by definition isn't functioning under the license, afaict.

 

[sgbett]

I'm not trying to defend anyone here but the "contains block X with hash Y" seems fairly robust to me. I have a history of being the eternal optimist though, so I'm quite comfortable accepting your concerns as also valid in a worst case scenario I'd certainly want to pursue "Bitcoin" not "BSV" per se

 

[79b79aa8]

so software developed under the OpenBSV license is open for BSV or anything that forks it (any blockchain containing the genesis, exodus, and leviticus blocks), adressing @cypherdoc's first concern about getting locked in with BSV and forfeiting all governance.

imo, this whole new bsv open source license thing is totally unnecessary for purity of motive. nchain should be able to defend its innovations and the BSV chain via its patents and patents alone.

they are not just defending their innovations, but acting out their stated maximalism. this is to be expected and consistent with the vision of many.

negative consequences will be that devs that do not share that maximalism will refuse to develop for BSV. that's a brain drain, but not an enormous price to may when your model is to set the strategy and hire devs to carry it out, rather than let volunteer devs set the strategy. the move is also asymmetric, they can take from others but those others can't take from them -- thank you and piss off.

 

[cypherdoc]

@79b79aa8

IANAL but how does your statement here... :

>so software developed under the OpenBSV license is open for BSV or anything that forks it (any blockchain containing the genesis, exodus, and leviticus blocks), adressing @cypherdoc's first concern about getting locked in with BSV and forfeiting all governance.

...jive with a hypothetical BSX chain that forks from BSV 10y from now? to be clear, BSX would certainly not be the BSV blockchain. in fact , they would be in competition:

>The Software, and any software that is derived from the Software or parts thereof,
**can only be used on the Bitcoin SV blockchain**.
[doublepost=1558409417,1558408649][/doublepost]I think there are different scenarios we should examine but let's first address the one where BSV wants to soft fork in coin stealing from old addresses and a hypothetical BSX chain (sorry if there's some altcoin out there already with that ticker) needs to hard fork off ahead of the soft fork similar to what BCH had to do from core in 2017.

 

[79b79aa8]

"The Bitcoin SV blockchain is defined, for purposes of this license, as the Bitcoin blockchain containing block height #556767 with this hash: 000000000000000001d956714215d96ffc00e0afda4cd0a96c96f8d802b1662b."

IANAL either, but according to that definition, BSX would be part of the Bitcoin SV chain. as already pointed out, the definition could certainly have been worded more carefully.

isn't this j. nguyen's area of expertise?

 

[cypherdoc]

I honestly don't think so. the first sentence of Part 2 supercedes the second sentence.
[doublepost=1558410864][/doublepost]and if you think about it, the whole purpose of this license is to prevent competition with a different ticker from so easily arising.
[doublepost=1558411051][/doublepost]I'm not accusing them of being nefarious here but I think they need to clarify the wording as I tend to be overly cautious. or just plain wrong.

 

[79b79aa8]

i would say the definition takes precedence. but that comes from being used to read formal work, not legalese.

@Otaci (since you uploaded the license to the github repo) is there any chance the language could be made more precise?

 

[rocks]

2 - The Software, and any software that is derived from the Software or parts thereof,
can only be used on the Bitcoin SV blockchain. The Bitcoin SV blockchain is defined,
for purposes of this license, as the Bitcoin blockchain containing block height #556767
with this hash: 000000000000000001d956714215d96ffc00e0afda4cd0a96c96f8d802b1662b.

To me the text is very clear with no ambiguity. The license is only for the "Bitcoin SV blockchain". The "Bitcoin BV blockchain" is define as any chain that incorporates block 556767 above. Every BSV fork from this point forward will have this block and be covered by the license, essentially the entire "tree" of forks post block 556767 is covered. This includes your BSX fork.

@cypherdoc I understand the concern, but think you are reading this wrong.

The only risk is if in the future the license is changed, if that is done all SW up to that point remains under the existing license and remains open. Only new SW additions after the license change would be effected, again look at the ZFS example above.

Since to me that is the biggest risk, if the intention is to never change the license it might make people more comfortable to add a perpetuity clause...