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.
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back a...@cypherspace.org 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
On Thu, Oct 09, 2014 at 06:28:19AM +, Gregory Maxwell wrote:
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back a...@cypherspace.org 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
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd p...@petertodd.org 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
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 not
On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn m...@plan99.net 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
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
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn m...@plan99.net 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
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 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
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
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
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock b...@mattwhitlock.name 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
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 time
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 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
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 p...@petertodd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014
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
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,
-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
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
On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr l...@dashjr.org 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
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 5:04 PM, Alan Reiner etothe...@gmail.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@dashjr.org 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen gavinandre...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com
wrote:
No, the burner would supply the funding transaction plus the redeeming
script as the
On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@dashjr.org 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen gavinandre...@gmail.com
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
28 matches
Mail list logo
