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
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:
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
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
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
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
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
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:
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
12 matches
Mail list logo
