Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-12-04 📝 Original message:I wrote a little ...
📅 Original date posted:2014-12-04
📝 Original message:I wrote a little Javascript program
<https://github.com/bitcoinj/bitcoinj/blob/master/examples/src/main/javascript/payprotocol.js>;
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 <swansontec at gmail.com>
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 <luke at dashjr.org> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141204/0b9d3095/attachment.html>;
📝 Original message:I wrote a little Javascript program
<https://github.com/bitcoinj/bitcoinj/blob/master/examples/src/main/javascript/payprotocol.js>;
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 <swansontec at gmail.com>
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 <luke at dashjr.org> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141204/0b9d3095/attachment.html>;