Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions

2015-01-16 Thread Thomas Kerin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It would - it assumes you have the set of keys and are sorting before
you derive and send funds to such a P2SH address.

It seems there is scope for further narrowing down how a multisig
scripthash address should be determined - what do people think of
anticipating only compressed keys for scripts?

It's possible to cause confusion if one put forward a compressed key at
some time, and an uncompressed key at another. A different script hash
would be produced even though there is no difference to the keys
involved. The client will not search for this.


Having spoken with Jean-Pierre and Ruben about this for quite some time
now, there is 100% the need for a BIP outlining this. Everyone has had
the idea at some point, and some of us already using it, but people
shouldn't have to go digging in BIP45 for the two lines which mention
it. All we need is a place to put the docs.

I am building up a list of implementations which currently support
sorting, and briefly describing a motivation for such a BIP.


On 16/01/15 10:16, Ruben de Vries wrote:
 Since we only need the sorting for creating the scriptPubKey,
 wouldn't it make the most sense to sort it by the way it represented
in that context?


 On Thu, Jan 15, 2015 at 2:03 PM, Wladimir laa...@gmail.com
mailto:laa...@gmail.com wrote:

 On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock
b...@mattwhitlock.name mailto:b...@mattwhitlock.name wrote:
  On Wednesday, 14 January 2015, at 3:53 pm, Eric Lombrozo wrote:
  Internally, pubkeys are DER-encoded integers.
 
  I thought pubkeys were represented as raw integers (i.e.,
they're embedded in Script as a push operation whose payload is the raw
bytes of the big-endian representation of the integer). As far as I
know, DER encoding is only used for signatures. Am I mistaken?

 OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a
 DER-encoded signature on the stack.

 Possibly you're confused with OP_HASH160 hash160 OP_EQUALVERIFY as
 used in outputs, which compares the 160-bit hash of the pubkey against
 the given hash (usually taken from a bitcoin address).

 It doesn't help understanding to consider either as integers. They are
 binary blob objects with either a fixed format (DER) or a fixed size
 (hashes).

 Wladimir




 --
 BlockTrail B.V.
 Barbara Strozzilaan 201
 1083HN Amsterdam
 The Netherlands

 Phone:+31 (0)612227277
 E-mail:ru...@blocktrail.com mailto:ru...@blocktrail.com
 Web:www.blocktrail.com
 http://www.blocktrail.com/
 Github:www.github.com/rubensayshi http://www.github.com/rubensayshi

 BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in
Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01



--
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

- -- 
Thomas Kerin
- -

My PGP key can be found here
http://pgp.mit.edu/pks/lookup?op=getsearch=0x3F0D2F83A2966155
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJUuT2EXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFV4GgP/Rr955cDBA34e58lLdjXkqzi
EYDH5QfsTdUQQVUvkK0OBq7RQwkbb7Kn5u6U8UD3hEhaWwQGhrQ/gOJrqM68glma
YfYupugMesTTu4Fxm/AtNv4Cifr29EZB1gu9hBeZGT4FL863+0ShvWHdHvscOcmg
3SGv0De+1bd93j7p+9jyWh/sYpHEdi0lQBMkkCzSzhXPZzoHEglUmVYBRcmrjaag
ycHuQfN5zjM0fJ18R6f7PCOOAhDi9+7xpikDArvHmKb4BZjOuMBTprN2Mzdg98Uz
Rw4LRsLuht5VCnWHvC8+TUUEMUO8QOMrRxLYJSDVGcl0XYXT0EiRfnkqCr5ab8mm
KqLcxpSLxrDGd4OiHwWB7oDsg9tWXwVmyQgFsTLsxaNkL8AFRG59mAhbK9j+0+1E
Bd/pMx0VgGXpn1Urism5YlrR4FZ5USbYn9O0NxhUkQb550qvRtaAQNUVSJPEW0AG
/2pQdFOOqkI1wI0g2L/ZcC+fwBqUok+5MyMTb4NuuvaMDpR7vOeeobIpYLjL0VVZ
dNzfnlCQxGw/7QrFIbvnye8fNIMZZ9qtJx00bvXYizRyUhrF/FrRgwj2DhEjz6xM
3+CHKXNmb0qGg6jKgHvXQFic2DVo3IaNmZtVDBqyqCBKmC/A65rRws5uxIimUsIC
k4af62ZBGpSAhJ4ajCIY
=Ni9V
-END PGP SIGNATURE-



0xA2966155.asc
Description: application/pgp-keys


0xA2966155.asc.sig
Description: PGP signature
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu

[Bitcoin-development] BIP for deterministic multisig addresses

2015-02-12 Thread Thomas Kerin
Not sure what happened there - I'll drop the PGP.


Hi all,

I have drafted a BIP with Jean Pierre and Ruben after the last
discussion, related to a standard for deriving a canonical
pay-to-script-hash address given a set of public keys and the number of
signatures required. There have been two or three discussions about it
on the mailing list to date, and various services already carry out this
process. I hope a BIP to describe this process will allow services to
declare themselves as BIPXX compliant, working towards interoperability
of services and simplifying the derivation of scripts and their
addresses by all parties.


  BIP: XX
  Title: Deterministic Pay-to-script-hash multi-signature addresses
through public key sorting
  Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
  Status: Draft
  Type: Standards Track
  Created: 8 February 2015

==Abstract==

This BIP describes a method to deterministically generate
multi-signature transaction scripts.  It focuses on defining how the
public keys must be encoded and sorted so that the redeem script and
corresponding P2SH address are always the same for a given set of keys
and number of required signatures.

==Motivation==

Most multi-signature transactions are addressed to P2SH
(pay-to-script-hash) addresses, as defined in BIP-0016.

Multi-signature redeem scripts do not require a particular ordering or
encoding for public keys.  This means that for a given set of keys and
number of required signatures, there are as many as 2(n!) possible
standard redeem scripts, each with its separate P2SH address.  Adhering
to a an ordering scheme and key encoding would ensure that a
multi-signature “account” (set of public keys and required signature
count) has a canonical P2SH address.

By adopting a sorting and encoding standard, compliant wallets will
always produce the same P2SH address for the same given set of keys and
required signature count, making it easier to recognize transactions
involving that multi-signature account.  This is particularly attractive
for multisignature hierarchical-deterministic wallets, as less state is
required to setup multi-signature accounts:  only the number of required
signatures and master public keys of participants need to be shared, and
all wallets will generate the same addresses.

While most web wallets do not presently facilitate the setup of
multisignature accounts with users of a different service, conventions
which ensure cross-compatibility should make it easier to achieve this.

Many wallet as a service providers use a 2of3 multi-signature schema
where the user stores 1 of the keys (offline) as backup while using the
other key for daily use and letting the service cosign his transactions.
This standard will help in enabling a party other than the service
provider to recover the wallet without any help from the service provider.

==Implementation==

For a set of public keys, ensure that they have been received in
compressed form, sort them lexicographically according to their binary
representation before using the resulting list of keys in a standard
multisig redeem script.  Hash the redeem script according to BIP-0016 to
get the P2SH address.

==Compatibility==

* Uncompressed keys are incompatible with this specificiation. A
compatible implementation should not automatically compress keys. 
Receiving an uncompressed key from a multisig participant should be
interpreted as a sign that the user has an incompatible implementation.
* P2SH addressses do not reveal information about the script that is
receiving the funds. For this reason it is not technically possible to
enforce this BIP as a rule on the network.  Also, it would cause a hard
fork.
* Implementations that do not conform with this BIP will have
compatibility issues with strictly-compliant wallets.
* Implementations which do adopt this standard will be cross-compatible
when choosing multisig addressses.
* If a group of users were not entirely compliant, there is the
possibility that a participant will derive an address that the others
will not recognize as part of the common multisig account.

==Test vectors==
The required number of signatures in each case is 2.

Vector 1
* List
** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
* Sorted
** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
* Script
**
522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae
* Address
** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z

Vector 2 (Already sorted, no action required)
* List:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
* Sorted

[Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses

2015-02-12 Thread Thomas Kerin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

I have drafted a BIP with Jean Pierre and Ruben after the last
discussion, related to a standard for deriving a canonical
pay-to-script-hash address given a set of public keys and the number of
signatures required. There have been two or three discussions about it
on the mailing list to date, and various services already carry out this
process. I hope a BIP to describe this process will allow services to
declare themselves as BIPXX compliant, working towards interoperability
of services and simplifying the derivation of scripts and their
addresses by all parties.


  BIP: XX
  Title: Deterministic Pay-to-script-hash multi-signature addresses
through public key sorting
  Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
  Status: Draft
  Type: Standards Track
  Created: 8 February 2015

==Abstract==

This BIP describes a method to deterministically generate
multi-signature transaction scripts.  It focuses on defining how the
public keys must be encoded and sorted so that the redeem script and
corresponding P2SH address are always the same for a given set of keys
and number of required signatures.

==Motivation==

Most multi-signature transactions are addressed to P2SH
(pay-to-script-hash) addresses, as defined in BIP-0016.

Multi-signature redeem scripts do not require a particular ordering or
encoding for public keys.  This means that for a given set of keys and
number of required signatures, there are as many as 2(n!) possible
standard redeem scripts, each with its separate P2SH address.  Adhering
to a an ordering scheme and key encoding would ensure that a
multi-signature “account” (set of public keys and required signature
count) has a canonical P2SH address.

By adopting a sorting and encoding standard, compliant wallets will
always produce the same P2SH address for the same given set of keys and
required signature count, making it easier to recognize transactions
involving that multi-signature account.  This is particularly attractive
for multisignature hierarchical-deterministic wallets, as less state is
required to setup multi-signature accounts:  only the number of required
signatures and master public keys of participants need to be shared, and
all wallets will generate the same addresses.

While most web wallets do not presently facilitate the setup of
multisignature accounts with users of a different service, conventions
which ensure cross-compatibility should make it easier to achieve this.

Many wallet as a service providers use a 2of3 multi-signature schema
where the user stores 1 of the keys (offline) as backup while using the
other key for daily use and letting the service cosign his transactions.
This standard will help in enabling a party other than the service
provider to recover the wallet without any help from the service provider.

==Implementation==

For a set of public keys, ensure that they have been received in
compressed form, sort them lexicographically according to their binary
representation before using the resulting list of keys in a standard
multisig redeem script.  Hash the redeem script according to BIP-0016 to
get the P2SH address.

==Compatibility==

* Uncompressed keys are incompatible with this specificiation. A
compatible implementation should not automatically compress keys. 
Receiving an uncompressed key from a multisig participant should be
interpreted as a sign that the user has an incompatible implementation.
* P2SH addressses do not reveal information about the script that is
receiving the funds. For this reason it is not technically possible to
enforce this BIP as a rule on the network.  Also, it would cause a hard
fork.
* Implementations that do not conform with this BIP will have
compatibility issues with strictly-compliant wallets.
* Implementations which do adopt this standard will be cross-compatible
when choosing multisig addressses.
* If a group of users were not entirely compliant, there is the
possibility that a participant will derive an address that the others
will not recognize as part of the common multisig account.

==Test vectors==
The required number of signatures in each case is 2.

Vector 1
* List
** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
* Sorted
** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
* Script
**
522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae
* Address
** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z

Vector 2 (Already sorted, no action required)
* List:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
* Sorted

Re: [Bitcoin-development] New BIP: protocol for multisignature payments

2015-01-30 Thread Thomas Kerin
Ooh, I had a very similar proposal, except it involved sharing generic P2SH 
scripts. It also involved facilitating requesting of signatures.. We should 
talk.On 31 Jan 2015 01:30, Martin Habovštiak martin.habovst...@gmail.com 
wrote:

 Hello, 

 I've been thinking about how to solve security problems of the servers 
 holding huge amounts of bitcoins (exchanges, markets...) and came up 
 with this idea: https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5 

 TL;DR: it's extension of BIP70 (but not fully compatible due to security 
 reasons) which supports making of multisig transactions dynamically. 
 (The most important thing is that the user provides his address.) 

 What do you think? Is it a good way to solve the problem or do you know 
 about something better? I would really like this or something similar 
 implemented by wallets. 

 Thank you for your feedback! 

 Martin

 --
  
 Dive into the World of Parallel Programming. The Go Parallel Website, 
 sponsored by Intel and developed in partnership with Slashdot Media, is your 
 hub for all things parallel software development, from weekly thought 
 leadership blogs to news, videos, case studies, tutorials and more. Take a 
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___ 
 Bitcoin-development mailing list 
 Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development 
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses

2015-02-13 Thread Thomas Kerin

On 12/02/15 22:13, Luke Dashjr wrote:
 Where is the Specification section?? Does this support arbitrary scripts, or 
 only the simplest CHECKMULTISIG case?

The BIP is a process for deriving only the type of scripts you would
encounter doing addmultisigaddress. More complicated scripts would
require more metadata to be shared, but the only case we describe is
when given public keys and the number of signatures required.

You're right, we're missing a Specification. I have tweaked the document
to cover this now.



On 13/02/15 07:53, Peter Todd wrote:
 It might be enough to rewrite this BIP to basically say all pubkeys
 executed by all CHECKMULTISIG opcodes will be in the following
 canonical order, followed by some explanatory examples of how to
 apply this simple rule. OTOH we don't yet have a standard way of even
 talking about arbitrary scripts, so it may very well turn out to be
 the case that the above rule is too restrictive in many cases - I
 certainly would not want to do a soft-fork to enforce this, or even
 make it an IsStandard() rule.

It would be interesting, but I agree it should not be brought into these
validation rules - just a convention for people to follow for now. I
think it's fair that implementers are free to order them however they
please. But I think there is good reason for wallets to opt in to the
convention and declare this, for ease of recovery, and for
interoperability reasons. 


-- 
Thomas Kerin


My PGP key can be found here 
http://pgp.mit.edu/pks/lookup?op=getsearch=0x3F0D2F83A2966155



0xA2966155.asc
Description: application/pgp-keys
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Thomas Kerin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

I just created a PR on bitcoin/bips for a proposed standard for creating
standard multisignature P2SH addresses given m, and a set of public keys.

https://github.com/bitcoin/bips/pull/146

I used BIP0090 as a place-holder, but I would like to request a BIP
number for this now.

All the best,

- -- 
Thomas Kerin
- -

My PGP key can be found here
http://pgp.mit.edu/pks/lookup?op=getsearch=0x3F0D2F83A2966155
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJVACrVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVkGgQAIUpyA3PsNjCA99W1HwFI7Ra
+g+JTtXBdhJSvVpv67TlaPZzp4LP7rRW/U1Nv0JYvhpQZTsV/xcMSKpy56d3S50M
Yvxwy51Aco1LEPC1vuiE2aJ8lDwCrXJMxJwfdBp6iNwf0huZNrsqZNKUHwMepePj
PYlGBkyfnp7QXo0ZkYBCJ2yerir5emKap3AibijRtkTrq6K1+YRk/9UZHllZSmmk
/B8n6xy/+v65uoAriVwKkX7H0bXmNTjleMzXbm/+Zhh9qfEnp2zqGmBIk5ooV5x4
3Flb76EYAMXibfAQ2+NPoCiPxCDIEWIsWqyzOC9zWX1QZN55qT3s/p7olYtaYheD
mf2xZ2pI/cIxpiYGfFEn4C/l0dOCNFLfElgsFcn4RsqRE41Grm+MGAPrf7S5bstp
TPIALOoVShucHaMvD/6sdK51hC54MKktNDtzTIumnWtOMwTy9qbELIcNvD8DaFe8
7FVZ7Vndj2FfXCNBF2EHzmy4D4+BE2YZ07pLQVUrc79oidUTs/099PsnUNOEYz0l
Y4IL/5qJMep9PJlj+IlbfXFX0zfTLJF7vJgjYMybr0iKP66iTtuHc46QFxTRyIhC
dMLXbSqm9X5zEc1j9Q50dSE5rqIT3/gkQe7nWFwf4xC7hlLAXSm8HuqwRSkZdP19
2byvsvoZ+4D4drXHXXpi
=QU8i
-END PGP SIGNATURE-

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-04-30 Thread Thomas Kerin
When dealing with any of the libraries or API's it's helps to know
what's going on under the hood. I find these pages to be invaluable.

https://en.bitcoin.it/wiki/Transactions
https://en.bitcoin.it/wiki/Protocol_specification
https://en.bitcoin.it/wiki/Script

On 30/04/15 11:28, Jorge Timón wrote:
 Well, if you're interested in learning java while learning bitcoin,
 probably you should be looking at https://github.com/bitcoinj/bitcoinj
 or one of its related project (like the android bitcoin wallet based
 on it).
 There's a getting sterted page: https://bitcoinj.github.io/#getting-started

 These links my be useful too:

 https://bitcoin.org/en/bitcoin-for-developers
 https://bitcoin.org/en/developer-documentation


 On Thu, Apr 30, 2015 at 11:35 AM, Telephone Lemien
 lemienteleph...@gmail.com wrote:
 Hello,
 I'm a beginner in Bitcoin and I want to know, what are things those allo me
 to understand Bitcoin protocol and make progress in java to become a good
 developper.
 Please tell me how I can begin.
 Best regards

 2015-04-30 10:08 GMT+02:00 Jorge Timón jti...@jtimon.cc:
 As Mike says it depends on your interests. But one thing that is almost
 always welcomed is improving the tests, and it is unlikely that it conflicts
 with other people's PRs (unless they're changing that part of the code and
 need to update those tests. Improving documentation is also good and you can
 do that while reading the code. Usually I just start cloning, compiling and
 changing things as I read, if I understand this correctly, this change
 should not break the tests, if I understand this, this other change should
 break the build, etc.
 But again, is up to you.

 On Apr 16, 2015 2:34 PM, Mike Hearn m...@plan99.net wrote:
 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_15utm_medium=emailutm_campaign=VA_SF
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

 --
 One dashboard for servers and applications across Physical-Virtual-Cloud 
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
Thomas Kerin


My PGP key can be found here 
http://pgp.mit.edu/pks/lookup?op=getsearch=0x3F0D2F83A2966155

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses

2015-05-22 Thread Thomas Kerin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I wonder are there any other blockers or modifications that need to be
made for this to be merged?

Latest version of the document:
https://github.com/afk11/bips/blob/213e8a27a3a2eaaf44f79221a9f9f888af002801/bip-0067.mediawiki



On 13/02/15 23:43, Thomas Kerin wrote:

 On 12/02/15 22:13, Luke Dashjr wrote:
 Where is the Specification section?? Does this support arbitrary
scripts, or
 only the simplest CHECKMULTISIG case?

 The BIP is a process for deriving only the type of scripts you would
encounter doing addmultisigaddress. More complicated scripts would
require more metadata to be shared, but the only case we describe is
when given public keys and the number of signatures required.

 You're right, we're missing a Specification. I have tweaked the
document to cover this now.



 On 13/02/15 07:53, Peter Todd wrote:
 It might be enough to rewrite this BIP to basically say all pubkeys
executed by all CHECKMULTISIG opcodes will be in the following canonical
order, followed by some explanatory examples of how to apply this
simple rule. OTOH we don't yet have a standard way of even talking about
arbitrary scripts, so it may very well turn out to be the case that the
above rule is too restrictive in many cases - I certainly would not want
to do a soft-fork to enforce this, or even make it an IsStandard() rule.

 It would be interesting, but I agree it should not be brought into
these validation rules - just a convention for people to follow for now.
I think it's fair that implementers are free to order them however they
please. But I think there is good reason for wallets to opt in to the
convention and declare this, for ease of recovery, and for
interoperability reasons.


 --
 Thomas Kerin
 -
 My PGP key can be found here
http://pgp.mit.edu/pks/lookup?op=getsearch=0x3F0D2F83A2966155



--
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media,
is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

- -- 
Thomas Kerin
- -

My PGP key can be found here
http://pgp.mit.edu/pks/lookup?op=getsearch=0x3F0D2F83A2966155
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQJ8BAEBCgBmBQJVX2ciXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVlOwP/1w/Omr/6jGyi7spqW22HQ7P
4+lNNzcsWp5/pv8e6YelUOSYiHuh/KxRoFfWL+wF+PNS2EtjRxSsXxg/R2nMft7B
JQLNmIG6zTzVg/lhVObeSslXaia7repZxZ1S4nyEcs8rDVt7kkNnNguFOeONF95O
3usCnrch+QbQacIt9StySAz155u1SuHeSmGmA/fRGLfArndXDdN0fYwE1KGyv5wm
LqZ1PQfmYaCc0TUKRvpDRuc/+KF7q1fDMzuP9mZ3WiPdvTDKCXSRxYfbQYJdxplg
AC0CFiOne+DXgiBdTOIcs9pcp1/6SyZs75Bkpv71AxBCmTlRTuYpsfH7O3VuZBGP
FrN/4BMYnzMbGnNmvZwerUKH59MmzZTAzLSwZlpvj7ZxRks6KOp1CHInFWQlHAXJ
O5c5McvqSdQ0rPHLcQ4DwB00Q1els18NRULjxdsTfLrT32birIXn3M1Hn/Q9d8Sa
N+Y/cfXkojf4rJt75+XwjLyHECwS378ZFC8lfs1m/B3VSQxTtTZWA8905a1IRv/F
nPQ2eaxBrFjm4OatE5lx+I/xmVAQuybG54UdcZGaKVXJbMg3sOslcYg7eA77pmR5
7jRoRU+q7GhiRsUmxSkD+57FfhaMzX7iUl4xe3YK14KUS/pONuv0USC9to8a62kA
gz9kb4pJMEhTtZNv7z9C
=iq37
-END PGP SIGNATURE-

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development