inbuilt transaction type in bitcoin to improve scalability massively?

[Anonymous Kid]

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

Code:

inputs;
<unlock script>(n times)

outputs;
OP_DUP OP_HASH160 <hash> 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?

so like this;

Code:

type: simple_tx,
inputs: {
  tx_id: <id> (n times)
  aggregated signature: <signature> (1 time)
}

outputs: {
  type: simple_unlock
  new_owner: <pub key>
}

so here we get rid of a lot a lot of data by making tx much more simple. Node processes inputs by searching all tx_id's and makes sure they are all of the type simple_unlock. Then it adds all the pub keys for those tx up and makes sure that the input signature matches*. Then if its valid the node adds the new outputs to the db.
if simple_unlock is used with traditional scripting unlocks outputs then it just defaults to  OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG and the spender has to provide a valid unlock script.

Using this method means that you can get size of input signatures down from O(n) to O(1). There is also space saving on the outputs because you only need to use a pub key and not other scripting stuff.

*i am not sure if ecdsa has signature aggregation? But I know schnorr does.

[1715093897]

1715093897

[1715093897]

1715093897

[1715093897]

1715093897

[1715093897]

1715093897

[1715093897]

1715093897

[1715093897]

1715093897

[darosior]

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

Code:

inputs;
<unlock script>(n times)

outputs;
OP_DUP OP_HASH160 <hash> 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?

so like this;

Code:

type: simple_tx,
inputs: {
  tx_id: <id> (n times)
  aggregated signature: <signature> (1 time)
}

outputs: {
  type: simple_unlock
  new_owner: <pub key>
}

so here we get rid of a lot a lot of data by making tx much more simple. Node processes inputs by searching all tx_id's and makes sure they are all of the type simple_unlock. Then it adds all the pub keys for those tx up and makes sure that the input signature matches*. Then if its valid the node adds the new outputs to the db.
if simple_unlock is used with traditional scripting unlocks outputs then it just defaults to  OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG and the spender has to provide a valid unlock script.

Using this method means that you can get size of input signatures down from O(n) to O(1). There is also space saving on the outputs because you only need to use a pub key and not other scripting stuff.

*i am not sure if ecdsa has signature aggregation? But I know schnorr does.

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.

[HeRetiK]

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.

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

Code:

inputs;
<unlock script>(n times)

outputs;
OP_DUP OP_HASH160 <hash> 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.

[ABCbits]

Bitcoin script is pretty small as each codes only have 4 byte in size, so it only save less than 16 bytes and contribute little to reduce blockchain size growth.

Also, all wallet must adopt to this format and i doubt it can be done without hard-fork, unless you introduce new opcodes and older nodes treat it as anyone-can-spend (just like SegWit backward compatibility). Roughly it look like this where nodes automatically convert it to proper script and put the signature to correct position.

OP_PRESET <preset_id> <signature>

Using this method means that you can get size of input signatures down from O(n) to O(1). There is also space saving on the outputs because you only need to use a pub key and not other scripting stuff.

It's still has O(n) space complexity unless you're talking about MuSig Schnorr

[Anonymous Kid]

Bitcoin script is pretty small as each codes only have 4 byte in size, so it only save less than 16 bytes and contribute little to reduce blockchain size growth.

Also, all wallet must adopt to this format and i doubt it can be done without hard-fork, unless you introduce new opcodes and older nodes treat it as anyone-can-spend (just like SegWit backward compatibility). Roughly it look like this where nodes automatically convert it to proper script and put the signature to correct position.

OP_PRESET <preset_id> <signature>

Using this method means that you can get size of input signatures down from O(n) to O(1). There is also space saving on the outputs because you only need to use a pub key and not other scripting stuff.

It's still has O(n) space complexity unless you're talking about MuSig Schnorr

I mean with this technique you can introduce signature aggregation (only need 1 signature for N keys). So it does become O(1). They main benefit is signature aggregation not getting rid of the one or two op_codes. I think you're right in that it would need a hard fork tho.

[achow101]

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

Code:

inputs;
<unlock script>(n times)

outputs;
OP_DUP OP_HASH160 <hash> 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?

so like this;

Code:

type: simple_tx,
inputs: {
  tx_id: <id> (n times)
  aggregated signature: <signature> (1 time)
}

outputs: {
  type: simple_unlock
  new_owner: <pub key>
}

so here we get rid of a lot a lot of data by making tx much more simple. Node processes inputs by searching all tx_id's and makes sure they are all of the type simple_unlock. Then it adds all the pub keys for those tx up and makes sure that the input signature matches*. Then if its valid the node adds the new outputs to the db.
if simple_unlock is used with traditional scripting unlocks outputs then it just defaults to  OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG and the spender has to provide a valid unlock script.

Using this method means that you can get size of input signatures down from O(n) to O(1). There is also space saving on the outputs because you only need to use a pub key and not other scripting stuff.

*i am not sure if ecdsa has signature aggregation? But I know schnorr does.

That's exactly what segwit does except for signature aggregation. AFAIK, ecdsa does not support signature aggregation, but schnorr does, so we should actually get transactions that look just like this in the future.

[aliashraf]

We need to distinguish between segregation and aggregation, to have a truly scalable blockchain you need both.

Segregation is what SW offers already, it helps in pruning unnecessary, witness data once blocks are buried enough and re-orgs are practically impossible.

As of aggregation in its ultimate form, as @ETF and  Andrew has reminded correctly we have Schnorr which has its own story and  controversies (not too much, but still) and the main problem would be hard fork phobia in bitcoin and I don't exactly know  what they are going to do with it.

But I think there is something we can do in terms of aggregation with current ECDSA technology. I don't exactly know how effective it would be because I have no statistics right now showing how important it would be, but I think it is worth discussing here.
Following is a modified version of op's pseudo script:

Code:

type: AGGREGATED,
inputs: {
  tx_ids: <[id_list]>[,id_list]      // id_list :: id [,id]
  tx_pubkeys: <pubkey>[,<pubkey>]
  aggregated signatures: <signature> [,<signature>]
}
,
outputs: {
  type: P2KH
  new_owners: <(address, amount, script)> [,<(address, amount, script)>]
}

Here we are on the same old rail but with a small difference which may sometimes have huge advantage to make some boiler plates substantially smaller.

Every payment made to a wallet address in bitcoin creates a utxo that is spendable once as an input of a txn. Now suppose a business/person has announced an address to another group/person for recurring payments, with current bitcoin transaction format for the owner to spend the total balance it takes a one-payment-one-input transaction which is amazingly stupid and a waste of space/bandwidth.

According to above proposed model, wallets arrange inputs with same "PubkeyHash" in their output script in id-list(s) and disclose their unique pubkey(s) separately along with corresponding signature(s).

It looks to be a good pre-Shnorr optimization, imo  
As of now I've not extensively studied the possibility of implementing it in a soft-soft way, to be honest.

[gmaxwell]

the main problem would be hard fork phobia in bitcoin

There is no hardfork needed for schnorr signatures or aggregation, nor is any desirable for them. All they require is an additional script type.

What you suggest instead is no easier and would create a massive incentive for address reuse.  That just isn't going to happen.

[aliashraf]

the main problem would be hard fork phobia in bitcoin

What you suggest instead is no easier and would create a massive incentive for address reuse.  That just isn't going to happen.

I wonder if anything like that has been discussed before. I felt somehow smarty when I came to this anyway.  

As of hard fork, I just read somewhere that Shnorr needs one and honestly I don't know without a trick like what was used for sw how it would be possible to support it. I'll check discussions don't bother describing it here, seems to be pretty much off-topic.


As of address re-use: You are implying that my proposed txn format will encourage users not to generate and give new receive addresses to their customers/partners for recurring payments. Isn't it too much of intervention?

In practice, to distinguish between different users (whenever needed)  businesses need to assign them different addresses and there is always definite chance for them to deal with payments that are made when they have already spent the address.

And as usual, your "That just isn't going to happen" thing  is annoying, nobody has ordered you to do anything. We are just discussing possibilities.

[gmaxwell]

I wonder if anything like that has been discussed before. I felt somehow smarty when I came to this anyway.  

Yes, a couple times. If you really care I can dig up an older post.

As of hard fork, I just read somewhere that Shnorr needs one

Not at all, in fact that is a really _super duper_ perplexing claim. Introducing a new script operation is like the canonical example of a softfork. No one would ever consider implementing it any other way.

It really makes me sad that there is so much misinformation being spread about Bitcoin.

how it would be possible to support it.

A new checksigverify operation is defined out of an existing nop that processes the new style signatures... exactly how any other softfork works.

For aggregation, the operation can take an empty signature, and it just pushes the aggregate signature onto a signature stack, and the last signature in the aggregate isn't empty and provides the signature for the aggregate. Or likewise,

And as usual, your "That just isn't going to happen" thing  is annoying,

The rehashed discussion is annoying.  People previously proposed  having one signature for reused scriptpubkeys, and it got smashed into the ground over the fact that it would create a huge financial incentive to reuse.  Indeed there are also reasons against reuse but with enough incentive they can be overcome (e.g. only reuse addresses for settled payments... bitpay was already doing that even though there is no incentive in the system, just because they wanted to store fewer private keys...)

[aliashraf]

I wonder if anything like that has been discussed before. I felt somehow smarty when I came to this anyway.  

Yes, a couple times. If you really care I can dig up an older post.

Of course I do. And I appreciate it, take your time tho.

And as usual, your "That just isn't going to happen" thing  is annoying,

The rehashed discussion is annoying.  

"Rehashing" just happens Greg, take it easy. There is no way for people to review all the discussions in bitcoin in last 10 years like a historian or something! Plus, I personally have encountered a lot of semi-closed issues in bitcoin, it is not bad to reopen some files occasionally, imo.  

For instance I'm discussing ASIC resistance in other thread right now and I don't expect you or anybody to show up saying things about "rehashing" closed cases.
I know ASIC is controversial topic and many topics are not and I appreciate your idea about not repeating the history like in a comedy but it will be highly appreciated too if you would bother posting a reference to older threads or even just briefly mentioning that they exist and not feeling any offense.

[gmaxwell]

"Rehashing" just happens Greg, take it easy.

It was you that started the complaining... not I.  All I did was point out that inserting a gigantic financial incentive to reuse addresses is a non-starter. (doubly so because we know how to get the same gain without the bad incentive via aggregation with essentially an identical implementation).

If you're going to complain that my response was terse, please don't also complain when I expand on why I didn't think the matter needed more than a terse response.

[aliashraf]

"Rehashing" just happens Greg, take it easy.

It was you that started the complaining... not I.  All I did was point out that inserting a gigantic financial incentive to reuse addresses is a non-starter. (doubly so because we know how to get the same gain without the bad incentive via aggregation with essentially an identical implementation).

Schnorr is not standardized yet and Pieter wullie's draft needs to be approved by a standards body I suppose. If so, Schnorr may be delayed like 1-2 years. Right?

If you're going to complain that my response was terse, please don't also complain.

Terse talk is ok.

But Greg, there is something you need to reconsider. I complained about harsh tone in spite of the fact that nobody has made any offense.

P.S
Would you please give me some keywords to search for historical discussions you are referring to?