ToominCoin aka "Bitcoin_Classic" #R3KT - page 48.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: marcus_of_augustus on March 31, 2016, 06:19:19 AM

Quote from: Bergmann_Christoph on March 31, 2016, 06:02:13 AM

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 :/

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

... yeah right, a civilised discussion with disingenuous little weasels arguing in bad faith and an endless barrage of troll-fest questions that looks more like feeding time at the zoo. Good luck with trying to make your turd slinging session look like 'civilised discussion'.

And how many of these sudden experts and critics on segwit have commented on github, or god forbid, submitted actual code pull requests for improvements to the system they're crapping on?? ... big fat zero I can confidently guess.

It appears that bullshit still walks, but money now codes.

Bergmann_Christoph

sr. member

Activity: 409

Merit: 286

Quote from: CIYAM on March 31, 2016, 06:11:32 AM

Quote from: Bergmann_Christoph on March 31, 2016, 06:02:13 AM

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).

So, ok, everything's all right. SegWit has not the purpose to reduce bandwith and it does not reduce bandwith, but it is possible that in the future things will be build on segwit that save bandwith. Ok.

If Carlton get's this too, we have achieved something today.

marcus_of_augustus

legendary

Activity: 3920

Merit: 2349

Eadem mutata resurgo

Quote from: Bergmann_Christoph on March 31, 2016, 06:02:13 AM

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 :/

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

... yeah right, a civilised discussion with disingenuous little weasels arguing in bad faith and an endless barrage of troll-fest questions that looks more like feeding time at the zoo. Good luck with trying to make your turd slinging session look like 'civilised discussion'.

And how many of these sudden experts and critics on segwit have commented on github, or god forbid, submitted actual code pull requests for improvements to the system they're crapping on?? ... big fat zero I can confidently guess.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Bergmann_Christoph on March 31, 2016, 06:02:13 AM

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).

Bergmann_Christoph

sr. member

Activity: 409

Merit: 286

Quote from: CIYAM on March 31, 2016, 05:57:00 AM

@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

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

@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.

valiz

sr. member

Activity: 471

Merit: 250

BTC trader

These trolls are so funny Cheesy

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

sickpig

legendary

Activity: 1260

Merit: 1008

Quote from: Carlton Banks on March 31, 2016, 05:14:04 AM

Quote from: sickpig on March 31, 2016, 04:57:21 AM

Quote from: Carlton Banks on March 31, 2016, 04:43:53 AM

Quote from: sickpig on March 31, 2016, 04:11:01 AM

Quote from: Carlton Banks on March 31, 2016, 03:50:28 AM

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.

Bergmann_Christoph

sr. member

Activity: 409

Merit: 286

Quote from: Carlton Banks on March 31, 2016, 05:14:04 AM

Quote from: sickpig on March 31, 2016, 04:57:21 AM

Quote from: Carlton Banks on March 31, 2016, 04:43:53 AM

Quote from: sickpig on March 31, 2016, 04:11:01 AM

Quote from: Carlton Banks on March 31, 2016, 03:50:28 AM

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.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: Bergmann_Christoph on March 31, 2016, 05:40:36 AM

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 Roll Eyes

troll harder

Bergmann_Christoph

sr. member

Activity: 409

Merit: 286

Quote from: Carlton Banks on March 31, 2016, 04:43:53 AM

Quote from: sickpig on March 31, 2016, 04:11:01 AM

Quote from: Carlton Banks on March 31, 2016, 03:50:28 AM

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.

Bergmann_Christoph

sr. member

Activity: 409

Merit: 286

Quote from: Carlton Banks on March 31, 2016, 03:50:28 AM

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?

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: sickpig on March 31, 2016, 04:57:21 AM

Quote from: Carlton Banks on March 31, 2016, 04:43:53 AM

Quote from: sickpig on March 31, 2016, 04:11:01 AM

Quote from: Carlton Banks on March 31, 2016, 03:50:28 AM

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

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: sickpig on March 31, 2016, 05:09:01 AM

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).

Quote from: sickpig on March 31, 2016, 05:09:01 AM

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).

sickpig

legendary

Activity: 1260

Merit: 1008

Quote from: CIYAM on March 31, 2016, 05:03:42 AM

Quote from: sickpig on March 31, 2016, 04:57:21 AM

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

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: sickpig on March 31, 2016, 04:57:21 AM

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

legendary

Activity: 1260

Merit: 1008

Quote from: Carlton Banks on March 31, 2016, 04:43:53 AM

Quote from: sickpig on March 31, 2016, 04:11:01 AM

Quote from: Carlton Banks on March 31, 2016, 03:50:28 AM

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.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: sickpig on March 31, 2016, 04:11:01 AM

Quote from: Carlton Banks on March 31, 2016, 03:50:28 AM

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

legendary

Activity: 1260

Merit: 1008

Quote from: CIYAM on March 31, 2016, 04:05:50 AM

Quote from: sickpig on March 31, 2016, 03:45:42 AM

Quote from: CIYAM on March 31, 2016, 03:30:57 AM

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)).

sickpig

legendary

Activity: 1260

Merit: 1008

Quote from: Carlton Banks on March 31, 2016, 03:50:28 AM

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.

Topic: ToominCoin aka "Bitcoin_Classic" #R3KT - page 48. (Read 157137 times)