Luke Dashjr 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 block
Charlie 'Charles' Shrem 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:
https://github.com/rustyrussell/bi
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:
http://rustyrussell.github.io/pe
Gregory Maxwell writes:
> On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell 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&
Pieter Wuille 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 recent evens (see
Pieter Wuille 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 recent evens (see
Peter Todd writes:
> That said, if people have strong feelings about this, I would be willing
> to make OP_CLTV work as follows:
>
> 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 implemented as
> foll
Tier Nolan writes:
> On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell 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
> * 900kB soft limit
I
Tier Nolan writes:
> On Sat, May 16, 2015 at 1:22 AM, Rusty Russell
> 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 bl
Title: Canonical Input and Output Ordering
Author: Rusty Russell
Discussions-To: "Bitcoin Dev"
Status: Draft
Type: Standards Track
Created: 2015-06-06
Abstract
This BIP provides a canonical ordering of inputs and outputs when
creating transactions.
Motivation
Most bitc
Mark Friedenbach 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 inputs or outputs, not
Tier Nolan 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 than enough
> (
Gregory Maxwell writes:
> I'm not a great fan of this proposal for two reasons: The first is
> that the strict ordering requirements is incompatible with future
> soft-forks that may expose additional ordering constraints. Today we
> have _SINGLE, which as noted this interacts with poorly, but the
Mark Friedenbach writes:
> There's another important use case which you mentioned Greg, that also
> requires special exemption: compact commitments via mid-state compression.
>
> The use case is an OP_RETURN output sorted last, whose last N bytes are a
> commitment of some kind. A proof of the com
Kristov Atlas writes:
> Hello all,
>
> I have written a draft of a BIP to standardize the sorting of tx inputs and
> outputs for privacy and security reasons. A few colleagues have reviewed
> this and provided feedback privately, but now it's ready for feedback from
> a wider audience.
>
> If ther
Jorge Timón writes:
> On Jun 15, 2015 11:43 PM, "Rusty Russell" wrote:
>
>> Though Peter Todd's more general best-effort language might make more
>> sense. It's not like you can hide an OP_RETURN transaction to make it
>> look like somethi
16 matches
Mail list logo
