From: Gregory Maxwell <gmaxwell@gmail•com>
To: bgroff@lavabit•com
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Discussion related to pull 349 and pull 319 (escrow transactions)
Date: Thu, 4 Aug 2011 16:35:53 -0400 [thread overview]
Message-ID: <CAAS2fgQ6GXfebUV8_PLVpLJ9jvPF8FXiBqwquhGFNZ+Vt3uCtg@mail.gmail.com> (raw)
In-Reply-To: <43351.137.56.163.46.1312351847.squirrel@lavabit.com>
On Wed, Aug 3, 2011 at 2:10 AM, <bgroff@lavabit•com> wrote:
> Thank you! (I think you mean 319 here)
Correct.
> With Eligius mining !IsStandard transactions and probably other pools open
> to the idea, I am hopeful that we can quickly get 30%+ of mining power to
> upgrade, which means that we could still mine these in a reasonable time
> frame (under 1 hour).
It's not just a matter of mining power, it's also a question of
propagation. Matt and I tried to perform a non-standard transaction
weeks ago and weren't able to get in mined after many hours. (we
eventually double spent the input with a normal transaction in order
to make it go away, interestingly one point about non-propagating txn
is that they're extra vulnerable to double spending by a standard txn,
as the non-standard one won't preclude the propagation of the standard
one)
From discussion on IRC it seemed clear enough that the current focus
on maturity/bugfixes is probably going to delay your full patch, but
the IsStandard part is uncontroversial and could go in quickly.
Based on that I think it would be very useful to split 319 into two
pull requests: one which does the IsStandard change, and one which
adds the full escrow feature set. This way when the escrow patch does
enter the mainline client it will be meet up with a network which is
happy to handle its transactions.
(and people who are eager to use escrow can use modified clients on
the main network before that point in time)
> I'm not sure I see the problem here. CScript.operator<< currently inserts
> values into scripts using the shortest possible sequence.
Ah for some reason I thought your current code did not always produce
the shortest sequence.
If so, I see no reason to block on the other pull.
next prev parent reply other threads:[~2011-08-04 20:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-23 23:39 Gregory Maxwell
2011-08-03 6:10 ` bgroff
2011-08-04 20:35 ` Gregory Maxwell [this message]
2011-08-08 0:21 ` bgroff
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=CAAS2fgQ6GXfebUV8_PLVpLJ9jvPF8FXiBqwquhGFNZ+Vt3uCtg@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bgroff@lavabit$(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