Of course, that's why it has been added: in the original protocol there was no way to create an address from a script different from P2PKH.
Not exactly: everybody (everybody!) agreed that this kind of feature was missing and was absolutely needed to allow standard addresses for complex scripting, the controversy was only on the way to implement it: Lukejr's OP_EVAL introduced a new and quite powerful OP (hence a bigger change to the original protocol with more unforeseen effects).
I'm sorry I overreacted, this happens to me when I really can't understand something. But I'm harmless, don't worry
Anyway, I perfectly know about information manipulation (I followed the block size debate quite closely and I learnt a thing or two from it...), and that's exactly why I asked a specific question and not a generic one: I would like to know the answer
of that specific one. I don't want you (or anybody else) changing topic to avoid to reply.
That seems like a forgery, and very very easy to prove, so the case seems closed for me, if I don't get an explanation.
So, tell me: how will you "ban" P2SH?
Remember that P2SH is a hack made to be backward compatible, and even old nodes would evaluate the enclosing script (not the enclosed one, though).
So, I asked a few questions and nobody replied, why?
1) How do you create addresses from random scripts?
2) How do you ban P2SH transactions, since they are normal scripts? If you disable the internal script validation they are still valid, you "just" are unable to reuse the same address because after the first usage all other transactions can be redeemed.
Yes, sorry if I reacted a bit too much.
Of course not, it's just needed to create a simple address, otherwise you would need to give the whole script to the payer, and that's not very practical since it can be quite long.
isStandard is a check that can be taken out at any moment, it's not the problem.
And also, it is enforced only on node relay since miners can create whatever transaction they want, already now.
So if you need to publish a non-standard transcation you just find a miner willing to accept it. I bet that with the right fee that's not a problem.
I mean how can you create (usable) addresses.
Because removing work done by others is not a good message to devs, exactly like changing the protocol and becoming uncompatible with the past.
Extending a protocol in a compatible way should be the way to go, and how it goes in software development since ages.
Who could believe such a thing?
CSW said
so many things that didn't happen, that I think nobody sane would believe such a crazy statement.
Actually I was one of his (few) supporters when he declared that it will attack the BCH chain with hashing power to avoid a split (do you remember "you split, we bankrupt you!" ?).
I was very impressed, because I like PoW and I think it should rule. I was very pro-craig at that time.
But then that, and many other claims, showed to be just empty words, and I don't like people that does not follow words with actions, sorry.
But I asked how, can you please explain me, technically speaking?
@Cristoph Bergmann:
You haven't used Melis then ;-)
The server coordinates signing by different parties until the transaction is ready to be broadcasted.
And sends you notifications when an action is needed.
And also applies restrictions (TFA, spending limits) if amongst the signers there is the server too.
You can also attach the transaction a little chat between the participants, so that the expense will be documented and will be accessible in the future.
No, that can't be done with threshold signatures because Melis, since day one (and it means at least since 5 years) is able to implement complex signature schemes like "N out M signatures are needed plus K mandatory ones".
No other wallet in the world is able to that that, and this works on BTC, BCH, LTC, GRS (and BSV too, until P2SH is working).
As a software developer I hate software patents (actually I am against every kind of patents, but software ones are the worst) and that's another point I don't like about CSW.