Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
It is better if the scheme is strongly deterministic.On 16 Jan 2015 17:09, Alan Reiner etothe...@gmail.com wrote: I see no reason to restrict compressed/uncompressed. Strings don't have to be the same length to sort them lexicographically. If a multi-sig participant provides an uncompressed key, they are declaring that the key that they use and it will only be used uncompressed. Clients don't have to go looking for all combinations of compressed uncompressed. On 01/16/2015 11:34 AM, Thomas Kerin wrote: 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 -- 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 -- 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
Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
A public key is a point in the elliptic curve. As such it has an X and a Y component. Its serialization is described very succintly here: https://en.bitcoin.it/wiki/Protocol_specification#Signatures On 15/01/15 01:17, Matt Whitlock wrote: 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? -- Be Happy :) -- 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
Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
We in Haskoin do the same. On 14/01/15 17:39, devrandom wrote: At CryptoCorp we recommend to our customers that they sort lexicographically by the public key bytes of the leaf public keys. i.e. the same as BitPay. -- Be Happy :) -- 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
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Jean-Pierre Rupp from Haskoin here. I support a hard fork to fix consensus bugs. The Bitcoin protocol should eventually get to a state where it is documented in a clear and understandable fashion. Bugs are bugs, and are the enemy. We should not attempt to live with them. We should be opening a process of thoroughly documenting and reparing consensus bugs on a separate branch, and eventually schedule a hard fork. There are two good things that will come out of that: 1. Known bugs will be gone, and 2. We will have a process in place to get rid of future bugs in eventual future hard forks. We do not need to become paranoid about the ramifications of a hard fork, or how it will open the door for unwanted changes in the protocol. We are discussing about removing bugs, and bugs that could be used to exploit the network in ways that may not be immediately obvious. There are 144 blocks generated per day by groups of miners that are mostly identified. It is not going to be a titanic task to get consensus from the main mining pools on fixing this at the mining level. We must address how the fixes for some of these bugs affect other types of software such as wallets. I can think that fixing the bug where OP_CHECKMULTISIG pops an extra value from the stash could be more traumatic, since it requires anything that creates and validates multi-signature transactions to change the way it works. Hardware wallets could be impacted. But most of the consensus bugs would not affect the way the vast majority of bitcoin transactions that are currently created. Therefore it should not be traumatic at all for users, but only really affect mining pools, who would only need to be convinced to upgrade their bitcoind well in advance, which seems to me that it is not an issue at all. We should not compare doing a Bitcoin hard-fork with doing something like deploying IPv6 world-wide or enforcing TLS and SPF on every SMTP connection. We should not conflate Bitcoin with other network protocols. The Bitcoin protocol is actually relatively easy to upgrade at this point. Let's take advantage of this fact. On 06/11/14 15:36, Justus Ranvier wrote: Because Bitcoin has a extra consensus requirements, requirements which are really rare in engineering, the necessity of fixing bugs is even greater. -- Be Happy :) 0x310A8A5B.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
Hello people, We are working on some of this stuff. We had some very early draft on how we envisioned multisig happening. It is all implemented in Haskoin available as multiple repositories in Github. I am happy to see this gathering momentum. Our multisig system uses BIP-0032 HD wallets, and there will soon be BIP-0039 support for keys compatibility. Our wallet uses synced trees rooted at the extended pubkeys of the participants. Currently we are sorting public keys in the scripts to avoid ambiguity. Download haskoin-wallet: cabal install haskoin-wallet Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to bring transactions into the wallet. You must initialize first with a seed and create an account. It supports both regular and multisig accounts. Perhaps this can lead to interesting discussions on key exchange, and the appropriate handling of wallet metadata. Id love to work on a proper standard that could lead us to compatible implementations. This document explains how we do it now: http://haskoin.com/~xeno/hd-multisig-wallet.html Cheers! -- Be Happy :) 0xFF4BF34C.asc Description: application/pgp-keys 0xFF4BF34C.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] A better Spanish translation for vulnerability page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Una potencial falla de seguridad ha sido descubierta en Bitcoin-Qt para Windows. Si tienes Bitcoin-Qt para Windows en alguna versión entre 0.5 y 0.6, deberías salir del programa, y actualizar a la versión 0.5.3.1 o 0.6rc4 AHORA. La aplicación de línea de comandos (bitcoind), las versiones Mac y Linux de Bitcoin-Qt, y las versiones anteriores a 0.5 no están afectadas. Debido a la naturaleza de esta falla, creemos que sería muy difícil para un atacante hacer algo más que colgar (cerrar) el proceso de Bitcoin-Qt. Sin embargo, porque existe la posibilidad que un cierre inesperado permita la ejecución de código remoto, consideramos esto un incidente crítico. Si tienes alguna pregunta, visita el canal IRC #bitcoin-dev en Freenode. Puedes descargar el software actualizado desde SourceForge: 0.6rc [https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/] 0.5.3.1 para Windows y 0.5.3 para Linux [https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/] - -- Be Happy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9m4DYACgkQ77Wxq1L+vC74wgCfX4kF+BiKjO51UOgZmRib4kMP W6sAn016/jDXOfV/WeonqtqB3GuhzG+t =pqWY -END PGP SIGNATURE- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
