[Bitcoin-ml] bitcoin-ml Digest, Vol 6, Issue 15 - transaction malleability

Tom N thomascnolte at gmail.com
Mon Nov 13 18:06:39 UTC 2017 

Sorry for the silly question but my understanding was that no group or
mailing list consensus had been reach with regards to any alleged
transaction malleability fix. In similar fashion I thought discussion was
continuing regarding possible address changes.

Yet the prior message seems to negate my understanding. Have these things
again been decided upon unilaterally and are just being rolled out to the
community? I realize that it sounds like BU is in agreement with the abc
address change but where is this all being discussed or taking place?

I don't disagree that unilaterally implementing 'needed fixes' speeds up
the process, but can someone tell me what that process is? I do appreciate
the time and effort spent on this project but this feels like the daa
discussion and unilateral implementation all over again.

Maybe more teams or some sort of discussion outreach or or aspect is
needed. This is disappointing.

Tom N


On Nov 13, 2017 12:48 PM, <bitcoin-ml-request at lists.linuxfoundation.org>
wrote:

Send bitcoin-ml mailing list submissions to
        bitcoin-ml at lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
or, via email, send a message with subject or body 'help' to
        bitcoin-ml-request at lists.linuxfoundation.org

You can reach the person managing the list at
        bitcoin-ml-owner at lists.linuxfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-ml digest..."


Today's Topics:

   1. Is there a need to preempt scaling issues with Bitcoin
      Cash/BCC now? (Will M)
   2. Transaction Malleabilily Fixes (Lucas Clemente Vella)
   3. Re: Transaction Malleabilily Fixes (Jared Lee Richardson)
   4. Re: Transaction Malleabilily Fixes (Lucas Clemente Vella)
   5. Re: Is there a need to preempt scaling issues with Bitcoin
      Cash/BCC now? (Tom Harding)


----------------------------------------------------------------------

Message: 1
Date: Mon, 13 Nov 2017 08:03:55 -0700
From: Will M <will.madden at gmail.com>
To: bitcoin-ml at lists.linuxfoundation.org
Subject: [Bitcoin-ml] Is there a need to preempt scaling issues with
        Bitcoin Cash/BCC now?
Message-ID: <673d29d9-53d8-40d8-baad-6d1e6a0a8b0b at Spark>
Content-Type: text/plain; charset="utf-8"

BCC is taking off faster than most anticipated. That makes me concerned
about any ?magic numbers? (even defaults) that could be leveraged to stop
BCC from scaling on chain.

Some concerns/questions:

1. Could I sponsor a BCC dev. team, get lots of users, and then one day
refuse to increase the default 8MB limit that ships with my client?
Adjustable or otherwise, wouldn?t this have the same result as the 1MB
limit does with bitcoin legacy today?
2. Is the 32MB message size limit still lurking out there in BCC, and could
this become another blockade to scaling later on?

How difficult would it be to increase the default limit settings that ship
with the software at predetermined block heights now... just like BIP101/XT
used to do with max_block_size?

I would feel a lot better if the default limits on scaling increased ~40%
per annum, conservatively under long term efficiency increases we?ve seen
in broadband, storage, and processing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/
attachments/20171113/78daea6d/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 13 Nov 2017 13:15:38 -0200
From: Lucas Clemente Vella <lvella at gmail.com>
To: Bitcoin and related protocol coordination
        <bitcoin-ml at lists.linuxfoundation.org>
Subject: [Bitcoin-ml] Transaction Malleabilily Fixes
Message-ID:
        <CAGCathy-hh6sscYR8owJv5CeKaQmQsF2RWGnQSypPdnFxvB0hQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

According to November 13th hardfork specification in
https://gitub.com/Bitcoin-UAHF/spec/blob/master/nov-13-hardfork-spec.md
there will be adopted the measures from BIP-146 to prevent transaction
malleability problems.

Do you know if transaction malleability will still be possible? What are
the other sources of malleability?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/
attachments/20171113/db459f50/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 13 Nov 2017 07:29:09 -0800
From: Jared Lee Richardson <jaredr26 at gmail.com>
To: Lucas Clemente Vella <lvella at gmail.com>,    Bitcoin and related
        protocol coordination   <bitcoin-ml at lists.linuxfoundation.org>
Subject: Re: [Bitcoin-ml] Transaction Malleabilily Fixes
Message-ID:
        <CAD1TkXthu3bgyEoNVie3TXnZFH949VkgqvPXacKKptZtA57yhQ at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

It seems that some types of malleability can still be done.  The
person who created the transaction can still malleate it, though now
others cannot.

IMO this type of malleability also needs to be fixed with an optional
flag or setting.  There's no reason not to allow people to know that
their transactions can't be malleated so they can use things like
lightning; Bitcoin Cash is in no danger of forcing people to use
lightning though high fees, it should become an optional tool for the
use cases that do want it.  There's many use cases that can benefit
from Lightning's advantages even though it isn't a scaling solution.

On Mon, Nov 13, 2017 at 7:15 AM, Lucas Clemente Vella via bitcoin-ml
<bitcoin-ml at lists.linuxfoundation.org> wrote:
> According to November 13th hardfork specification in
> https://gitub.com/Bitcoin-UAHF/spec/blob/master/nov-13-hardfork-spec.md
> there will be adopted the measures from BIP-146 to prevent transaction
> malleability problems.
>
> Do you know if transaction malleability will still be possible? What are
the
> other sources of malleability?
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>


------------------------------

Message: 4
Date: Mon, 13 Nov 2017 15:18:12 -0200
From: Lucas Clemente Vella <lvella at gmail.com>
To: Jared Lee Richardson <jaredr26 at gmail.com>
Cc: Bitcoin and related protocol coordination
        <bitcoin-ml at lists.linuxfoundation.org>
Subject: Re: [Bitcoin-ml] Transaction Malleabilily Fixes
Message-ID:
        <CAGCathxuMVzufvnyRatkLwPQh3-kG=pvR3CMkq3yD_=n_up-Ew at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2017-11-13 13:29 GMT-02:00 Jared Lee Richardson <jaredr26 at gmail.com>:

> It seems that some types of malleability can still be done.  The
> person who created the transaction can still malleate it, though now
> others cannot.
>

And how transaction malleated by the signing party is worse from an
ordinary double spend? It is only a bigger problem if any signer can do it
independently from the other in a multisig transactions, is this the case?


> IMO this type of malleability also needs to be fixed with an optional
> flag or setting.  There's no reason not to allow people to know that
> their transactions can't be malleated so they can use things like
> lightning; Bitcoin Cash is in no danger of forcing people to use
> lightning though high fees, it should become an optional tool for the
> use cases that do want it.  There's many use cases that can benefit
> from Lightning's advantages even though it isn't a scaling solution.
>

An opt-in solution increases complexity, and that is precisely what is
precisely what segwit does. That is one of the reasons I dislike it: it
requires from anyone who doesn't want their transactions malleated to
change their software systems in order to forbid it. I assume the vast
majority would simply prefer their transactions not to be malleated, so
that should be the default. If someone do require transaction malleability,
for whatever reason I can't imagine, that should be the one required to
opt-in. That said, I don't believe such hypothetical need is worth the
increased complexity of simply getting rid of malleability once and for all.

--
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/
attachments/20171113/0577ce19/attachment-0001.html>

------------------------------

Message: 5
Date: Mon, 13 Nov 2017 09:48:16 -0800
From: Tom Harding <tomh at thinlink.com>
To: bitcoin-ml at lists.linuxfoundation.org
Subject: Re: [Bitcoin-ml] Is there a need to preempt scaling issues
        with Bitcoin Cash/BCC now?
Message-ID: <57f1ba47-724c-ea61-9940-41b702c6cfe1 at thinlink.com>
Content-Type: text/plain; charset="windows-1252"

Hi Will, this is the situation as far as I know.

BU relies on emergent consensus (EC). Miners and nodes signal their
preferences and enforce them through local rules.

ABC has a static 8MB limit. There is a set of open tasks to implement
emergent consensus (EC).

XT has an 8MB limit and implements BIP100, a deterministic algorithm
based on miner signals in the chain.
https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki

To answer your questions directly,
? 1. Yes, you could do it. The result depends on network acceptance of
your rules.
? 2. I wouldn't worry about implementation-specific limits like the 32MB
message size (except maybe as they affect any future deliberation of
consensus changes).


On 11/13/2017 7:03 AM, Will M via bitcoin-ml wrote:
> BCC is taking off faster than most anticipated. That makes me
> concerned about any ?magic numbers? (even defaults) that could be
> leveraged to stop BCC from scaling on chain.
>
> Some concerns/questions:
>
>  1. Could I sponsor a BCC dev. team, get lots of users, and then one
>     day refuse to increase the default 8MB limit that ships with my
>     client? Adjustable or otherwise, wouldn?t this have the same
>     result as the 1MB limit does with bitcoin legacy today?
>  2. Is the 32MB message size limit still lurking out there in BCC, and
>     could this become another blockade to scaling later on?
>
> How difficult would it be to increase the default limit settings that
> ship with the software at predetermined block heights now... just like
> BIP101/XT used to do with max_block_size??
>
> I would feel a /lot/ better if the default limits on scaling increased
> ~40% per annum, conservatively under long term efficiency increases
> we?ve seen in broadband, storage, and processing.?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/
attachments/20171113/87fb3ac5/attachment.html>

------------------------------

_______________________________________________
bitcoin-ml mailing list
bitcoin-ml at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml


End of bitcoin-ml Digest, Vol 6, Issue 15
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171113/10e9eaa7/attachment-0001.html>

More information about the bitcoin-ml mailing list