Topic: Practical ways to store a redeem script for a P2SH address (Read 2063 times)

Because there are already bare multisig outputs. No reason to use p2sh & OP_RET

Yes and I feel the blockchain is not the right place to store my personal data. It's big enough as it is.

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

Why not ?

No, but thanks

OP_RETURN, seriously.

I asked a similar question a while [ago](https://bitcointalksearch.org/topic/m.8583616) 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.

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.

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.

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

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.

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?