Bitcoin Forum
February 23, 2019, 02:06:30 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: inbuilt transaction type in bitcoin to improve scalability massively?  (Read 206 times)
Anonymous Kid
Member
**
Offline Offline

Activity: 184
Merit: 22


View Profile
January 12, 2019, 05:40:53 AM
Merited by ETFbitcoin (1)
 #1

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.
1550887590
Hero Member
*
Offline Offline

Posts: 1550887590

View Profile Personal Message (Offline)

Ignore
1550887590
Reply with quote  #2

1550887590
Report to moderator
Goat says: "Bitcoin is NOT Illegal in Thailand. There is no law against Bitcoin in Thailand!"
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1550887590
Hero Member
*
Offline Offline

Posts: 1550887590

View Profile Personal Message (Offline)

Ignore
1550887590
Reply with quote  #2

1550887590
Report to moderator
darosior
Member
**
Offline Offline

Activity: 112
Merit: 121


View Profile WWW
January 12, 2019, 12:05:51 PM
 #2

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
Hero Member
*****
Offline Offline

Activity: 1022
Merit: 955


the forkings will continue until morale improves


View Profile
January 12, 2019, 03:27:27 PM
Merited by bones261 (2), ETFbitcoin (1)
 #3

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.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1596
Merit: 1555

Use SegWit and enjoy lower fees.


View Profile WWW
January 12, 2019, 08:05:34 PM
Merited by bones261 (4)
 #4

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.

Quote
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
Member
**
Offline Offline

Activity: 184
Merit: 22


View Profile
January 12, 2019, 09:07:00 PM
 #5

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.

Quote
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
Moderator
Legendary
*
expert
Offline Offline

Activity: 1680
Merit: 2086


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
January 13, 2019, 03:37:22 AM
Merited by Foxpup (3)
 #6

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.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1596
Merit: 1555

Use SegWit and enjoy lower fees.


View Profile WWW
January 13, 2019, 08:03:42 PM
 #7

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.

Since you use different script formatting, i though you're talking about reduce transaction size with aggregate signature and reduce script size. But if you're only talking about signature aggregation, then you know that MuSig Schnorr is being developed and it's just matter of time before we use it.

aliashraf
Hero Member
*****
Offline Offline

Activity: 728
Merit: 586


View Profile
January 15, 2019, 05:04:47 PM
Last edit: January 15, 2019, 06:54:51 PM by aliashraf
Merited by ETFbitcoin (1), Heisenberg_Hunter (1)
 #8

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  Wink
As of now I've not extensively studied the possibility of implementing it in a soft-soft way, to be honest.

gmaxwell
Moderator
Legendary
*
qt
Online Online

Activity: 2660
Merit: 1995



View Profile
January 15, 2019, 05:52:00 PM
 #9

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
Hero Member
*****
Offline Offline

Activity: 728
Merit: 586


View Profile
January 15, 2019, 06:49:41 PM
 #10

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

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
Moderator
Legendary
*
qt
Online Online

Activity: 2660
Merit: 1995



View Profile
January 15, 2019, 08:11:53 PM
Merited by Foxpup (4)
 #11

I wonder if anything like that has been discussed before. I felt somehow smarty when I came to this anyway.  Tongue
Yes, a couple times. If you really care I can dig up an older post.

Quote
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. Sad

Quote
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,

Quote
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
Hero Member
*****
Offline Offline

Activity: 728
Merit: 586


View Profile
January 15, 2019, 09:50:12 PM
Last edit: January 15, 2019, 10:02:03 PM by aliashraf
 #12

I wonder if anything like that has been discussed before. I felt somehow smarty when I came to this anyway.  Tongue
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.

Quote
Quote
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
Moderator
Legendary
*
qt
Online Online

Activity: 2660
Merit: 1995



View Profile
January 16, 2019, 01:44:43 AM
 #13

"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
Hero Member
*****
Offline Offline

Activity: 728
Merit: 586


View Profile
January 16, 2019, 07:43:52 AM
 #14

"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?

Quote
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?
Pages: [1]
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!