Bitcoin Forum
September 23, 2021, 12:54:54 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Practical ways to store a redeem script for a P2SH address  (Read 2009 times)
edmundedgar
Sr. Member
****
Offline Offline

Activity: 352
Merit: 250


https://www.realitykeys.com


View Profile WWW
February 03, 2015, 01:36:12 AM
 #1

A lot of people out there are starting to do more interesting stuff with multi-sig, often involving multiple parties combining their keys in transactions to create a P2SH address.

When one of the parties comes to actually spend whatever's been sent to that P2SH address, they're going to need the original public keys to recreate the P2SH address, even if they don't actually need the corresponding private keys that would allow them to sign. So this information needs to be stored somewhere. We want this to be around even if whatever site may have helped set up the transaction has gone away, and it probably doesn't need to be secret, since it's ultimately going to show up on the blockchain anyway. I guess that implies we want it to be mirrored in several or more places, ideally run by a mix of different people in a mix of jurisdictions.

I know there are a bunch of clever data alt-coins and things in development, but has anyone got any suggestions for something practical we can use for a web app right now? We all love P2P but if there isn't a good fully P2P solution I think the "reasonably trustworthy vendor" model is OK here, as long as you have the data synced to reasonably diverse reasonably trustworthy vendors.

Basically I guess we're looking at an append-only public data storage for shortish bits of data. (I guess the fiddly bit is how you do anti-spam, since it's hard to squeeze "pay the data storage guy" in some of these workflows until you actually do the redeem.)

I know I'm not the first person to be feeling pain here - any suggestions for something that would be good to use, or if not any thoughts about what would be a useful thing to build?
1632401694
Hero Member
*
Offline Offline

Posts: 1632401694

View Profile Personal Message (Offline)

Ignore
1632401694
Reply with quote  #2

1632401694
Report to moderator
Visit and contribute to reddit.com/r/Bitcoin
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1632401694
Hero Member
*
Offline Offline

Posts: 1632401694

View Profile Personal Message (Offline)

Ignore
1632401694
Reply with quote  #2

1632401694
Report to moderator
1632401694
Hero Member
*
Offline Offline

Posts: 1632401694

View Profile Personal Message (Offline)

Ignore
1632401694
Reply with quote  #2

1632401694
Report to moderator
1632401694
Hero Member
*
Offline Offline

Posts: 1632401694

View Profile Personal Message (Offline)

Ignore
1632401694
Reply with quote  #2

1632401694
Report to moderator
hhanh00
Sr. Member
****
Offline Offline

Activity: 467
Merit: 261


View Profile
February 03, 2015, 07:15:43 AM
 #2

If all parties use HD wallets, you can use HDM. Then you don't have to remember the public keys that were used because you can regenerate them.

dabura667
Sr. Member
****
Offline Offline

Activity: 476
Merit: 251


View Profile
February 03, 2015, 04:59:59 PM
 #3

Most sane implementations of reliable multi-sig involve storing the extended public keys for HD chains for all parties, and using methods like BIP45 to deterministically generate and order the pubkeys.

Otherwise you'll just be storing tons of pubkeys.

As for specialized pubkey storage vendors... I don't think there's much of a use case, thus not much of a market.

Sucks being an innovator...

My Tip Address:
1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1013


Gerald Davis


View Profile
February 03, 2015, 05:34:49 PM
 #4

Yes I don't think a full P2P stack is a useful requirement at least not at this point.  A federated network of servers and an open protocol is all that is needed (i.e. a way for a third party to add a server to the network quickly and easily).  There is minimal security risk as the provider can't spoof data it can only fail to provide a lookup when requested (either because it is malicious or because the stored value has been lost).

The storage costs are relatively low.  Redeem scripts are limited to a max of 520 bytes.  Storing them in a key-value database would mean 520+20 bytes per record plus a small amount of database overhead.  That means greater than a million script records per GB of storage.  Storage costs would be reduced by using a DHT but for the forseable future I think that would just be needless complication.  I think the simplest way to handle spam would just be to either not accept a script submission until the scripthash appears in an output in the blockchain or to temporarily accept them but delete them after some reasonable amount of time if they don't appear in the blockchain.

You are probably ahead of your time but it is an interesting project.  I am not sure if leveldb (or any other open source key-value store) handles remote synchronization but it would seem a lightweight protocol could be developed.    Honestly this is probably something which makes sense to eventually be part of the Bitcoin protocol and stored by full nodes but in the interim a federated network sounds like a good idea.  This all assumes the network is created and run for altruistic reasons (or relying on donations). If you are talking about how to commercialize such a service well that is a little trickier, I agree with the previous poster than you probably a years ahead of any commercial demand.

As an alternative you could use the existing Bitcoin network by performing a sequential spend from the P2SH address back to itself.  For the cost of one transaction (which may be free if it is high priority) you have now stored the script in the blockchain permanently.

edmundedgar
Sr. Member
****
Offline Offline

Activity: 352
Merit: 250


https://www.realitykeys.com


View Profile WWW
February 03, 2015, 10:53:29 PM
 #5

If all parties use HD wallets, you can use HDM. Then you don't have to remember the public keys that were used because you can regenerate them.


In theory yes, but when multiple parties are involved you're at least going to need to store _something_ related to the other party, even if you've removed the need to store many things.

Deterministic wallets are actually making this problem more pressing, because if you already have to store and back up a bunch of random private keys then you presumably already have a process for storing and backing up new data, but nowadays people reasonably expect not to lose funds unless they lose their seed.
hhanh00
Sr. Member
****
Offline Offline

Activity: 467
Merit: 261


View Profile
February 04, 2015, 01:05:47 AM
 #6

If all parties use HD wallets, you can use HDM. Then you don't have to remember the public keys that were used because you can regenerate them.

In theory yes, but when multiple parties are involved you're at least going to need to store _something_ related to the other party, even if you've removed the need to store many things.

Deterministic wallets are actually making this problem more pressing, because if you already have to store and back up a bunch of random private keys then you presumably already have a process for storing and backing up new data, but nowadays people reasonably expect not to lose funds unless they lose their seed.
I asked a similar question a while [ago](https://bitcointalk.org/index.php?topic=761283.msg8583616#msg8583616) and people seemed fine with the extra storage needed. With multi sig boxes, the premise of not losing data because you have your seed no longer holds. After all, other people must not lose their seed either. I guess that you are now also required to store the master pub keys of all parties involved which are simply more seeds.

Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106
Merit: 1057


View Profile
February 04, 2015, 09:19:12 AM
 #7

OP_RETURN, seriously.

hhanh00
Sr. Member
****
Offline Offline

Activity: 467
Merit: 261


View Profile
February 04, 2015, 10:47:34 AM
 #8

OP_RETURN, seriously.
No, but thanks

samson
Legendary
*
Offline Offline

Activity: 2044
Merit: 1043


View Profile
February 07, 2015, 07:37:11 PM
 #9


Why not ?
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
February 08, 2015, 10:17:45 AM
 #10

OP_RETURN, seriously.

Isn't a script too big to fit in a standard OP_RETURN?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
hhanh00
Sr. Member
****
Offline Offline

Activity: 467
Merit: 261


View Profile
February 08, 2015, 10:35:12 AM
 #11

OP_RETURN, seriously.

Isn't a script too big to fit in a standard OP_RETURN?
Yes and I feel the blockchain is not the right place to store my personal data. It's big enough as it is.

amaclin
Legendary
*
Offline Offline

Activity: 1260
Merit: 1011


View Profile
February 08, 2015, 02:38:10 PM
 #12

Because there are already bare multisig outputs. No reason to use p2sh & OP_RET
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!