On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd wrote:
> Speaking of, can anyone think of an example of a complex transaction
> use-case that is affected by malleability which can't be fixed by
> CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head
> trying to think of a good example.
On Thu, Oct 09, 2014 at 06:28:19AM +, Gregory Maxwell wrote:
> On Thu, Oct 9, 2014 at 6:14 AM, Adam Back wrote:
> > I think you can do everything with the existing script level nlocktime
> > in some kind of turing completeness sense (maybe); but there is a
> > complexity cost that often you ha
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back wrote:
> I think you can do everything with the existing script level nlocktime
> in some kind of turing completeness sense (maybe); but there is a
> complexity cost that often you have to resort to extra dependent
> transaction(s) (and work-around malleab
I think you can do everything with the existing script level nlocktime
in some kind of turing completeness sense (maybe); but there is a
complexity cost that often you have to resort to extra dependent
transaction(s) (and work-around malleability until that is fully
fixed) just to get the effect.
By the way, I really like this proposal. I haven't spent much time
thinking about the deeper subtleties and risks associated with it, but I
see a lot of opportunities. One just came to mind that I didn't see
mentioned in his original proposal:
_Non-Interactive Recurring payments__with ID-associa
On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn wrote:
>> That is easy to change; I'll submit a pull request.
>
>
> That's certainly a useful improvement. It won't help the existing userbase
> though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release.
The next minor release (0.9.4) c
>
> Opinion: if a soft work works, it should be preferred, if for no other
> reason than once a hard-fork is planned, the discussion begins about
> what else to throw in. To minimize the frequency of hard-forks, the
> time for that is when the change being considered actually requires one.
I'm n
On 10/7/2014 8:50 AM, Gavin Andresen wrote:
>
> I don't have any opinion on the hard- versus soft- fork debate. I
> think either can work.
>
Opinion: if a soft work works, it should be preferred, if for no other
reason than once a hard-fork is planned, the discussion begins about
what else to t
>
> That is easy to change; I'll submit a pull request.
>
That's certainly a useful improvement. It won't help the existing userbase
though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major
release. If there's going to be an intermediate release (6 months?) which
lays the groundwork for
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn wrote:
>
>> Meanwhile, what I said *is* correct. New version numbers result in only
> a log print. Being hard forked off results in both log prints *and* the
> -alertnotify being run:
>
That is easy to change; I'll submit a pull request. It is a good id
>
> Anyway the stuff Mike is saying about being able to detect upgrades is
> incorrect - detecting an upgrade is *easier* with a soft-fork, just look
> at the block header nVersion numbers and warn the user if they increase
> beyond what you know is valid. Bitcoin Core implements this IIRC, and
> b
On Fri, Oct 03, 2014 at 07:12:11PM -0400, Jeff Garzik wrote:
> RE " It's not like other software where people can choose to skip an
> upgrade and things still work just like before."
>
> If you're a minority, sure you can. Still a few nutters out there on
> a 0.3.x codebase, including one or two
RE " It's not like other software where people can choose to skip an
upgrade and things still work just like before."
If you're a minority, sure you can. Still a few nutters out there on
a 0.3.x codebase, including one or two inattentive,
now-inconsequential miners.
There is some headroom built
Alright. It seems there's no real disagreement about how the opcode
behaves. Perhaps a time limit would be appropriate to stop people creating
outputs locked for 100 years is bitcoin even likely to exist in 100
years? The entire history of computing is not even that old, seems hard to
imagine
On Friday, October 03, 2014 2:28:17 PM Matt Whitlock wrote:
> Is there a reason why we can't have the new opcode simply replace the top
> stack item with the block height of the txout being redeemed? Then
> arbitrary logic could be implemented, including "output cannot be spent
> until a certain ti
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock wrote:
> Is there a reason why we can't have the new opcode simply replace the top
> stack item with the block height of the txout being redeemed?
This would not be soft-forking compatible.
It also would be unsafe in that it would result in transact
Oops, sorry. I meant: replace the top stack item with the block height of the
txin doing the redeeming. (So the script can calculate the "current time" to
some reference time embedded in the script.)
On Friday, 3 October 2014, at 10:28 am, Matt Whitlock wrote:
> Is there a reason why we can't h
Is there a reason why we can't have the new opcode simply replace the top stack
item with the block height of the txout being redeemed? Then arbitrary logic
could be implemented, including "output cannot be spent until a certain time"
and also "output can ONLY be spent until a certain time," as
Very good, I like the proposal.
A question I have: can it be used to do the opposite, i.e. build a script
that can only be spent up until block X?
On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 1 October 2014 17:55:36 GMT-07:00,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr wrote:
>On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
>> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr
>wrote:
>> >Thoughts on some way to have the stack item be incremented by t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen
wrote:
>Very nice, semantics are clear and use cases are compelling.
Thanks!
>Can we defer discussion of how to roll this out for a little bit, and
>see
>if there is consensus that:
>
>a) ben
On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr wrote:
> >Thoughts on some way to have the stack item be incremented by the
> >height at
> >which the scriptPubKey was in a block?
>
> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen
wrote:
>On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner
>wrote:
>No, the burner would supply the funding transaction plus the redeeming
>script as the proof-of-burn to whoever needed the proof.
N
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr wrote:
>Thoughts on some way to have the stack item be incremented by the
>height at
>which the scriptPubKey was in a block?
Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner wrote:
> On 10/01/2014 04:58 PM, Gavin Andresen wrote:
> > If the first transaction is P2SH, then the miner won't know there is
> > an advantage to holding it until it is too late (the scriptPubKey is
> > an opaque hash until the second transaction is f
On 10/01/2014 04:58 PM, Gavin Andresen wrote:
> If the first transaction is P2SH, then the miner won't know there is
> an advantage to holding it until it is too late (the scriptPubKey is
> an opaque hash until the second transaction is final and
> relayed/broadcast).
If you're doing some kind of
On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr wrote:
> houghts on some way to have the stack item be incremented by the height at
> which the scriptPubKey was in a block? A limitation of encoding the target
> height/time directly, is that miners may choose not to mine the first
> transaction until
On Wednesday, October 01, 2014 1:08:26 PM Peter Todd wrote:
> I've written a reference implementation and BIP draft for a new opcode,
> CHECKLOCKTIMEVERIFY.
Thoughts on some way to have the stack item be incremented by the height at
which the scriptPubKey was in a block? A limitation of encoding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Yeah, there are lots of "upper-level" details to consider; I'm not going to
pretend that BIP is complete yet. My thinking is that the first release should
include my NOPx blacklist pull-req, and leave NOP2/CHECKLOCKTIMEVERIFY in that
blacklist for
I like the proposal.
I suggest that applications and nodes should only broadcast transactions
having OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value.
If a node broadcasts a TX having OP_CHECKLOCKTIMEVERIFY and nLockTime is
equal to the current height and equal to the timeout value, but
Very nice, semantics are clear and use cases are compelling.
Can we defer discussion of how to roll this out for a little bit, and see
if there is consensus that:
a) benefits of having this outweigh risks
b) we're all happy with exact semantics
Then we can have a knock-down drag-out argument abo
I've written a reference implementation and BIP draft for a new opcode,
CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at:
https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki
The reference implementation, including a full-set of unittest
32 matches
Mail list logo
