Tier Nolan tier.no...@gmail.com writes:
What are the use cases for relative lock time verify? I have 1 and I think
that is the kind of thing it is useful for.
I think that most cases are just to guarantee that the other party has a
chance to react. This means that 8191 blocks should be more
Mark Friedenbach m...@friedenbach.org writes:
Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
assurance contracts among other things. Sometimes the ordering is set by
the signing logic itself...
Ah, I forgot about that particular wart. Yech. Implies that you can
order
Title: Canonical Input and Output Ordering
Author: Rusty Russell ru...@rustcorp.com.au
Discussions-To: Bitcoin Dev bitcoin-development@lists.sourceforge.net
Status: Draft
Type: Standards Track
Created: 2015-06-06
Abstract
This BIP provides a canonical ordering of inputs and outputs when
creating
Tier Nolan tier.no...@gmail.com writes:
On Sat, May 16, 2015 at 1:22 AM, Rusty Russell ru...@rustcorp.com.au
wrote:
3) ... or maybe not, if any consumed UTXO was generated before the soft
fork (reducing Tier's perverse incentive).
The incentive problem can be fixed by excluding UTXOs from
Tier Nolan tier.no...@gmail.com writes:
On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
An example would
be tx_size = MAX( real_size 1, real_size + 4*utxo_created_size -
3*utxo_consumed_size).
This could be implemented as a soft fork too.
* 1MB hard size limit
Peter Todd p...@petertodd.org writes:
That said, if people have strong feelings about this, I would be willing
to make OP_CLTV work as follows:
nLockTime 1 OP_CLTV
Where the 1 selects absolute mode, and all others act as OP_NOP's. A
future relative CLTV could then be a future soft-fork
Pieter Wuille pieter.wui...@gmail.com writes:
Hello everyone,
We've been aware of the risk of depending on OpenSSL for consensus
rules for a while, and were trying to get rid of this as part of BIP
62 (malleability protection), which was however postponed due to
unforeseen complexities. The
Pieter Wuille pieter.wui...@gmail.com writes:
Hello everyone,
We've been aware of the risk of depending on OpenSSL for consensus
rules for a while, and were trying to get rid of this as part of BIP
62 (malleability protection), which was however postponed due to
unforeseen complexities. The
Hi all,
I've been toying with an algorithm to place a ceiling on
confirmation latency by allowing weaker blocks after a certain time.
Hope this isn't noise, but thought someone must have considered this
before, or know of flaws in the scheme?
Gory details:
Gregory Maxwell gmaxw...@gmail.com writes:
On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Hi all,
I've been toying with an algorithm to place a ceiling on
confirmation latency by allowing weaker blocks after a certain time.
Hope this isn't noise
Charlie 'Charles' Shrem csh...@gmail.com writes:
Hey Rusty,
This is intriguing, do you have a writeup somewhere I can read more about ?
OK, ignore the FIXMEs, but I rehashed my stupid sim code, added some
graphs to the (clearly unfinished) paper and uploaded it to github:
Luke Dashjr l...@dashjr.org writes:
On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
Hi,
I thought a lot about the worst case scenario of SHA256d being broken in a
way which could be abused to
A) reduce the work of mining a block by some significant amount
B) reduce the work of mining a
12 matches
Mail list logo