From: Alan Reiner <etotheipi@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
Date: Sat, 12 Nov 2011 12:10:24 -0500 [thread overview]
Message-ID: <4EBEA880.7010608@gmail.com> (raw)
In-Reply-To: <CANEZrP2RrkJ-6A8fwhNX_xKYScrDqBYM1VgcoZFNLqX8GaQotQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]
Maybe I'm new to this, but this doesn't make any sense. I thought the
point of the BIP was to collaborate to come up with a good solution.
That's exactly what I want to do before I implement it in my software.
After all, they are "Bitcoin Improvement *Proposals*." It seems like
EXACTLY what a BIP is for... just no one needs/should use it until it
removes the "draft" marking.
As for the protocol on top of it, my BIP was not intended to address
that. It's only proposing how unsigned transactions can be serialized
and users can collect addresses. Whatever system you want to implement
on top of it to exchange the data is up to the developer. My only
motivation is that if the user clicks "Save this proposal to file", that
any client can use the resulting file, just the same way we serialize
any other blockdata that has a consistent representation.
-Alan
On 11/12/2011 11:58 AM, Mike Hearn wrote:
> Please don't create BIPs that don't have any actual implementation
> behind them. Design discussion is fine but the mailing list works for
> that.
>
> If I were going to implement escrow transactions in BitCoinJ it would
> not matter what was written here. I'd just implement the design I
> thought made sense. If that design was later adopted by others it can
> be documented and agreed upon in a BIP, just like a regular RFC.
>
> For what it's worth I would not attempt to send half-valid escrow
> transactions through the p2p network, not even using the overlay
> networks the protocol already supports. A correct escrow protocol
> requires the seller to challenge the dispute mediator with the public
> key to be sure they actually own it, and the simplest way to do that
> is to leverage the existing DNS/EV-SSL infrastructure with a "sign
> this nonce" HTTP request.
>
> BIPs should not be a place for people to come up with armchair
> designs, because a design with no corresponding implementation is
> likely to be full of problems. Let's revisit this once I can install
> some software on my laptop, my server, and a friends server, and do a
> 3-way mediated transaction between them.
[-- Attachment #2: Type: text/html, Size: 2828 bytes --]
next prev parent reply other threads:[~2011-11-12 17:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-09 10:22 Michael Grønager
2011-11-09 14:43 ` Alan Reiner
2011-11-09 15:22 ` Alan Reiner
2011-11-09 19:13 ` Gavin Andresen
2011-11-09 20:02 ` Gavin Andresen
2011-11-09 20:31 ` Michael Grønager
2011-11-09 21:18 ` Gavin Andresen
2011-11-09 21:32 ` Joel Joonatan Kaartinen
2011-11-09 22:13 ` theymos
2011-11-09 20:03 ` Michael Grønager
2011-11-10 3:00 ` Alan Reiner
2011-11-10 9:55 ` Michael Grønager
2011-11-10 12:56 ` Alan Reiner
2011-11-12 16:58 ` Mike Hearn
2011-11-12 17:10 ` Alan Reiner [this message]
2011-11-12 17:16 ` Mike Hearn
2011-11-12 17:25 ` Alan Reiner
2011-11-12 17:38 ` Mike Hearn
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=4EBEA880.7010608@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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