Comments in line:
> On May 8, 2015, at 11:08 PM, Peter Todd wrote:
>
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
>
> Right now pools already get DoSed all the time through their work
> submission systems; getting DoS at
We should make sure to consider how BIP34 affects normalized transaction ids,
since the height of the block is included in the scriptSig ensuring that the
txid will be different. We wouldn't want to enable replay attacks in the form
of spending coinbase outputs in the same way they were spent fr
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
On Friday, May 15, 2015 9:54:55 AM s7r wrote:
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays. This could
> work if we were using only one scriptPubKey per tx. But this is not
> enforced, ...
Assuming you mean o
On Fri, May 15, 2015 at 10:54 AM, s7r wrote:
> Hello,
>
> How will this exactly be safe against:
> a) the malleability of the parent tx (2nd level malleability)
>
The signature signs everything except the signature itself. The normalized
txid doesn't include that signature, so mutations of the
Hello,
How will this exactly be safe against:
a) the malleability of the parent tx (2nd level malleability)
b) replays
If you strip just the scriptSig of the input(s), the txid(s) can still
be mutated (with higher probability before it gets confirmed).
If you strip both the scriptSig of the pare
6 matches
Mail list logo
