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

[Jean-Pierre Rupp]

It is better if the scheme is strongly deterministic.On 16 Jan 2015 17:09, Alan 
Reiner  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 > > > wrote:
>>
>> > On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock > >> 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 
>> > Web:www.blocktrail.com
>> > 
>> > Github: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 co

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

[Jean-Pierre Rupp]

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

[Jean-Pierre Rupp]

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] Increasing the OP_RETURN maximum payload size

[Jean-Pierre Rupp]

Agree,

There are many legitimate uses for a larger OP_RETURN, and application 
developers are already complaining that the current size is not enough.  It is 
about adding value to the blockchain.  I know it can grow the blockchain 
faster, but so far at 40 bytes Bitcoin hasn't experienced death by bloat, nor 
that is even close to happen.  I understand starting with a prudent approach, 
but I think it is safe to increase this without worrying.  Actually I would 
make it even bigger than 80 bytes.

Cheers

On 17/11/14 02:30, Wladimir wrote:
> Agreed. I'm in favor of increasing OP_RETURN size as well. Don't care
> about the actual size.

-- 
Be Happy :)


0x310A8A5B.asc
Description: application/pgp-keys
<>--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
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]

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=154624111&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Feedback request: colored coins protocol

[Jean-Pierre Rupp]

By deciding to use a decentralized network to hold your assets, it may
make more sense to emit less shares. Two billion shares backed by
coloured coins makes less sense than a more conservative number, like
10,000. That costs a negligible amount of money, at least until the day
when Bitcoin takes over the world and a satoshi becomes very expensive.
But it is irrelevant now.

If you have already created a massive amount of shares for your company,
then the only reasonable solution is for a coloured coin to represent a
bundle of shares as Flavien suggested. Some shareholder could emit
another coloured coin instrument with a genesis block based on a smaller
set of shares to trade among smaller investors unwilling to deal in
terms of the bundled shares.

We need to understand that coloured coins provide benefits, but also has
constraints that are not difficult to live with.

On 10/04/14 13:19, Flavien Charlon wrote:
> By the way, padding doesn't solve the issue entirely (issuing 10 billion
> shares sill takes you 100 BTC, even with padding and 1 satoshi = 1
> share), so I am going for the solution where the asset quantity of every
> output is explicitly encoded in the OP_RETURN output. That way, whether
> you are issuing 1 share or 100 trillions, you never need to pay more
> than 540 satoshis.

-- 
haskoin.com


0xFF4BF34C.asc
Description: application/pgp-keys
<>

signature.asc
Description: OpenPGP digital signature
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Multisign payment protocol?

[Jean-Pierre Rupp]

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. I’d 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

[Jean-Pierre Rupp]

-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