Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses
-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=get&search=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=get&search=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
Re: [Bitcoin-development] Where do I start?
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 > 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 : >>> 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" 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_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 >>>> >>> >>> -- >>> 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-developmen
[Bitcoin-development] BIP for standard multi-signature P2SH addresses
-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=get&search=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] BIP for deterministic pay-to-script-hash multi-signature addresses
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=get&search=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 deterministic multisig addresses
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 * S
[Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses
-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
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 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] convention/standard for sorting public keys for p2sh multisig transactions
-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 mailto:laa...@gmail.com>> wrote: > > On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock 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 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=get&search=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 i
Re: [Bitcoin-development] New BIP32 structure
Isn't the length of the seed arbitrary anyway? Once decoded using whatever mnemonic implementation (electrums, or BIP0039) the bytestream is immediately passed to HMAC-SHA256 to generate the master key. No matter what your initial entropy is, it would be hashed anyway. On Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn wrote: > Ah, BIP32 allows for a range of entropy sizes and it so happens that they > picked 256 bits instead of 128 bits. > > I'd have thought that there is a right answer for this. 2^128 should not > be brute forceable, and longer sizes have a cost in terms of making the > seeds harder to write down on paper. So should this be a degree of freedom? > > > On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn wrote: > >> By the way, I just noticed that greenaddress.it is creating seeds that >> have 24 words instead of 12. Does anyone know what's up with that? They >> claim to be using BIP32 wallets so I wanted to see if they were using the >> default structure and if so, whether bitcoinj was compatible with it >> (before I switch to the one discussed here). But it seems we fall at the >> first hurdle ... >> >> >> On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin wrote: >> >>> >>> >>> Le 27/03/2014 12:30, Marek Palatinus a écrit : >>> > Ah, I forget to two things, which should be into the BIP as well: >>> > >>> > a) Gap factor for addresses; as Thomas mentioned, although some >>> software >>> > can watch almost unlimited amount of unused addresses, this is serious >>> > concern for lightweight or server-based wallets like Electrum or >>> > myTREZOR. myTREZOR currently uses gap factor 10, which is (from my >>> > experience so far) quite sane for most of users. >>> >>> >>> Yes, I was planning to increase the number of available unused addresses >>> to 10 or 20 in the bip32 version of Electrum. >>> >>> Related to this, here is another idea I would like to submit: >>> >>> Instead of using a "gap limit" (maximal number of consecutive unused >>> addresses), I think we should get rid of the topology, and simply count >>> the number of unused addresses since the beginning of the sequence. >>> Indeed, the topology of the sequence of addresses is of no interest to >>> the user. Users often misinterpret "gap limit" as the "number of unused >>> addresses available", so I think we should just give them what they want >>> :) This is easier to understand, and it makes things more predictable, >>> because the wallet will always display the same number of unused >>> addresses (except when it is waiting for confirmations). >>> >>> >>> >>> -- >>> ___ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >> >> > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
