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).
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
Norway
Well-Known Member
- Sep 29, 2015
- 2,424
- 6,410
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.
Please don't try to paint IBS as a small tweak of previous BU inventions.
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...
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
Well-Known Member
- Sep 29, 2015
- 2,424
- 6,410
@theZerg
"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.)
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.
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 your own ego go, and not try to take credit when someone else invent something new.
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.)
You've been essentially asking for input and discussion on IBS so I read it.
> (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.
And here you hijacked a different discussion to directly make me aware of IBS:
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
Well-Known Member
- Sep 29, 2015
- 2,424
- 6,410
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.
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.
Fine, I take it back. It was your arrogance that pissed me off.
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.
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.
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.
@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.
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
Active Member
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.
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
Well-Known Member
- Sep 29, 2015
- 2,424
- 6,410
@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.
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
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
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).
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.
Last edited:
Gold collapsing, Bitcoin UP:
https://www.trustnodes.com/2019/07/21/bulgarias-bitcoin-holdings-surpass-their-gold-reserves
https://www.trustnodes.com/2019/07/21/bulgarias-bitcoin-holdings-surpass-their-gold-reserves
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 :
[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 :
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
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
Well-Known Member
- Aug 28, 2015
- 1,439
- 3,797
O brethren ...
> you censorship endorsing statist.
You not only endorsed to censor Norway, you campaigned for such subterranean activism.
#georgeorwell #liberty #truth #
> you censorship endorsing statist.
You not only endorsed to censor Norway, you campaigned for such subterranean activism.
#georgeorwell #liberty #truth #
Last edited:
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 :
[doublepost=1563890108][/doublepost]
correction, he endorsed censoring the entire BU non technical community; however the hell you define that.
- Dec 16, 2015
- 2,806
- 6,088
Only confirms the dirt on your shoes.
This bothers you a great deal more than it should an ordinary person.
Poor projection. You literally advocate authority to censor "illegitimate" transactions.
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".
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.
>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.
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.
Last edited:
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.
