ToominCoin aka "Bitcoin_Classic" #R3KT

[marcus_of_augustus]

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.

[1714929842]

1714929842

[1714929842]

1714929842

[1714929842]

1714929842

[Bergmann_Christoph]

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.

[Carlton Banks]

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.

[Carlton Banks]

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.

That sounds reasonable, but I expect the way it will be implemented could be a great deal more efficient if B were to send out requests for missing sigs prior to it's ability to validate a data block. And so the amount of bandwidth that would require needs accounting for, but I can't see that there won't still be an overwhelming saving in bandwidth for non-mining nodes like B. After all, missing tx's that were included in the latest block are only being relayed to B for the first time anyway, so the effect you're talking about sounds pretty marginal.

[btcusury]

Why is it that everyone who supports segwit has to be a condescending asshole all the time?

This is a major question many people ask and a phenomena that made many people escape bitcoin.

The best explanation I heard was posted yesterday in another forum:

The age of deference to authority will never end. It's in our blood, a tribal instinct. That is why Core's position is the default among the unthinking masses and especially junior coders who look up to the "wizard" heroes at Core.

Over the years I have looked at many fields and found that the marks of a field being fleeced by authority figures are pretty universal. Most salient is that semantic games always figure prominently: equivocation, weasel words and vague terms like "consensus," constant goalpost shifting, appeals to tribal identity ("cypherpunks"), circular arguments rinsed down with appeals to authority, blatant double standards, censorship in the name of free speech, buzzwordism, extremely short public memory just like in political cycles, the genetic fallacy, slippery slope, etc.

Hope this helps to understand some kind of mindset without disrespecting them. Everybody is human.

You are so badly mistaken it's funny! You won't find a more anti-"authority" poster here than me (see links in sig) and I'll tell you that's it's obvious to me that the forkers have no good arguments to push their position the way they are still doing. This is about technical and philosophical arguments, which you can come to understand(/overstand/innerstand), without having to defer to some "expert". But you don't care about that, it seems. You stick to initial perceptions and assumptions. The quote you posted is extremely pertinent, but it goes both ways, you see -- the forkers really have nothing at all to their arguments except the perceived "authority" of Gavin and a few others.

What's actually happening is this:

It was inevitable that these forkers would eventually target segwit, which was widely acclaimed as a completely uncontroversial fix when it was first released.

The governance coup that they are attempting is founded on disrupting any and all progress that doesn't belong to 'their vision' of progress. If it wasn't segwit it would be whatever Core was currently working on.

And that "Hope this helps to understand some kind of mindset without disrespecting them" PC BS is incredibly self-destructive, BTW. See no evil, hear no evil, allow all evil. It's what's leading your country to a civil war!

[pereira4]

With every new update of Core and new BIPs and merging of features going on the Classic supporters are getting increasingly nervous. Im sorry guys but at this point it's time to call it a day and admit that Core was the better team from the start.

https://twitter.com/bitcoincoreorg/status/715482664443052032

To the moon.

[sickpig]

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.

That sounds reasonable, but I expect the way it will be implemented could be a great deal more efficient if B were to send out requests for missing sigs prior to it's ability to validate a data block. And so the amount of bandwidth that would require needs accounting for, but I can't see that there won't still be an overwhelming saving in bandwidth for non-mining nodes like B. After all, missing tx's that were included in the latest block are only being relayed to B for the first time anyway, so the effect you're talking about sounds pretty marginal.

You have just gave a overall description xthin block algorithm. And yes, xthin provide a pretty significant  BW saving in the block propagation step (~ an order of magnitude).

But as I've already told you that's orthogonal to SegWit, you could implement it now without SegWit.

More to the point current Segwit proposal does not implement the aforementioned mechanism and at best of my knowledge there's no plan to include it in the near future.

So it seems that we are still searching for a motivation for the 75% discount applied to witness data.

[CIYAM]

So it seems that we are still searching for a motivation for the 75% discount applied to witness data.

No we are not. The purpose of SegWit has been explained to you numerous times (and saving bandwidth is not it).

It is clear now that you are posting nonsense repeatedly just like all the other trolls (you might be being paid to post your nonsense but others will post for nothing just to point it out so that you won't "win" using this approach - there seems to be at least 10+ forum members using the exact same approach and as tiring as it is to have to keep countering it I'm going to continue to do so as it makes this approach more and more obvious and therefore less and less effective).

[sickpig]

So it seems that we are still searching for a motivation for the 75% discount applied to witness data.

No we are not. The purpose of SegWit has been explained to you numerous times (and saving bandwidth is not it).

It is clear now that you are posting nonsense repeatedly just like all the other trolls.

Sorry but I'm actually trying to understand and I don't want to troll anyone. Just check my history to see that I've almost no tendency to trolling.

That said, if the 75% it's not due to actual bandwidth savings what are the main reason? Storage saving or future benefits?  If it's the former it seems to me that is a little bit disproportionate.

[CIYAM]

Sorry but I'm actually trying to understand and I don't want to troll anyone. Just check my history to see that I've almost no tendency to trolling.

If you're seriously not trolling then why do you keep on posting about SegWit and bandwidth savings?

(for the Nth time SegWit was not created for bandwidth savings so arguing about whether or not you'll get whatever amount of said savings is irrelevant)

[sickpig]

Sorry but I'm actually trying to understand and I don't want to troll anyone. Just check my history to see that I've almost no tendency to trolling.

If you're seriously not trolling then why do you keep on posting about SegWit and bandwidth savings?

(for the Nth time SegWit was not created for bandwidth savings so arguing about whether or not you'll get whatever amount of said savings is irrelevant)

Could you please explain to me the reason why a discount of 75% is applied to signatures (witnesses) while computing block space limit?

[CIYAM]

Could you please explain to me the reason why a discount of 75% is applied to signatures (witnesses) while computing block space limit?

The witness information is separate to the block data (with SegWit).

I don't know where the figure 75% itself originates from but when SegWit is implemented then all such tx signatures are no longer stored in the block (thus leaving more space for more transactions in the block without changing the 1MB block size limit).

[hdbuck]

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.

at least it does not fucking increase it, weasel.

[xyzzy099]

Sorry but I'm actually trying to understand and I don't want to troll anyone. Just check my history to see that I've almost no tendency to trolling.

If you're seriously not trolling then why do you keep on posting about SegWit and bandwidth savings?

(for the Nth time SegWit was not created for bandwidth savings so arguing about whether or not you'll get whatever amount of said savings is irrelevant)

Could you please explain to me the reason why a discount of 75% is applied to signatures (witnesses) while computing block space limit?

Did this not answer your question?

https://bitcointalk.org/index.php?topic=1330553.msg14367997#msg14367997

The developers only matter when they say what you want to hear?

I've yet to see a single person who completely understands Segwit and is against it.

if you are among the group of people that completely understand SegWit, could you please explain to me the reason why a discount of 75% is applied to signatures (witnesses) while computing block space limit? (serious question)

the witness data (signatures) portion of a transaction usually makes up around 75% of the total transaction data size ... so by moving it out the main block and into a separate 'witness block' of data makes available approx. that much space in the main block for other data.

[sickpig]

Did this not answer your question?

https://bitcointalk.org/index.php?topic=1330553.msg14367997#msg14367997

the witness data (signatures) portion of a transaction usually makes up around 75% of the total transaction data size ... so by moving it out the main block and into a separate 'witness block' of data makes available approx. that much space in the main block for other data.

Nope.

Because despite the witness segregation in a separate block my full node will receive both txs base data and witness data to perform full validation.

And because my node will have to relaying both base data and witness data to any other full node to let them perform full validation.

So of the 3 main costs of operating a node RAM/CPU, bandwidth and storage the witness segregation will let me save in terms of storage and bandwidth only once I will decide to discard the witness part of a block, or "witness block" if you will.

This has a disadvantage though, namely I could not fully participating to the p2p bitcoin network anymore because I can't provide blocks data to new nodes once I delete the witness part.

[CIYAM]

So of the 3 main costs of operating a node RAM/CPU, bandwidth and storage the witness segregation will let me save in terms of storage and bandwidth only once I will decide to discard the witness part of a block, or "witness block" if you will.

Why do you persist with the nonsense posting?

SegWit was not created to save bandwidth (in the short term) - can you please repeat that for me?

(it seems that you really are a troll after all as you refuse to acknowledge this very simple fact and keep on posting about bandwidth - also if you didn't troll before then it is very likely that you are not the original owner of the account)

[xyzzy099]

Did this not answer your question?

https://bitcointalk.org/index.php?topic=1330553.msg14367997#msg14367997

the witness data (signatures) portion of a transaction usually makes up around 75% of the total transaction data size ... so by moving it out the main block and into a separate 'witness block' of data makes available approx. that much space in the main block for other data.

Nope.

Because despite the witness segregation in a separate block my full node will receive both txs base data and witness data to perform full validation.

And because my node will have to relaying both base data and witness data to any other full node to let them perform full validation.

So of the 3 main costs of operating a node RAM/CPU, bandwidth and storage the witness segregation will let me save in terms of storage and bandwidth only once I will decide to discard the witness part of a block, or "witness block" if you will.

This has a disadvantage though, namely I could not fully participating to the p2p bitcoin network anymore because I can't provide blocks data to new nodes once I delete the witness part.

The 75% witness discount will allow for more transactions per block w/o requiring a hard fork.  I don't think anyone is claiming that it will directly reduce resources required to run a full validating node.

[adamstgBit]

Did this not answer your question?

https://bitcointalk.org/index.php?topic=1330553.msg14367997#msg14367997

the witness data (signatures) portion of a transaction usually makes up around 75% of the total transaction data size ... so by moving it out the main block and into a separate 'witness block' of data makes available approx. that much space in the main block for other data.

Nope.

Because despite the witness segregation in a separate block my full node will receive both txs base data and witness data to perform full validation.

And because my node will have to relaying both base data and witness data to any other full node to let them perform full validation.

So of the 3 main costs of operating a node RAM/CPU, bandwidth and storage the witness segregation will let me save in terms of storage and bandwidth only once I will decide to discard the witness part of a block, or "witness block" if you will.

The 75% witness discount will allow for more transactions per block w/o requiring a hard fork.  I don't think anyone is claiming that it will directly reduce resources required to run a full validating node.

Give it up sickpig, we all understand what your saying, but like everyone keeps saying at the end of the day segwit will nearly double capacity.
the 75% witness discount will make sure of that even if not all full-user-nodes dont upgraded.

This has a disadvantage though, namely I could not fully participating to the p2p bitcoin network anymore because I can't provide blocks data to new nodes once I delete the witness part.

no. the blocks can be sent around without the individual sigs on each TX, and that block can still be validated without these sigs.

[drinksyourmilkshake]

Why does this thread still exist? it's over; classicism is dead.  Sorry /r/btctards, dump and get out of the way.

[adamstgBit]

Why does this thread still exist? it's over; classicism is dead.  Sorry /r/btctards, dump and get out of the way.

its only just begun

now that classic has >5% hashing power it has veto power over segwit.
obviously core (~95% hashing power) has veto power over 2MB
with this veto power, a compromise is just around the corner.

maybe we'll get 1.256MB now + Segwit later, who knows...

if anything this thread is dead because classic isn't #R3KT