Gold collapsing. Bitcoin UP.

[theZerg]

Expedited xthin does not use a bloom filter. The sender assumes that the receiver has all the tx that it has (because its has presumably been sending these tx to it).

 

[Norway]

IBS synchronize a block definition from one node to other nodes in increments while mining. When a block is found, all that is needed to send is the block header, the coinbase transaction and the transaction count. This is a tiny and constant amount of data, independent of the block size. It's nothing like Expedited Xthin.

Please don't try to paint IBS as a small tweak of previous BU inventions.

 

[theZerg]

I get that you are proud of your invention.

I was dismayed to discover that blockstream's liquid had a similar opcode to OP_DSV.

I'm sure Leibnitz and Newton were similarly discomfited.

I'm making no claims that you started with xthin and modified it. But the reality is that your post and mine say exactly the same thing technically -- expedited xthin passes one additional chunk of data (the short hashes of the tx in a block) when the block is found.

Realizing that since BSV confirms all transactions, a lot of data can be dropped is a good innovation! I hope you can let the ego go and think about my suggestions above on how to make IBS better.

Also, look at the block forwarding (after the first hop) problem...

 

[Norway]

@theZerg

I was dismayed to discover that blockstream's liquid had a similar opcode to OP_DSV.

This situation is different. IBS sends the block definition in advance, before the block is found. Please stop trying to paint this as a small tweak of previous BU inventions. The fact that Liquid had a similar opcode to OP_DSV does not change anything.

I'm making no claims that you started with xthin and modified it.

And I'm not making claims that you claim this. I'm reacting to your language that indicate that IBS is a small change from Expedited Xthin, while it's a radical new way of communicating a block definition, removing block propagation time regardless of block size.

I hope you can let the ego go and think about my suggestions above on how to make IBS better.

I hope you can let your own ego go, and not try to take credit when someone else invent something new.

Also, look at the block forwarding (after the first hop) problem...

Page 1, paragraph 4 in the IBS paper:
"IBS is not a block relay method, where a block is transmitted via several hops. Block relay
will still be needed occasionally."
I'll ask you if I need your input on what I should spend my time on. You can ask me to do the same for you. So I will not tell you to find a way to scale BCH with CTOR unless you want me to.

(Sorry for the harsh tone, but I'm very pissed off by the direction BU has taken lately.)

 

[theZerg]

You've been essentially asking for input and discussion on IBS so I read it.

Did you read the paper on IBS?

And here you hijacked a different discussion to directly make me aware of IBS:

What is awkward is that you don't pick up on the IBS tech...

FYI, "Weak blocks"/"subchains" protocols uses a similar append-only strategy... and the technique of sending parts of the whole as they are ready is common enough in telecom that it has its own name.

> (Sorry for the harsh tone, but I'm very pissed off by the direction BU has taken lately.)

This is not an acceptable excuse. If you cannot rise above your petty tribalism to have a rational discussion about the technical merits of your protocol, your protocol will not be as strong as it could be.

And you are behaving exactly like BTC and BCH devs by excluding and dismissing constructive criticism due to your emotional and time investment in the work you've already accomplished and your personal feelings about the people or group giving the criticism.

 

[Norway]

And here you hijacked a different discussion to directly make me aware of IBS:

You assumed that we did not know that the Bitcoin SV node currently doesn't order transactions as the miner see them and called it awkward. While you were the one behind the curve in the conversation as the premise was Bitcoin SV's future IBS-tech. And you didn't pick up on IBS november last year. Awkward.

FYI, "Weak blocks"/"subchains" protocols uses a similar append-only strategy... and the technique of sending parts of the whole as they are ready is common enough in telecom that it has its own name.

You're pointing at the nuts and bolts of a new car, and say it's old because nuts and bolts are not new. You are exposing a clear case of Not Invented Here syndrome. IBS is not a pre-consensus idea like Weak Blocks/Subchains, changing the protocol and the economics. IBS was designed to follow the white paper and consensus rules.

This is not an acceptable excuse.

Fine, I take it back. It was your arrogance that pissed me off.

If you cannot rise above your petty tribalism to have a rational discussion about the technical merits of your protocol, your protocol will not be as strong as it could be.

Here's some news for you: A frozen protocol does not depend on social bonding and alliances like the BCH protocol do. Because you fight for dev power in BCH. It's a shit show. How the IBS concept develops on BSV is in practice out of my hands. But if a shitcoin should try to implement it, I would seek legal advice and see if I have a legal way to stop it.

And you are behaving exactly like BTC and BCH devs by excluding and dismissing constructive criticism due to your emotional and time investment in the work you've already accomplished and your personal feelings about the people or group giving the criticism.

What triggers me, is your attempt to downplay the innovation of IBS and take credit for it as a variant of previous BU inventions. I don't need that NIH attitude.

 

[trinoxol]

The truth is that there are very few dependent transactions in blocks. I believe I ran the stats once and it was almost vanishingly small. So it becomes a fine method to simply defer processing any transactions which can't be immediately validated.

What I meant to say is that the data structure that is the body of the block can only be deserialized by a single thread. This has nothing to do with dependencies between transactions. The mere act of parsing the bytes is sequential irrespective of any follow up processing.

Regarding dependencies, maybe there is a risk of someone creating very long dependency chains as an attack. A two-pass algorithm over all transactions is enough to deal with any dependency chain length, though. In the first pass, you collect all the transaction hashes (the TxID). In the second pass, you can then validate all inputs. You check the inputs against the UTXO set of the previous block and also against the newly gathered TxIDs.

 

[theZerg]

@Norway, Xthin came from Mike Hearn's thin blocks. Subchains is a formal treatment of "weak blocks" (I forget who invented), and "weak blocks" are a new application of mining "shares". So I am not trying to claim your invention is anything that BU invented since we didn't invent its antecedents. "Cut through switching" has been around for decades, and the Cornell "falcon" propagation network applied it to bitcoin blocks.

If you can't see how your invention builds upon other people's ideas, fitting within a family of algorithms, all I can say is as a dev you have become what you've spent years criticizing.

 

[Christoph Bergmann]

Amazing how this thread entertains deep technical discussions, after all, and now two in parallel. Always something to learn from you guys.

About dependent transactions. They are rare when it's about money, coins usually sit more than 10 min in a wallet before moving again. But with metanet things, creating dependent schemes of data transactions, they are very common.

 

[Norway]

@theZerg
IBS removes the whole issue of block propagation time with big blocks. You fail to see the significance of this now, and you have failed to see it for 8 months.

When someone tries to belittle your work, you have to address it immediately. If you don't, they will keep pushing you down.

 

[Richy_T]

What I meant to say is that the data structure that is the body of the block can only be deserialized by a single thread. This has nothing to do with dependencies between transactions. The mere act of parsing the bytes is sequential irrespective of any follow up processing.

Sorry, yes, this is true enough. It is slightly annoying that it is done this way from a convenience point of view but in truth, it's pretty a lightweight part of the process to handle this.

Edit: I think some of the block compression schemes will ameliorate this somewhat anyway since the transactions will mostly already be received and validated. (for new blocks anyway. For historical blocks, you're perfectly correct, I think).

Regarding dependencies, maybe there is a risk of someone creating very long dependency chains as an attack. A two-pass algorithm over all transactions is enough to deal with any dependency chain length, though. In the first pass, you collect all the transaction hashes (the TxID). In the second pass, you can then validate all inputs. You check the inputs against the UTXO set of the previous block and also against the newly gathered TxIDs.

Yes. Though I think I saw somewhere that there is a limit on the length of these dependency chains. I did once suggest that it might have been better to have not allowed any dependency chains and only allowed spending from confirmed blocks but didn't get much agreement and it's water under the bridge anyway.

In fact, your two-passes may even be that the first pass is done by the non-parallel deserialization and then the second pass is handled by the parallel validation code.

 

[cypherdoc]

Gold collapsing, Bitcoin UP:

https://www.trustnodes.com/2019/07/21/bulgarias-bitcoin-holdings-surpass-their-gold-reserves

 

[cypherdoc]

0.57 going over the top

 

[cypherdoc]

this really is amazing esp given all the r/bitcoin hate. they don't deserve CB:

[doublepost=1563880327][/doublepost]I'm outta the prediction business but it really looks to me like bsv is getting ready to launch over the last previous high here and on the coinex ratio coincident with the 2G upgrade :

 

[freetrader]

the fiat system which has at least brought to us a certain level of prosperity over the last hundred years and actually doesn't limit the number of people who can use the dollar system tx wise if you're legitimate ?

So I suppose you're alright censoring a whole bunch of economic activity because you or your friends in the USgov get to decide they're "illegitimate".

Thanks for stepping out of the shadows, you censorship endorsing statist.

 

[Zarathustra]

O brethren ...


> you censorship endorsing statist.

You not only endorsed to censor Norway, you campaigned for such subterranean activism.
#georgeorwell #liberty #truth #

 

[cypherdoc]

leave it to the Bitcoin saboteur @freetrader to take my comment out of context and miss the point entirely. yes @freetrader, you're one of the child apparatchiks/anarchists I'm referring to. you're also the one and only dev I've known who insists on maintaining his anonymity after having split the community. i was missing using you as my doormat, you authoritarian endorsing statist :

This limit also sends a huge message to the market that ABC code is run by a technical community that wants to maintain control. reference the comments made by @jtoomim when he flat out says the limit "will not be lifted until we say so". do you really want childlike technical apparatchiks/anarchists like this running your monetary system vs what we currently have with the fiat system which has at least brought to us a certain level of prosperity over the last hundred years and actually doesn't limit the number of people who can use the dollar system tx wise if you're legitimate ? note the difference ; expecting adoption on a coin with a limit can result in preventing even legitimate actors from participating due to limited tx throughput.

[doublepost=1563890108][/doublepost]

O brethren ...


> you censorship endorsing statist.

You not only endorsed to censor Norway, you campaigned for such subterranean activism.
#georgeorwell #liberty #truth #

correction, he endorsed censoring the entire BU non technical community; however the hell you define that.

 

[freetrader]

i was missing using you as my doormat

Only confirms the dirt on your shoes.

you're also the one and only dev I've known who insists on maintaining his anonymity

This bothers you a great deal more than it should an ordinary person.

you authoritarian endorsing statist

Poor projection. You literally advocate authority to censor "illegitimate" transactions.

You not only endorsed to censor Norway

I did not. I put forward a BUIP to remove him from BU membership.
That is not censorship, he can talk as much shit as he wants, but BU has Articles of Federation and its members are expected to abide by them.
Hypocrites like @Zarathustra and @cypherdoc would want us to ignore these rules even while advocating the present system of corrupt rulers that wants to decide for us which transactions are "legitimate".

he endorsed censoring the entire BU non technical community

I never did that, and of course you will fail to provide any evidence for your claim, since it is a lie - one of countless. Once you go down that road, you have to keep on lying. Take inspiration from your frontman.

 

[cypherdoc]

>Only confirms the dirt on your shoes.

and the dirt on your hands, you anonymous saboteur.

>This bothers you a great deal more than it should an ordinary person.

i've articulated in great depth the reasoning behind my suspicions of you. here, we have another example. your normally decent reading comprehension gets purposefully thrown out the window in misrepresenting my comparison of an unlimited fiat system to what you've done to BCH. i only used the example of "legitimate" actors in the fiat space b/c in that system, it's quite clear they are "unlimited" tx wise to make profit. whereas in BCH, with your 32MB limit, even legitimate actors get cut off by the limited blocksize space. we've seen this in BTC. so yeah, if you force me to choose btwn the current fiat system and BCH, i'd have to think long and hard about that choice b/c of your authoritarian technocratic limits vs the inflationists. whereas with an unlimited BSV, there is no comparison or difficulty, as BSV is the real Bitcoin.

 

[pafkatabg]

Gold collapsing, Bitcoin UP:

https://www.trustnodes.com/2019/07/21/bulgarias-bitcoin-holdings-surpass-their-gold-reserves

I can partially confirm this as a local resident, who is following the topic. The most likely situation is that the government can't move the coins. They have seized computers with wallets installed, which are claimed to have huge balances. Most likely they have the encrypted files, which contain the private keys, but the criminals would not tell the passwords to unlock the private keys. I'd not be surprised if the criminals negotiate a perfect deal for themselves.

I am reading this thread for several months and I will most likely start to contribute with few posts per month soon.