From: Toby Padilla <tobypadilla@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Key.run: BIP-70 Payments and OP_RETURN
Date: Mon, 7 Dec 2015 18:10:22 -0800 [thread overview]
Message-ID: <CAGcHOzy--AmRhBYveFF4Aq1dr=2oB4xuHVZPQnQV4kEXroLWXA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]
Hi all. I've been working on a new publication platform based on Bitcoin
called key.run: http://key.run
The high level overview is that key.run stores BitTorrent info hashes
(magnet links) in the blockchain by sending transactions to a "namespace"
Bitcoin address. Using SPV, I reconstitute the key.run db from the
blockchain. This is meant to be an open source and distributed system so
anyone can run the key.run server (and change namespace keys). More info
here: https://git.playgrub.com/toby/keyrun
Now to my issue...
One of the main use cases I wanted to support was people using their
*existing* Bitcoin wallet to encode the key.run transactions on the
blockchain. Practically speaking this meant building the transactions with
the proper OP_RETURN value server-side then passing them to the end user's
wallet via BIP-70. I have this working with Bitcoin Core (there are issues
with other wallets I've tested with BIP-70).
The problem I'm having is that Bitcoin Core will not allow BIP-70
PaymentDetails to contain outputs with zero value. As stated in
https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki:
"if there are more than one; Outputs with zero amounts shall be ignored"
Bitcoin Core doesn't seem to ignore the output though, it rejects the
transaction and doesn't allow the user to submit it. The key.run
transactions currently work by giving the OP_RETURN outputs a non-zero >
dust value. This value is presumably lost forever.
I think ideally OP_RETURN outputs with zero value WOULD be allowed since
they are valid transactions. Allowing OP_RETURN outputs to be constructed
with BIP-70 Payments is also the only way I can think of to extend the
functionality of existing wallets.
I would love to get feedback on if there is an alternative way to do what I
propose or ideally if BIP-70 could be tweaked to allow OP_RETURN outputs
with zero value.
I'd also love feedback on key.run but this probably isn't the best venue
for that. I've setup #keyrun on Freenode if anyone is interested in
discussing the project.
Regards,
Toby
--
http://twitter.com/toby
[-- Attachment #2: Type: text/html, Size: 2663 bytes --]
reply other threads:[~2015-12-08 2:10 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGcHOzy--AmRhBYveFF4Aq1dr=2oB4xuHVZPQnQV4kEXroLWXA@mail.gmail.com' \
--to=tobypadilla@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox