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
On Fri, Nov 28, 2014 at 11:45 AM, Flavien Charlon
flavien.char...@coinprism.com 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
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
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore m...@ricmoo.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 November 2014 18:46:23 GMT-05:00, Gregory Maxwell gmaxw...@gmail.com
wrote:
snip 100% accurate commentary from gmaxwell
The things you're suggesting were all carefully designed out of the
proposal, perhaps the BIP text needs some more
5 matches
Mail list logo
