On Fri, Nov 28, 2014 at 11:45 AM, Flavien Charlon
wrote:
>> This breaks existing invariants and would make the coins potentially less
>> fungible because they wouldn't be reorg safe.
>
> I'm not sure coins are ever reorg safe. All it takes is a double spend in
> the history of your coins for them
> This breaks existing invariants and would make the coins potentially less
fungible because they wouldn't be reorg safe.
I'm not sure coins are ever reorg safe. All it takes is a double spend in
the history of your coins for them to become invalid after a reorg. Because
of that, there are already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 November 2014 18:46:23 GMT-05:00, Gregory Maxwell
wrote:
>The things you're suggesting were all carefully designed out of the
>proposal, perhaps the BIP text needs some more clarification to make
>this more clear.
It does; it is still a
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore wrote:
> Heya,
>
> I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and
> thought it might make more sense to instead have a OP_CHECKLOCKTIME which
> would simply push an OP_TRUE or OP_FALSE onto the stack?
Updating the stack is no
Heya,
I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and thought
it might make more sense to instead have a OP_CHECKLOCKTIME which would simply
push an OP_TRUE or OP_FALSE onto the stack?
That way someone could include multiple OP_CHECKLOCKTIME conditions in a single
script
5 matches
Mail list logo
