public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP - Selector Script
Date: Fri, 25 Apr 2014 21:02:41 +0100	[thread overview]
Message-ID: <CAE-z3OX5_POg9kFoz-LsGhuLRA6qFPcNXoECLhewe+o-+Pw2gA@mail.gmail.com> (raw)
In-Reply-To: <201404251917.49826.luke@dashjr.org>

[-- Attachment #1: Type: text/plain, Size: 3828 bytes --]

On Fri, Apr 25, 2014 at 8:17 PM, Luke-Jr <luke@dashjr•org> wrote:

> I believe you meant to link here instead?
>     https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki
>
> Yeah, sorry.


> This looks reasonable from a brief skim over, but does not define any use
> cases (it mentions "necessary for atomic cross chain transfers", but does
> not
> explain how it is useful for that - perhaps that belongs in another BIP you
> haven't written yet, though).


One use case should be enough.  The atomic cross chain proposal has been
discussed for a while.  It feels like bitcoin works on an "ask permission
first" basis.

It always stalls at the fact that non-standard transactions are hard to get
confirmed on other coins.  It is hard to find pools on other coins which
have weaker isStandard() checks.  The timeouts have to be set so that they
are long enough to guarantee that transactions are accepted before they
expire.

A testnet to testnet transfer is the best that would be possible at the
moment.

I don't think the cross chain system needs a BIP (except to justify this
one).

If cross chain transfer become popular, then it would be useful to ensure
that clients are interoperable, but first things first.  If the
transactions aren't accepted in any chains, then everything stalls.

Secure transfers require that the malleability issue is fixed, but that is
a separate issue.  I am assuming that will be fixed at some point in the
future, since micro-payment channels also requires that it is fixed.


> IMO, it should also require P2SH.
>

It could be restricted to only P2SH, I don't think there would be a loss in
doing that.

Personally, I would make it so that P2SH is mandatory after a certain
time.  It makes distributed verification of the block chain easier.
Everything needed to verify a script is present in the transaction (except
that the output actually exists).

A soft fork that expands P2SH functionality would be even better, but I
would rather not let the best be the enemy of the good.

>
>
> Luke
>
>
> On Friday, April 25, 2014 6:49:35 PM Tier Nolan wrote:
> > This is a BIP to allow the spender to choose one of multiple standard
> > scripts to use for spending the output.
> >
> > https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
> >
> > This is required as part of the atomic cross chain transfer protocol.  It
> > is required so that outputs can be retrieved, if the process ends before
> > being committed.
> >
> > https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
> >
> > The script allows multiple standard scripts to be included in the
> > scriptPubKey.
> >
> > When redeeming the script the spender indicates which of the standard
> > scripts to use.
> >
> > Only one standard script is actually executed, so the only cost is the
> > extra storage required.
> >
> > A more ambitious change would be a soft fork like P2SH, except the
> spender
> > is allowed to select from multiple hashes.  Effectively, it would be
> > "Multi-P2SH".
> >
> > This gets much of the benefits of MAST, but it requires a formal soft
> fork
> > to implement.
> >
> > If there is agreement, I can code up the reference implementation as a
> PR.
> > The multi-P2SH might actually be easier.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 5592 bytes --]

  parent reply	other threads:[~2014-04-25 20:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25 18:49 Tier Nolan
2014-04-25 19:17 ` Luke-Jr
2014-04-25 19:58   ` Peter Todd
2014-04-25 20:05     ` Tier Nolan
2014-04-25 20:02   ` Tier Nolan [this message]
2014-04-25 20:13     ` Gregory Maxwell
2014-04-25 20:26     ` Luke-Jr
2014-04-25 20:48       ` Tier Nolan
2014-04-26 17:00         ` Mark Friedenbach

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=CAE-z3OX5_POg9kFoz-LsGhuLRA6qFPcNXoECLhewe+o-+Pw2gA@mail.gmail.com \
    --to=tier.nolan@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.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