Re: [Bitcoin-development] 75%/95% threshold for transaction versions

[s7r]

On 4/16/2015 8:34 PM, Mark Friedenbach wrote:
> At this moment anyone can alter the txid. Assume transactions are 100%
> malleable.
> 

Anyone can alter the txid - more details needed. The number of altered
txids in practice is not so high in order to make us believe anyone can
do it easily. It is obvious that all current bitcoin transactions are
malleable, but not by anyone and not that easy. At least I like to think so.

>From your answer I understand that right now if I create a transaction
(tx1) and broadcast it, you can alter its txid at your will, without any
mining power and/or access to my private keys so I would end up not
recognizing my own transaction and probably my change too (if my systems
rely hardly on txid)?

> On Apr 16, 2015 9:13 AM, "s7r" mailto:s...@sky-ip.org>>
> wrote:
> 
> Hi Pieter,
> 
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate
> things.
> 
> The problem I am trying to solve is making all transactions
> non-malleable by default. I guess there is a very good reason why BIP62
> will not touch v1 anyway.
> 
> I am trying to build a bitcoin contract which will relay on 3 things:
> - coinjoin / txes with inputs from multiple users which are signed by
> all users after they are merged together (every user is sure his coins
> will not be spent without the other users to spend anything, as per
> agreed contract);
> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
> before the inputs being spent are broadcasted/confirmed, using the txid
> provided by the user before broadcasting it. Malleability hurts here.
> - P2SH
> 
> In simple terms, how malleable transactions really are in the network at
> this moment? Who can alter a txid without invalidating the tx? Just the
> parties who sign it? The miners? Anyone in the network? This is a little
> bit unclear to me.
> 
> Another thing I would like to confirm, the 3 pieces of the bitcoin
> protocol mentioned above will be supported in _any_ future transaction
> version or block version, regardless what changes are made or features
> added to bitcoin core? The contract needs to be built and left unchanged
> for a very very long period of time...
> 
> 
> On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> >
> > On Apr 16, 2015 1:46 AM, "s7r"    >>
> > wrote:
> >> but for transaction versions? In simple terms, if > 75% from all the
> >> transactions in the latest 1000 blocks are version 'n', mark all
> >> previous transaction versions as non-standard and if > 95% from
> all the
> >> transactions in the latest 1000 blocks are version 'n' mark all
> previous
> >> transaction versions as invalid.
> >
> > What problem are you trying to solve?
> >
> > The reason why BIP62 (as specified, it is just a draft) does not
> make v1
> > transactions invalid is because it is opt-in. The creator of a
> > transaction needs to agree to protect it from malleability, and this
> > subjects him to extra rules in the creation.
> >
> > Forcing v3 transactions would require every piece of wallet
> software to
> > be changed.
> >
> > --
> > Pieter
> >
> 
> 
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

[Mark Friedenbach]

At this moment anyone can alter the txid. Assume transactions are 100%
malleable.
On Apr 16, 2015 9:13 AM, "s7r"  wrote:

> Hi Pieter,
>
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
>
> The problem I am trying to solve is making all transactions
> non-malleable by default. I guess there is a very good reason why BIP62
> will not touch v1 anyway.
>
> I am trying to build a bitcoin contract which will relay on 3 things:
> - coinjoin / txes with inputs from multiple users which are signed by
> all users after they are merged together (every user is sure his coins
> will not be spent without the other users to spend anything, as per
> agreed contract);
> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
> before the inputs being spent are broadcasted/confirmed, using the txid
> provided by the user before broadcasting it. Malleability hurts here.
> - P2SH
>
> In simple terms, how malleable transactions really are in the network at
> this moment? Who can alter a txid without invalidating the tx? Just the
> parties who sign it? The miners? Anyone in the network? This is a little
> bit unclear to me.
>
> Another thing I would like to confirm, the 3 pieces of the bitcoin
> protocol mentioned above will be supported in _any_ future transaction
> version or block version, regardless what changes are made or features
> added to bitcoin core? The contract needs to be built and left unchanged
> for a very very long period of time...
>
>
> On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> >
> > On Apr 16, 2015 1:46 AM, "s7r" mailto:s...@sky-ip.org>>
> > wrote:
> >> but for transaction versions? In simple terms, if > 75% from all the
> >> transactions in the latest 1000 blocks are version 'n', mark all
> >> previous transaction versions as non-standard and if > 95% from all the
> >> transactions in the latest 1000 blocks are version 'n' mark all previous
> >> transaction versions as invalid.
> >
> > What problem are you trying to solve?
> >
> > The reason why BIP62 (as specified, it is just a draft) does not make v1
> > transactions invalid is because it is opt-in. The creator of a
> > transaction needs to agree to protect it from malleability, and this
> > subjects him to extra rules in the creation.
> >
> > Forcing v3 transactions would require every piece of wallet software to
> > be changed.
> >
> > --
> > Pieter
> >
>
>
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

[s7r]

Hi Pieter,

Thanks for your reply. I agree. Allen has a good point in the previous
email too, so the suggestion might not fix anything and complicate things.

The problem I am trying to solve is making all transactions
non-malleable by default. I guess there is a very good reason why BIP62
will not touch v1 anyway.

I am trying to build a bitcoin contract which will relay on 3 things:
- coinjoin / txes with inputs from multiple users which are signed by
all users after they are merged together (every user is sure his coins
will not be spent without the other users to spend anything, as per
agreed contract);
- pre-signed txes with nLockTime 'n' weeks. These txes will be signed
before the inputs being spent are broadcasted/confirmed, using the txid
provided by the user before broadcasting it. Malleability hurts here.
- P2SH

In simple terms, how malleable transactions really are in the network at
this moment? Who can alter a txid without invalidating the tx? Just the
parties who sign it? The miners? Anyone in the network? This is a little
bit unclear to me.

Another thing I would like to confirm, the 3 pieces of the bitcoin
protocol mentioned above will be supported in _any_ future transaction
version or block version, regardless what changes are made or features
added to bitcoin core? The contract needs to be built and left unchanged
for a very very long period of time...


On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> 
> On Apr 16, 2015 1:46 AM, "s7r" mailto:s...@sky-ip.org>>
> wrote:
>> but for transaction versions? In simple terms, if > 75% from all the
>> transactions in the latest 1000 blocks are version 'n', mark all
>> previous transaction versions as non-standard and if > 95% from all the
>> transactions in the latest 1000 blocks are version 'n' mark all previous
>> transaction versions as invalid.
> 
> What problem are you trying to solve?
> 
> The reason why BIP62 (as specified, it is just a draft) does not make v1
> transactions invalid is because it is opt-in. The creator of a
> transaction needs to agree to protect it from malleability, and this
> subjects him to extra rules in the creation.
> 
> Forcing v3 transactions would require every piece of wallet software to
> be changed.
> 
> -- 
> Pieter
> 

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[Vertoe Qhor]

I'm supporting this proposal and since I'm already using the Encompass
wallet software I would like to highlight that this use case is not only
practical but has already a working reference implementation.

The only donwside I see is that it means we get yet another HD wallet
definition.

Is there anything else what would speak against assigning a BIP number
to this proposal? This would allow kefkius and his team to use the
standard in Encompass and share it with other software packages which
might be interested in using deterministic cross-currency wallets.

On 04/09/2015 10:16 PM, Kefkius wrote:
> William,
>
> I've amended the proposal's "Motivation" section slightly for
> clarification. I'm not sure how a "cosigner_index" branch would benefit
> this proposal. Granted, I don't fully understand the benefits of the
> "cosigner_index" branch in BIP-0045. From what I understand, the
> "wallet" branch of my proposal seems to accomplish a similar goal.
>
> Jona,
>
> Your explanation is correct. As for this being appropriate as a BIP, I
> agree that it's an arguable point to say it improves Bitcoin. However,
> this proposal exists because of BIP-0044, which also describes a
> multi-currency hierarchy. For that reason, I think this is an
> appropriate proposal.
>
> Thank you both for your feedback.
>
> On 04/08/2015 12:41 PM, William Swanson wrote:
>> Oops, sorry I missed that.
>>
>> Since that's the reason this proposal exists, I would consider putting
>> it right up top where people can see it. Also, since this proposal is
>> specifically designed for multi-sig, I would look at what BIP45 is
>> doing and maybe incorporate a "cosigner_index" branch. Otherwise, this
>> idea seems like a reasonable way to organize a wallet.
>>
>> -William
>>
>> On Wed, Apr 8, 2015 at 9:28 AM, 木ノ下じょな  wrote:
>>> William,
>>>
>>> I believe the reasoning for this is stated in the Coin Type section.
>>>
>>> "Public derivation is used so that cosigners need only know one of each
>>> other's public keys, rather than needing to distribute public keys for each
>>> coin."
>>>
>>> BIP44 has a coin level, but it's a private derived level, so cosigners would
>>> not be able to generate multiple crypto currencies of each others' without
>>> giving each other n xpubs where n is the number of currencies shared. This
>>> new proposal basically sticks coin type on the public derivation side of
>>> things so that I could generate litecoin or darkcoin multisigs without your
>>> permission...
>>>
>>> Kefkius,
>>>
>>> This BIP seems like a good fit for multi-currency wallets based on multisig.
>>> So kudos for putting it in writing.
>>>
>>> However, I don't know if this is really a BIP thing. It's not improving
>>> Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by definition
>>> it is improving altcoin usability.
>>>
>>> For that reason alone I will say I disagree for a BIP for this.
>>> - Jona
>>>
>>>
>>> 2015-04-08 16:46 GMT+09:00 William Swanson :
 It's not really clear why this is better than BIP 44 as it already
 stands. You have the same fields, but they are just in a different
 order. Couldn't you just use the existing BIP 44 hierarchy, but add
 the convention that "wallet/account N" is the same wallet in each
 supported currency?

 For example, if I have a wallet called "business expenses", which
 happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same
 wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5'
 for Litecoin.

 I am trying to think of examples where your proposal is better than
 BIP 44, but I can't think of any. Even backup recovery works fine. I
 assume that your idea is to continue iterating over the different
 wallet indices as long as you are finding funds in *any* currency.
 Well, you can still do that with BIP 44. The fields are in a different
 order, but that doesn't affect the algorithm in any way.

 Maybe you have some deeper insight I'm not seeing, but if so, you need
 to clearly explain that in your motivation section. The current
 explanation, "This limits the possible implementations of
 multi-currency, multisignature wallets," is pretty vauge. Also, there
 is nothing in this spec that addresses the multisignature use-case.
 The BIP 45 spec does a lot of extra work to make multisignature work
 smoothly.

 I'm not trying to criticize your proposal. I'm just trying to
 understand what it's trying to accomplish.

 -William Swanson


 On Wed, Apr 8, 2015 at 12:05 AM, Kefkius  wrote:
> I have a potential BIP, "Multi-Currency Hierarchy For Use In
> Multisignature Deterministic Wallets." I'm requesting discussion on it,
> and possibly assignment of a BIP number.
>
> It's located in this github gist:
> https://gist.github.com/Kefkius/1aa02945e532f8739023
>> ---

Re: [Bitcoin-development] Where do I start?

[Mike Hearn]

Hey Gabe,

That's diving into the deep end for sure! :)

> What are some current things that are lacking in Bitcoin core? Or am I
> better off making something else for the ecosystem?
>
That depends on your interests.

Many of the highest priority tasks in Bitcoin Core are rather complicated,
unfortunately, even for people with experience. You can consult the issue
tracker to get a feel for it.

Alternatively, there are lots of wallet apps out there and plenty of more
straightforward projects on them. However they may have less of a research
flavour.
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development