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

That is something that even Mike Hearn knew is *simply impossible* for Bitcoin (I remember a topic about this from around 3 years ago in which I had actually argued for the creation of such a protocol specification and he convinced me otherwise).

It is fine for something like SMTP to have implementation faults as about the worst thing that might happen is you miss an email - but if you make any implementation fault with Bitcoin then people will lose money.

The C++ code IS the specification and if you refuse to read it then I'm sorry but you are NEVER going to understand Bitcoin (and it isn't up to us to educate you).

There are non-node implementations written in other languages so maybe you might be able to read the code of one of those (am guessing C++ is perhaps too difficult for you) but you need to understand that only "libconsensus" (written in C++) holds the key to Bitcoin (other language implementations are not used for mining but only for wallets).

The very language C++ itself would need to form a part of any such specification (as every single little C++ nuance is relevant) which would make any such document ridiculously large (which is why you are never going to see that).

You could of course take a look at Mastering Bitcoin (which I believe can even be found online).

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

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


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

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

I'm not sure if that command is even allowed when running in prune mode but if it is allowed then it would only be permitted for adding a new (never used before) address (same would apply to importaddress also).

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.

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

Also as I pointed out above - the SegWit implementation will support a new type of signature which will be much smaller (so although not initially a saving this will result in a saving of bandwidth as the witness data will be less than the equivalent signatures being used currently).

The main reasons for SegWit are to eradicate tx malleability (which was really a mistake that was in the original design) and to make it easier to add extensions to Bitcoin's script language (which are currently only possible via soft or hard fork).

Any space savings are a beneficial side-effect (for SPV clients) rather than being anything to do with the purpose of it.

Note that once SegWit has been implemented a new type of signature approach will be introduced that will be far more compact (so eventually the amount of bandwidth will be reduced even for full nodes but of course that won't be until a lot of txs are using the new type of signatures).

Huh?

You certainly can run software offline (and in fact every hardware wallet requires software for signing raw transactions).

What you don't want to do is give the offline software internet access or access to something like an infected USB flash drive.

Again - a total misunderstanding of the terminology and how Bitcoin works.

If you are seriously at all interested in what Standard and Valid transactions are then you should read the code rather than post nonsensical things like you just did.

It is rather clear to me (and others) that you are not interested to understand anything but instead to try and push the agenda of those that are attacking the Bitcoin core devs.

If it were just designed to be a currency then it wouldn't have had a 21M limit built in (as there would be no need for that as most currencies in the world inflate at a fairly constant rate).

Additions such as payment channels will enable "coffee" purchases down the track so it is very likely we'll be able to "have our cake and eat it too" but without a doubt preventing centralisation is the most important thing for Bitcoin to really be any serious game changer (so IMO that should be the main focus of development).

My point was not the insults, but the threats (and I don't think I've threatened anyone on this forum personally).

I don't doubt that I might have insulted some people on this forum but I do doubt that I would have done so without any reason (as I don't normally insult people without a reason).

So if you think I've insulted someone without reason then please provide the link (I am man enough to apoligise if I really got it wrong).

It certainly used to be very good for that but I think it is becoming less and less so in recent years.

(the opinion of a newbie is perhaps not really of that much relevance though)

https://bitcointalk.org/index.php?topic=1402980.msg14343375#msg14343375

Whilst I don't really care about this idiot attacking me I think it is relevant to note that this is what this forum has become (it used to actually be a place where you'd learn about Bitcoin rather than just some stupid fights).

If you actually care about Bitcoin (and not some replacement) then welcome to say so here.

No - I do understand that you are just an idiot kid posting in a forum.

I would advise you to not try and threaten people as that will likely not end up well for you.

Your topic has come to an end - no-one cares about you or your supposed issues with the forum (I am unwatching this topic now so you won't have any further posts from me).

Oh - I'm so scared - that apparently I need to send you a phone because you can't even afford one yourself and you're also apparently not capable of dialing that fake number that you posted.

Go back to primary school and learn something.

(now everyone can see exactly how stupid you are)

You are kidding me - please call the number (you haven't even got the correct country).



Dumbass!

You can simply check the fact that I was actually holding 500 BTC for the forum a few years ago.

Now where does your 100+ BTC come from?

(out of your arse no doubt)

Am waiting patiently for your call dickhead.

How about let's bet 100 BTC that you cannot even work out my phone number?

(oh - that's right you don't even have 100 BTC do you - so maybe you can take a 1 BTC bet?)