ToominCoin aka "Bitcoin_Classic" #R3KT

[sickpig]

Going back to what we were saying, It is clear now that full nodes bandwidth consumption will remain the same even when SegWit soft-fork will be enforced/activated.

Even initially that is not necessarily true because if a full node is relaying txs (which will contain the signatures) then it may actually already have all of the necessary information to validate the next block it sees (currently full nodes that are relaying txs are often actually seeing the signatures twice).

Bolded part is right, and that's the thing used by thin/xthin block techniques to reduce block propagation BW consumption.  SegWit has nothing to do with thin blocks, I could be wrong though.

[Carlton Banks]

Going back to what we were saying, It is clear now that full nodes bandwidth consumption will remain the same even when SegWit soft-fork will be enforced/activated.

No that would be going back to what you were saying. My point stands: as a part of the staged activation of segwit on the network, full nodes will stop receiving the signature data. Proof that transactions are signed is still provided, but not by the regular full nodes.

How many times would you like me to repeat this statement? Do you need it rephrased a different way, for a fourth time?

And speaking of my original question I think that you're misremembering what I was asking, I just restate my question just for a matter of clarity because I'm genuinely in getting a proper response:  what's the reason why a discount of 75% is applied to signatures (witnesses) while computing block space limit? 

Nevertheless I apologize in advance if I'm wasting your time Carlton.

I can't really accept your apology, because you are wasting time, as well as space. Nevertheless.

It has been explained to you already, several times: the signatures occupy 3 quarters of the current block space (i.e. 75%). The remain quarter (25%) is made up of transaction data.

Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.



How many more times does this require explanation? And why am I explaining to someone who is more than capable of researching contrary evidence for themselves? Or are we to answer only your questions?

[CIYAM]

Even initially that is not necessarily true because if a full node is relaying txs (which will contain the signatures) then it may actually already have all of the necessary information to validate the next block it sees (currently full nodes that are relaying txs are often actually seeing the signatures twice).

Bolded part is right, and that's the thing used by thin/xthin block techniques to reduce block propagation BW consumption.  SegWit has nothing to do with thin blocks, I could be wrong though.

Think a bit harder - if a SegWit block doesn't contain the signatures (those are sent separately as a witness block) and you realise that you already have all the signatures required (from txs that were relayed) then you don't need to request the witness block - do you?

Again this isn't the purpose or point of SegWit but it is a potential side-benefit.

[sickpig]

Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.

I think you are wrong. It's impossible to validate a transaction without its signature.

 

[sickpig]

Even initially that is not necessarily true because if a full node is relaying txs (which will contain the signatures) then it may actually already have all of the necessary information to validate the next block it sees (currently full nodes that are relaying txs are often actually seeing the signatures twice).

Bolded part is right, and that's the thing used by thin/xthin block techniques to reduce block propagation BW consumption.  SegWit has nothing to do with thin blocks, I could be wrong though.

Think a bit harder - if a SegWit block doesn't contain the signatures (those are sent separately as a witness block) and you realise that you already have all the signatures required (from txs that were relayed) then you don't need to request the witness block - do you?

Again this isn't the purpose or point of SegWit but it is a potential side-benefit.

And what if you have only a few of those txs in your mempool, are you going to require only a part of the witness block? And more to the point does current SegWit proposal implement the algo you described?

That said thin/xthin will let you save even more BW because you won't request nothing about  txs you already have in your mempool (both base data and witness data (signs + script)).

[Carlton Banks]

Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.

I think you are wrong. It's impossible to validate a transaction without its signature.

Regular nodes still check the signatures, they just don't store them after checking them.



Why can't you look this information up for yourself? Answer the question, for the 3rd time.

[sickpig]

Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.

I think you are wrong. It's impossible to validate a transaction without its signature.

Regular nodes still check the signatures, they just don't store them after checking them.

we do agree then.

Full nodes will receive transactions base data and signature data, after checking them they could discard the signature part.  i.e. SegWit will not provide any reduction of bandwidth for full nodes.

[CIYAM]

i.e. SegWit will not provide any reduction of bandwidth for full nodes.

That is not correct - although SegWit has not been designed for this purpose as I've already pointed out (a few times now) bandwidth savings are possible (initially due to already having all the signatures from tx relaying and down the track due to the fact that the new signature types that SegWit will permit are significantly smaller than those currently being used).

I'm not really sure (apart from FUDding) why you want to keep on harping on about SegWit and bandwidth reduction anyway as that is not the purpose of SegWit (and any such benefits are side-effects as I've stated).

[sickpig]

i.e. SegWit will not provide any reduction of bandwidth for full nodes.

That is not correct - although SegWit has not been designed for this purpose as I've already pointed out (a few times now) bandwidth savings are possible (initially due to already having all the signatures from tx relaying and down the track due to the fact that the new signature types that SegWit will permit are significantly smaller than those currently being used).

Sure savings are possible, but at best of my knowledge are not implemented in the current proposal. And more to the point you can obtain even more BW savings using thin blocks independently from SegWit.

The fact is that you already have transactions (base + signs) in your mempool does not depend on SegWit. They're there already it's just a matter of using it.

edit: grammar

[CIYAM]

Sure savings are possible, but at best of my knowledge are not implemented in the current proposal. And more to the point you can obtain even more BW savings using thin blocks independently from SegWit.

As that is not the point of SegWit then that would hardly be surprising (I haven't looked at the code yet but as I've pointed out savings are indeed possible even initially and certainly later when the new signature type is introduced).

The fact that you already have transactions (base + signs) in your mempool does not depend on SegWit. They're there already it's just a matter of using it.

That is a different approach which is planned to be added down the track (and is arguably quite a bit more complicated).

[Carlton Banks]

Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.

I think you are wrong. It's impossible to validate a transaction without its signature.

Regular nodes still check the signatures, they just don't store them after checking them.

we do agree then.

Full nodes will receive transactions base data and signature data, after checking them they could discard the signature part.  i.e. SegWit will not provide any reduction of bandwidth for full nodes.

no we don't, you're still wrong in exactly the same way as before.


Full nodes currently download the signatures twice: when they receive relayed unconfrimed transactions, the signature data is provided. When any number of those unconfirmed transactions do become confirmed, the block they're mined in also contains the signature, for a second time. With segwit, there are two types of blocks: data blocks and signature blocks (i.e. witness blocks). The miners store and broadcast both types, whereas full nodes will only store & relay the data blocks. Hence the reduction in bandwidth requirements for full nodes.


For the 4th time, why are you incapable of attaining knowledge that comprehends segwit, yet you repeatedly bring up tech from the defunct Classic software? Explain yourself

[Bergmann_Christoph]

I can't really accept your apology, because you are wasting time, as well as space. Nevertheless.

It has been explained to you already, several times: the signatures occupy 3 quarters of the current block space (i.e. 75%). The remain quarter (25%) is made up of transaction data.

Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.

How many more times does this require explanation? And why am I explaining to someone who is more than capable of researching contrary evidence for themselves? Or are we to answer only your questions?

Oh Carlton, how often does sickpig need to ask before you understand the question?

The question is: why does sw discount the segregated data? Why not make it part of the blocksize? Or why not make it with 50% part of the blocksize?

[Bergmann_Christoph]

Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.

I think you are wrong. It's impossible to validate a transaction without its signature.

Regular nodes still check the signatures, they just don't store them after checking them.



Why can't you look this information up for yourself? Answer the question, for the 3rd time.

And here again, Carlton: you are not so clever as you think you are.

If regular nodes don't store signatures it will be impossible to validate transactions while syncing a new node. And that's one of the most important part of starting a node.

[Carlton Banks]

If regular nodes don't store signatures it will be impossible to validate transactions while syncing a new node. And that's one of the most important part of starting a node.

That's right Christoph, the regular nodes won't be able to connect to mining nodes at all troll harder

[Bergmann_Christoph]

Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.

I think you are wrong. It's impossible to validate a transaction without its signature.

Regular nodes still check the signatures, they just don't store them after checking them.

we do agree then.

Full nodes will receive transactions base data and signature data, after checking them they could discard the signature part.  i.e. SegWit will not provide any reduction of bandwidth for full nodes.

no we don't, you're still wrong in exactly the same way as before.


Full nodes currently download the signatures twice: when they receive relayed unconfrimed transactions, the signature data is provided. When any number of those unconfirmed transactions do become confirmed, the block they're mined in also contains the signature, for a second time. With segwit, there are two types of blocks: data blocks and signature blocks (i.e. witness blocks). The miners store and broadcast both types, whereas full nodes will only store & relay the data blocks. Hence the reduction in bandwidth requirements for full nodes.


For the 4th time, why are you incapable of attaining knowledge that comprehends segwit, yet you repeatedly bring up tech from the defunct Classic software? Explain yourself

And one more, this is also for you, CIYAM:

You don't need Segregated Witness to change the code so that a node does NOT get signatures a second time. That the default setup is currently that transactions are received and validated twice is a flaw in the design that is not that had to repair - see thinblocks. Why do you think it is a feature of Segwit that developers, who ignored this flaw for years, have the option to repair it in an inferior kind - by just not receiving the signatures twice while nodes still have to receive transactions twice? That makes not any sense at all.

Nobody says SegWit is senseles. You don't need to make it better than it is.

That you, Carlton Banks, do not understand this, is no surprise. But I remember you, CIYAM, as someone with a bright mind, so I'm disappointed to read this from you. Sorry to say this and with all respect.

[sickpig]

Because full nodes will no longer recieve the signatures signing tx's, 75% of the data will be discounted (i.e. Not. Counted.), such as the signature data represents 75% of the overall block data.

I think you are wrong. It's impossible to validate a transaction without its signature.

Regular nodes still check the signatures, they just don't store them after checking them.

we do agree then.

Full nodes will receive transactions base data and signature data, after checking them they could discard the signature part.  i.e. SegWit will not provide any reduction of bandwidth for full nodes.

no we don't, you're still wrong in exactly the same way as before.


Full nodes currently download the signatures twice: when they receive relayed unconfrimed transactions, the signature data is provided. When any number of those unconfirmed transactions do become confirmed, the block they're mined in also contains the signature, for a second time. With segwit, there are two types of blocks: data blocks and signature blocks (i.e. witness blocks). The miners store and broadcast both types, whereas full nodes will only store & relay the data blocks. Hence the reduction in bandwidth requirements for full nodes.

Suppose that miner node (A) will send only data block to full node (B). B start looking for txs signature in its mempool. Unluckily B does not have all the txs included in the just mined block because its mempool is not perfectly in sync with the one of node A.
What happen then? Will B require those transaction to node A or to some other nodes?

if a method for request missing txs are not implemented then you left out from your description that a full node will have to receive both data block and signature block form a miner node (*). it need both to actually perform txs / block validation.

(*) I don't think there's such a distinction from miner full node and a non miner full node at the prorocol level.

[valiz]

These trolls are so funny  

ToominCoin is rekt => divert focus to segwit is evil => divert focus to segwit bandwidth stuff 

[CIYAM]

@Bergmann_Christoph - am guessing you are a troll but in the off chance you aren't I made it very clear that the purpose of SegWit has nothing to do with reducing bandwidth.

[Bergmann_Christoph]

@Bergmann_Christoph - am guessing you are a troll but in the off chance you aren't I made it very clear that the purpose of SegWit has nothing to do with reducing bandwidth.

No, I'm not a troll, but the atmosphere in this thread has a tendency to wake up the inner trolls of all of us :/

I did not assume you think that SegWit's purpose is to reduce bandwith. Some poeple think, but they are wrong. But you said that SegWit enables some kind of band-width saving that is already and better possible and implemented by thinblocks. That's an argument - a point - that is not equal to your other posts.

That said I hope we manage to get a civilized, adult discussion.

[CIYAM]

But you said that SegWit enables some kind of band-width saving that is already and better possible and implemented by thinblocks.

I said it *potentially* (as a side-effect) can have some bandwith saving and in the future it WILL reduce bandwidth due to the new signature type (but only after those new signature types are being used a lot).

What I did not say was that this was comparable or better than thin blocks or other such things (please don't misquote me).

And *again* I'll state that the main purpose of SegWit has nothing to do with reducing bandwidth (so this whole new argument is actually kind of stupid).