Gold collapsing. Bitcoin UP.

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
isn't this j. nguyen's area of expertise?
just saw this edit.

of course it is. but that could mean he's honestly trying to do the right thing or honestly trying to do the wrong thing.

again, imho, the BSX blockchain would not be the BSV blockchain because it's the BSX blockchain, no matter that it had the specified block hash.
[doublepost=1558411915][/doublepost]and again, we know the intent of nchain which most of us have already reconciled amongst ourselves, which is to stomp out any easily formed/forked competition using its tech by using legal challenges. so why would they allow such a lenient definition that allows such easy forking/competition?
[doublepost=1558412330,1558411455][/doublepost]finally, I think they should just get rid of all this "BSV open source license" bullshit. who do they think they are, really? there's alot of talk (I've not verified) about current BSV protocol software being pretty closed if anything. MIT is the gold standard, a non profit with a sterling track record. this new licensing scheme is arguably at the same level as a protocol change.

We accepting their arguments for the need for patents is a good enough concession that should allow them to protect BSV and their investment.
 

rocks

Active Member
Sep 24, 2015
586
2,284
again, imho, the BSX blockchain would not be the BSV blockchain because it's the BSX blockchain, no matter that it had the specified block hash.
The text is very clear and does not allow for that interpretation. IANAL but an old friend of mine is who is also pretty senior in the patent law space, I ran this by him today that that was his take away as well. The license is fine.

I think they should just get rid of all this "BSV open source license" bullshit.
@cypherdoc there is a huge benefit to using this license and not the MIT license, Apache 2.0 or anything similar, it explicitly excludes BTC, BCH and all other alt coins. That is huge IMHO, I'm willing to contribute to that effort...
 

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
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.
As someone who's been around OSS for a long time, that's not great in itself.
[doublepost=1558413932,1558413053][/doublepost]@rocks I think there is a problem with that definition. It says "The Bitcoin SV blockchain". "The" implies singular yet under Cypherdoc's scenario, there is more than one blockchain containing that block so you have contradictory writing.

Open source licenses are notoriously hard to write. Which is why there are so few of them and they are revised so infrequently. This may not even count as open source. I'd be interested to hear what the FSF has to say about it.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
IANAL but an old friend of mine is who is also pretty senior in the patent law space, I ran this by him today that that was his take away as well.
that's all well and good but I'd run it by him again specifically using the example I did of an attempted BSV soft fork pre advertised as trying to steal coins that gets preempted by a BSX hard fork (the BCH August 2017 scenario) that "had to change the ticker" meant to stop the coin stealing and compete for market share and price with BSV .
 
Last edited:
  • Like
Reactions: Zarathustra

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
@Richy_T yes, the competitive two blockchain scenario where each has the specified blockhash.
 

rocks

Active Member
Sep 24, 2015
586
2,284
There seems to be concerns on if this applies to the first sentence.
The Bitcoin SV blockchain is defined, for purposes of this license, as the Bitcoin blockchain containing block height #556767 with this hash: 000000000000000001d956714215d96ffc00e0afda4cd0a96c96f8d802b1662b.
Definitions, such as this one, can come in the beginning, middle or end of the license. It's location does not matter, the definition applies throughout the entire document. If you place the definition in the first sentence you get this, which explicitly makes the BSX chain valid under the license, even if it competes with another nChain branch.
2 - The Software, and any software that is derived from the Software or parts thereof,
can only be used on a Bitcoin blockchain containing block height #556767
with this hash: 000000000000000001d956714215d96ffc00e0afda4cd0a96c96f8d802b1662b.
[doublepost=1558418408][/doublepost]
Open source licenses are notoriously hard to write. Which is why there are so few of them and they are revised so infrequently. This may not even count as open source. I'd be interested to hear what the FSF has to say about it.
That is a really good point and is definitely true. To be fair I have not reviewed the rest of the license, and for a lawyer to do so is beyond the scope of a simple ask.

Maybe it would be better to use the MIT or Apache 2.0 license, but add a scoping clause that limits the license to the BSV branch as defined above.

All that said, companies are free to choose whichever license they want for their own work. It's likely this choice was considered and the current license is what the decision was. We can ask for changes, but for now it is a take it or leave it scenario most likely. Everyone will have to make their own decisions on if they are comfortable with it. On the balance I think it is fine.
[doublepost=1558418615][/doublepost]
that's all well and good but I'd run it by him again specifically using the example I did of an attempted BSV soft fork pre advertised as trying to steal coins that gets preempted by a BSX hard fork (the BCH August 2017 scenario) that "had to change the ticker" meant to stop the coin stealing and compete for market share and price with BSV .
That was the scenario I asked about. That said, friend quick review requests are not as legally thorough as paying by the hour console...
[doublepost=1558418616][/doublepost]
@rocks I think there is a problem with that definition. It says "The Bitcoin SV blockchain". "The" implies singular yet under Cypherdoc's scenario, there is more than one blockchain containing that block so you have contradictory writing.
In that definition the singular "the" references the blockchain up to block 556767 with that hash. There is only 1 blockchain that falls into that definition. It is a statement on the singular chain at that point in time. On a go-forward basis a block chain is actually a tree structure and there can be multiple future branches from that singular starting point.

If that wasn't the case, then the definition makes no sense because if there are two competing chains then the singular definition falls apart, and it is the license, not nChain, that gets to choose which is "the" chain. But that's not the way it reads to me.
 
Last edited:

kostialevin

Member
Dec 21, 2015
55
147
"The" implies singular yet under Cypherdoc's scenario, there is more than one blockchain containing that block so you have contradictory writing.
I'm not a lawyer but I would give much more importance to a hash (000000000000000001d956714215d96ffc00e0afda4cd0a96c96f8d802b1662b) than to an article (the).

However I agree with @rocks that this is a better wording:

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


But maybe to call the chain simply "Bitcoin" right now could spread a lot of controversy..

The most important thing remains to lock down the protocol as soon as possible and to gain use, then there will be no problems anymore with licenses.
 
Last edited:

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
@sickpig
The BU client is now outdated and can not participate on the Scaling Test Network (STN).

Tests with 10GB blocks started yesterday, and the upper configuration limit for EB (Excessive Block Size) on the BU client is lower than 10GB because of the data type of the parameter.
 

sickpig

Active Member
Aug 28, 2015
926
2,541
@Norway

The BU client is now outdated and can not participate on the Scaling Test Network (STN).
last time I checked EB was declared as uint64_t which means a max value of 18,446,744,073,709,551,615 bytes which is ~18*10^18. I would say this is enough.

Tests with 10GB blocks started yesterday, and the upper configuration limit for EB (Excessive Block Size) on the BU client is lower than 10GB because of the data type of the parameter.
anyway even assuming that EB max value was lower than 10GB, as soon as AD blocks will be built on top of the chain tip BU will follow. Hence even in this scenario (which is not true), it is just a matter of setting AD as lower as possible (i.e. 0)

Having said that to make a long story short, assuming that 1000000000 is 10GB, it's just a matter of issuing

Code:
bitcoin-cli setexcessiveblock 1000000000 12
and you'll get

Code:
"subversion": "BUCash:1.6.0(EB1000; AD12)/",
 

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
last time I checked EB was declared as uint64_t which means a max value of 18,446,744,073,709,551,615 bytes which is ~18*10^18. I would say this is enough.
@Norway, please use #101 for this.
However, BU does not have a block size hard cap per se, apart from the max value of the integer of the excessive block size. I have just tested it in the BUCash client preferences and it accepts 2,147,483,648 but truncates any larger, so the current maximum in BU is ~2.1GB.

This is massively ahead of the curve and basically doing what Gavin has suggested.
The constraint will not be in block limit at the moment, but max message size.
Thanks, it must have been changed from int32_t since I proposed BUIP101 last year.

Having said that to make a long story short, assuming that 1000000000 is 10GB, it's just a matter of issuing
No, that's just 1 GB in your example. It should be EB10000 to represent 10GB.

Are you going to test BU on STN, or did the last votes change your mind?
[doublepost=1558438842][/doublepost]@shadders
Yes, I guess I read this too quick:
On May 20th, the Scaling Test Network (STN) will see the first impacts of this upgrade. It will increase its maximum acceptable block size to an astounding 10GB, with default produced blocks set to 128MB.
Source: https://coingeek.com/bitcoin-sv-version-0-2-0-takes-the-next-step-towards-unlimited-scaling/

In theory, someone could issue a 9GB block on STN, but I guess no one will do it.

Yet, the max blocksize (EB) is increased to 10GB... :whistle:

I guess we'll have to wait for the conference, he he. See you there!
 
Last edited:

lunar

Well-Known Member
Aug 28, 2015
1,001
4,290
Bitcoin © Granted to Craig Wright as Satoshi Nakamoto

https://coingeek.com/bitcoin-creator-craig-s-wright-satoshi-nakamoto-granted-us-copyright-registrations-for-bitcoin-white-paper-and-code/


• U.S. copyright registration no. TXu 2-136-996, effective date April 11, 2019, for the paper entitled Bitcoin: A Peer-to-Peer Electronic Cash System, with year of completion 2008. The registration recognizes the author as Craig Steven Wright, using the pseudonym Satoshi Nakamoto.

• U.S. copyright registration no. TX-8-708-058, effective date April 13, 2019, for computer program entitled Bitcoin, with year of completion 2009 and date of first publication January 3, 2009. The registration recognizes the author as Craig Steven Wright, using the pseudonym Satoshi Nakamoto. Wright wrote most of version 0.1 of the Bitcoin client software, and the registration covers the portions he authored.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
should be. but goddammit, he should just sign the first 10 blocks to finalize this.
[doublepost=1558443260][/doublepost]92? hot damn.
 
  • Like
Reactions: Norway and bsdtar

79b79aa8

Well-Known Member
Sep 22, 2015
1,031
3,440
> isn't this j. nguyen's area of expertise?
of course it is. but that could mean he's honestly trying to do the right thing or honestly trying to do the wrong thing.
i meant it in the sense that it is his concern to make the language more precise.