Quote from: darosior on January 12, 2019, 12:05:51 PM

Hi,

I'm not sure what do you propose.
If you are talking about "an inbuilt method to process these tx" (in which software ? bitcoin-core ?) then there is createrawtransaction which takes as parameter almost what you described.
If you are talking about kind of a script language that would compile to Script there is Ivy but I have not tested it yet.

If I'm not mistaken OP is suggesting a method to reduce transaction size and therefore blockchain bloat.

Quote from: Anonymous Kid on January 12, 2019, 05:40:53 AM

So current tx. is (basically) like this right;

Code:

inputs;
(n times)

outputs;
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG (n times)

but this is really boilerplate. And probably like 90% of tx. are like this^. so why not have an inbuilt method to process these tx. much easier and more scalable?

I think one of the problems is that replacing boilerplate code like above with an abstraction makes it incredibly hard to upgrade the network when the logic behind the "simple_unlock" changes (or should change, due to a shift in usage of transaction formats).

Case in point -- the script used in the example above is already more or less obsolete, it's a legacy P2PKH transaction. Wrapped SegWit P2SH transactions already look different, native SegWit transactions look different still. All based on the same op_code primitives that every node understands (Well not quite, SegWit also saw the re-introduction of some formerly deprecated op_codes, but to be honest I'm not sure whether they are unrelated or necessary for these redeem scripts).

However I guess the main reason why we don't have a transaction type as suggested above is the lack of a viable ECDSA signature aggregation method. My understanding of cryptography is spotty at best though.