I wrote a little Javascript program to print some minimal protobufs to base64. Result for a multisig output: Ik0SSRJHUiECpm1rIsOcaCf/CqL/YeqNXgcnQzb/+hfaawdi9u46xhEhAgoJfDU3M5mr++dfBG2gO5DiBiBVkVmLzjSLf26HEINeUq4YAA Result for a regular pay to address output: Ih8SGxIZdqkU4nFAzWDBp6LEi4uXgddL65H11nGIrBgA That is without any expiry time, which you'd want in practice. For an HD-iterating payment request you'd also need a few flags and fields, but a well designed protocol should only add a handful of bytes. The above strings are, I think, short enough to set as a username in a mining program so the general UX of Eligius can be maintained. How to generate them? That's not too hard. Building specialised one-off SPV wallets is quite easy these days with bitcoinj, there's a template app and a video tutorial on how to customise it available here: https://bitcoinj.github.io/simple-gui-wallet You can just copy/paste the code into a new directory and start modifying it. The final result is like Lighthouse - you run a program and get an EXE installer or MSI for Windows, a DMG for MacOS and a .deb for Linux (though a tarball would work just as well). So producing a little GUI that lets you build a base64 encoded payment protocol request that supports HD iteration for one or more keys, along with a little BIP70 extension that says "although this output is a multisig output, please actually create a p2sh output", would make a nice starter project for someone. It could also then act as a watching wallet and plot a graph of mining payouts over time, for example. If anyone wants to take this on let me know. I can help out with the final code signing steps to make Gatekeeper/Internet Explorer happy so don't worry about distribution. On Thu, Dec 4, 2014 at 6:25 PM, William Swanson wrote: > Yes. A few of us over here in San Diego actually started working on a > format like this a few months ago, but it's been on the back burner > for a while. > > Our motivation was to come up with a shared HD wallet format. Say I > would like create a 2-of-3 multisig wallet using my phone, PC, and > hardware key fob. All three devices would presumably be running > different wallet software, so we need some sort of standardized HD > multisig chain-description format that all three wallets can > understand. That way, regardless of their other differences, the > wallets can at least agree on how to generate new addresses. > > Of course, once you share this chain-description file with a third > party, they too can generate addresses out of the wallet. This can be > used for auditing (like for charities), for receive-only wallets (like > a merchant kiosk), and for recurring payments. The recurring payment > case is a little problematic, since you need to trust the payee with > your privacy. I imagine this would only be useful for payouts you > manage yourself, like a mining pool, and not something you share with > the general public. > > Our format is very similar to yours. We have a script template, just > like you do, but we describe the HD chains in a separate section > rather than in-line with the script. The script template only comes > into being once the chains have been gathered together into one place, > so the chain descriptions need to stand alone. > > Unfortunately, we still have a lot of details to work through before > we have a concrete proposal that's ready for this mailing list. > Perhaps we can work together to come up with something. > > -William > > On Thu, Dec 4, 2014 at 7:42 AM, Luke Dashjr wrote: > > Is anyone working on a serialisation format to convey P2SH HD chains? For > > example, to give someone who wants to make recurring payments a single > token > > that can be used to generate many P2SH addresses paying to a multisig > script. > > > > I'm thinking of something along the lines of a simple series of tokens, > each > > indicating either a HD chain or literal script content. For all HD > chains in > > the data, a child key would be generated based on the payment number, > and all > > tokens concatenated to form the P2SH serialised script. Eg, for a simple > 2- > > of-2, you would do something like this: > > literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG) > > Does this sufficiently cover all reasonable use cases? > > > > Luke > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >