Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XWV5v-0000ih-M2 for bitcoin-development@lists.sourceforge.net; Tue, 23 Sep 2014 18:45:47 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.44 as permitted sender) client-ip=209.85.216.44; envelope-from=etotheipi@gmail.com; helo=mail-qa0-f44.google.com; Received: from mail-qa0-f44.google.com ([209.85.216.44]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XWV5t-000755-Kg for bitcoin-development@lists.sourceforge.net; Tue, 23 Sep 2014 18:45:47 +0000 Received: by mail-qa0-f44.google.com with SMTP id x12so2122883qac.31 for ; Tue, 23 Sep 2014 11:45:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.36.197 with SMTP id p63mr2139576qgp.61.1411497939934; Tue, 23 Sep 2014 11:45:39 -0700 (PDT) Received: by 10.229.89.199 with HTTP; Tue, 23 Sep 2014 11:45:39 -0700 (PDT) Received: by 10.229.89.199 with HTTP; Tue, 23 Sep 2014 11:45:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Sep 2014 14:45:39 -0400 Message-ID: From: Alan Reiner To: Vitalik Buterin Content-Type: multipart/alternative; boundary=001a11c11cd44fa2de0503bff966 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XWV5t-000755-Kg Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 40, Issue 9 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 18:45:47 -0000 --001a11c11cd44fa2de0503bff966 Content-Type: text/plain; charset=UTF-8 Yes, we sort the keys at each address as well. But this isn't about key sorting, it's about assigning each device a different branch of the BIP 32 tree to avoid accidental address re use and to make it self evident which devices were used for each transaction in the overall wallet history. I only suggested sorting the root public keys as a way to assign which internal/external pair of chains the device should use. @Justus... Looking at the links you sent I'm not clear how it is related. And naming it "key voting pools" seems unrelated to why we are proposing this scheme. I'll need more than naked links to understand (I'm not saying it isn't related, I'm just not seeing the connection) -Alan Sent from my overpriced smartphone On Sep 23, 2014 2:25 PM, "Vitalik Buterin" wrote: > Have you looked at how Coinvault does it? They have a similar setup, but > sort the pubkeys at each address. > > On Tue, Sep 23, 2014 at 1:09 PM, < > bitcoin-development-request@lists.sourceforge.net> wrote: > >> Send Bitcoin-development mailing list submissions to >> bitcoin-development@lists.sourceforge.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> or, via email, send a message with subject or body 'help' to >> bitcoin-development-request@lists.sourceforge.net >> >> You can reach the person managing the list at >> bitcoin-development-owner@lists.sourceforge.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Bitcoin-development digest..." >> >> >> Today's Topics: >> >> 1. Re: Proposal: "No-Collision" mode for Multisig BIP32 Wallets >> (Justus Ranvier) >> 2. Re: Proposal: "No-Collision" mode for Multisig BIP32 Wallets >> (Alan Reiner) >> 3. Re: Proposal: "No-Collision" mode for Multisig BIP32 Wallets >> (Justus Ranvier) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 23 Sep 2014 16:37:20 +0000 >> From: Justus Ranvier >> Subject: Re: [Bitcoin-development] Proposal: "No-Collision" mode for >> Multisig BIP32 Wallets >> To: bitcoin-development@lists.sourceforge.net >> Message-ID: <5421A1C0.6080605@monetas.net> >> Content-Type: text/plain; charset="utf-8" >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 09/23/2014 04:16 PM, Alan Reiner wrote: >> > P.S. -- "No-Collision Mode" is not a great name. Happy to take >> > suggestions for changing it. >> >> I'd call it a "voting pool wallet", since that was the original >> application for this arrangement. >> >> Would be nice if you'd at least mention our work, since we did share >> it with you back in January and have been publicly documenting it ever >> since. >> >> Or does the fact that we're implementing it in btcwallet mean what >> we're working on is unmentionable here? >> >> - -- >> Justus Ranvier | Monetas >> | Public key ID : C3F7BB2638450DB5 >> | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc >> -----BEGIN PGP SIGNATURE----- >> >> iQEcBAEBCAAGBQJUIaHAAAoJEMP3uyY4RQ21nwoH/3MYi9JibblZYmSOvCT1vJrN >> Ih+Q2WNumIAI+Y9bh4bBgLuhnG5lXyHedhYEUW+mfuwGiX+92Uc47nwaWED2/Lte >> 4Zk/KZnwLifdWCgKLdGpW6mzksRiOaVyU4vV5JchVOrGZZ2zYNIq+NcChtCph7Y5 >> L202ReAG+1dfSpp4rFckuv7pTVjNcrq89UN1tJFDNQdxzIRd7bwoeCuvyFurZagB >> 88bNiOl0BI3e090WC+CWmbC6BfqJiicn/d0gp/agW01wy7CVbLypPPTKmYqt3+54 >> msLUgaRHcbjuyKqu8HMHpYtgYVSNFg2q+U4SgmEepzPAkQ97khbduqA6i1B0ULM= >> =t/xp >> -----END PGP SIGNATURE----- >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: 0x38450DB5.asc >> Type: application/pgp-keys >> Size: 14046 bytes >> Desc: not available >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 23 Sep 2014 12:48:34 -0400 >> From: Alan Reiner >> Subject: Re: [Bitcoin-development] Proposal: "No-Collision" mode for >> Multisig BIP32 Wallets >> To: bitcoin-development@lists.sourceforge.net >> Message-ID: <5421A462.6030205@gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 09/23/2014 12:37 PM, Justus Ranvier wrote: >> > Would be nice if you'd at least mention our work, since we did share >> > it with you back in January and have been publicly documenting it ever >> > since. >> > >> > Or does the fact that we're implementing it in btcwallet mean what >> > we're working on is unmentionable here? >> > >> >> Please don't assume poor intentions or sneaky motives. I get a lot of >> emails from a lot of people about a lot of things. Nine months ago was >> an eternity in this world, and it can't be ruled out that I simply forgot. >> >> I have no problem giving credit where it is due, and I mentioned in my >> first email that I wasn't sure if my stuff was original. Please >> recap/link it here so that it can be part of this discussion. >> >> - -Alan >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> >> iQIcBAEBAgAGBQJUIaRiAAoJEBHe6b77WWmFcBgP/2IiQWda5diBIrd8MjbtYz/X >> pF+B1zOipClil151pKN5h9f4CI75qwSBSG6pUS+QH1lCz97nr5AoVYV5SAaRzv0z >> L9Bz0PiHJFHd4IRbfuFqlPZB8mw2TMD7QWJx/1U+WmpnYYOGsUeJn25psIVZSRTU >> FTCsmYrA4cGZ4bZoUKI/eiXrHao8rm/zQ7QHKOMSFWZT57sNea67vlxPXKu+AkmK >> nEYa4hD0kD7/R/TrNcmRmOlmbqCnyjICd/yp8Lj26CdHPv3PAvaxUwSX3VhWPbdc >> UOiGeo+lXqRnBVpwMd+k7oFddwrc2k9ISRdUVsU86z3JdAXKl/dLS5UoOtfC1JA9 >> m90TuRtq4QuuzjLF3brI9FthuHNowA//qaVfjo/AYgsKy15td9UBtFbt4E9w263M >> NiFEmFkXfbE1JmIvmPG3AQEEdQ1/nmWiN5UcLrBfauEHMDQ1fGd89A8IBpus7bWM >> kYXboW3E9RBN4lB6OdyYU4AuH0YQhZodmry4iElMPox/tclmNiaeqDR8UYhD5BMd >> eQN9zAALyR1IY1167Ki/abVfWVf5jF7b0Eeu/wAfwcble3sCFrvWWAwzHjNi3GjY >> gNfy1eDTbwLj2M63QbtB+YqzQBZx3+SY4euGKYQ1s1CVV9ibAFI52oxeMhwzVOWF >> ofeDK5BPL8H+5L3tk+1o >> =tX2n >> -----END PGP SIGNATURE----- >> >> >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Tue, 23 Sep 2014 17:07:58 +0000 >> From: Justus Ranvier >> Subject: Re: [Bitcoin-development] Proposal: "No-Collision" mode for >> Multisig BIP32 Wallets >> To: bitcoin-development@lists.sourceforge.net >> Message-ID: <5421A8EE.4060300@monetas.net> >> Content-Type: text/plain; charset="utf-8" >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 09/23/2014 04:48 PM, Alan Reiner wrote: >> > Please recap/link it here so that it can be part of this >> > discussion. >> >> http://sourceforge.net/p/bitcoin/mailman/message/32736455/ >> >> http://opentransactions.org/wiki/index.php/Deposit_Address_(voting_pools) >> >> Currently being implemented here: >> >> https://github.com/monetas/btcwallet/commits/vp >> >> - -- >> >> Really what's so annoying is how the BIP numbering process is handled in >> such a way that proposals can be silently pigeonholed. >> >> Especially so in the case of an *informational* BIP which requires no >> action on anyone's part (except for not using the same BIP43 purpose >> code). >> >> We resolved this by changing the naming scheme for our proposals, and >> their associated purpose codes, to not rely on centrally-allocated >> numbers. >> >> https://github.com/Open-Transactions/rfc/tree/master/bips >> >> - -- >> Justus Ranvier | Monetas >> | Public key ID : C3F7BB2638450DB5 >> | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc >> -----BEGIN PGP SIGNATURE----- >> >> iQEcBAEBCAAGBQJUIajuAAoJEMP3uyY4RQ215dQH/1GNOmZd19/e2Ys7MNFx0gqz >> rDmTFBylU3lhJrMY4CDd4Duq5+2U7HgaovqgX8UqxquHWLQUwEzZLqdEPCifLg0c >> d/u90cRlClFAaOxPh4HV2/3aZoS2R27N+ZjOfziW7RZySBP/2fMt4/ra+SPbkcAQ >> oeplYgqMRDqW52C/o2zm4y4yb0TJPS+lzSNM+JfxHSPRyY55l0KzLJfUNz1RSOze >> A8UAwdsLiJROKPKiSrQcqFOejPV7uqSPh10ukm/AI0k8TbvX8ffGQ083394M9IuE >> DB/1eyeLQVP5+lQMWNrTHk3BQ75XBEDJoSukaRENcqxtHV2m1JzTWoS2CQBXi2M= >> =TwI3 >> -----END PGP SIGNATURE----- >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: 0x38450DB5.asc >> Type: application/pgp-keys >> Size: 14046 bytes >> Desc: not available >> >> ------------------------------ >> >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> >> ------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> End of Bitcoin-development Digest, Vol 40, Issue 9 >> ************************************************** >> > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a11c11cd44fa2de0503bff966 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, we sort the keys at each address as well.=C2=A0 But thi= s isn't about key sorting, it's about assigning each device a diffe= rent branch of the BIP 32 tree to avoid accidental address re use and to ma= ke it self evident which devices were used for each transaction in the over= all wallet history.=C2=A0 I only suggested sorting the root public keys as = a way to assign which internal/external pair of chains the device should us= e.

@Justus... Looking at the links you sent I'm not clear h= ow it is related.=C2=A0 And naming it "key voting pools" seems un= related to why we are proposing this scheme.=C2=A0 I'll need more than = naked links to understand (I'm not saying it isn't related, I'm= just not seeing the connection)

-Alan

Sent from my overpriced smartphone

On Sep 23, 2014 2:25 PM, "Vitalik Buterin&q= uot; <v@buterin.com> wrote:
Have yo= u looked at how Coinvault does it? They have a similar setup, but sort the = pubkeys at each address.

On Tue, Sep 23, 2014 at 1:09 PM, <bitcoin-development-request@lists.sourceforge.net> wrot= e:
Send Bitcoin-development mailing list = submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.sourceforge.n= et/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development-request@lists.s= ourceforge.net

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development-owner@lists.sourc= eforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Proposal: "No-Collision" mode for Multisig BI= P32 Wallets
=C2=A0 =C2=A0 =C2=A0 (Justus Ranvier)
=C2=A0 =C2=A02. Re: Proposal: "No-Collision" mode for Multisig BI= P32 Wallets
=C2=A0 =C2=A0 =C2=A0 (Alan Reiner)
=C2=A0 =C2=A03. Re: Proposal: "No-Collision" mode for Multisig BI= P32 Wallets
=C2=A0 =C2=A0 =C2=A0 (Justus Ranvier)


----------------------------------------------------------------------

Message: 1
Date: Tue, 23 Sep 2014 16:37:20 +0000
From: Justus Ranvier <justus@monetas.net>
Subject: Re: [Bitcoin-development] Proposal: "No-Collision" mode = for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Multisig BIP32 Wallets
To: bitcoin-development@lists.sourceforge.net
Message-ID: <5421A1C0.6080605@monetas.net>
Content-Type: text/plain; charset=3D"utf-8"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/23/2014 04:16 PM, Alan Reiner wrote:
> P.S. -- "No-Collision Mode" is not a great name.=C2=A0 Happy= to take
> suggestions for changing it.

I'd call it a "voting pool wallet", since that was the origin= al
application for this arrangement.

Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever
since.

Or does the fact that we're implementing it in btcwallet mean what
we're working on is unmentionable here?

- --
Justus Ranvier=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Monetas <h= ttp://monetas.net/>
<mailto:justus@m= onetas.net>=C2=A0 =C2=A0 =C2=A0 | Public key ID : C3F7BB2638450DB5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| BM-2cTepVtZ6AyJAs2Y8LpcvZB8K= bdaWLwKqc
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJUIaHAAAoJEMP3uyY4RQ21nwoH/3MYi9JibblZYmSOvCT1vJrN
Ih+Q2WNumIAI+Y9bh4bBgLuhnG5lXyHedhYEUW+mfuwGiX+92Uc47nwaWED2/Lte
4Zk/KZnwLifdWCgKLdGpW6mzksRiOaVyU4vV5JchVOrGZZ2zYNIq+NcChtCph7Y5
L202ReAG+1dfSpp4rFckuv7pTVjNcrq89UN1tJFDNQdxzIRd7bwoeCuvyFurZagB
88bNiOl0BI3e090WC+CWmbC6BfqJiicn/d0gp/agW01wy7CVbLypPPTKmYqt3+54
msLUgaRHcbjuyKqu8HMHpYtgYVSNFg2q+U4SgmEepzPAkQ97khbduqA6i1B0ULM=3D
=3Dt/xp
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available

------------------------------

Message: 2
Date: Tue, 23 Sep 2014 12:48:34 -0400
From: Alan Reiner <etotheipi@gmail.com>
Subject: Re: [Bitcoin-development] Proposal: "No-Collision" mode = for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Multisig BIP32 Wallets
To: bitcoin-development@lists.sourceforge.net
Message-ID: <5421A462.6030205@gmail.com>
Content-Type: text/plain; charset=3DISO-8859-1


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/23/2014 12:37 PM, Justus Ranvier wrote:
> Would be nice if you'd at least mention our work, since we did sha= re
> it with you back in January and have been publicly documenting it ever=
> since.
>
> Or does the fact that we're implementing it in btcwallet mean what=
> we're working on is unmentionable here?
>

Please don't assume poor intentions or sneaky motives.=C2=A0 I get a lo= t of
emails from a lot of people about a lot of things.=C2=A0 Nine months ago wa= s
an eternity in this world, and it can't be ruled out that I simply forg= ot.

I have no problem giving credit where it is due, and I mentioned in my
first email that I wasn't sure if my stuff was original.=C2=A0 Please recap/link it here so that it can be part of this discussion.

- -Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUIaRiAAoJEBHe6b77WWmFcBgP/2IiQWda5diBIrd8MjbtYz/X
pF+B1zOipClil151pKN5h9f4CI75qwSBSG6pUS+QH1lCz97nr5AoVYV5SAaRzv0z
L9Bz0PiHJFHd4IRbfuFqlPZB8mw2TMD7QWJx/1U+WmpnYYOGsUeJn25psIVZSRTU
FTCsmYrA4cGZ4bZoUKI/eiXrHao8rm/zQ7QHKOMSFWZT57sNea67vlxPXKu+AkmK
nEYa4hD0kD7/R/TrNcmRmOlmbqCnyjICd/yp8Lj26CdHPv3PAvaxUwSX3VhWPbdc
UOiGeo+lXqRnBVpwMd+k7oFddwrc2k9ISRdUVsU86z3JdAXKl/dLS5UoOtfC1JA9
m90TuRtq4QuuzjLF3brI9FthuHNowA//qaVfjo/AYgsKy15td9UBtFbt4E9w263M
NiFEmFkXfbE1JmIvmPG3AQEEdQ1/nmWiN5UcLrBfauEHMDQ1fGd89A8IBpus7bWM
kYXboW3E9RBN4lB6OdyYU4AuH0YQhZodmry4iElMPox/tclmNiaeqDR8UYhD5BMd
eQN9zAALyR1IY1167Ki/abVfWVf5jF7b0Eeu/wAfwcble3sCFrvWWAwzHjNi3GjY
gNfy1eDTbwLj2M63QbtB+YqzQBZx3+SY4euGKYQ1s1CVV9ibAFI52oxeMhwzVOWF
ofeDK5BPL8H+5L3tk+1o
=3DtX2n
-----END PGP SIGNATURE-----





------------------------------

Message: 3
Date: Tue, 23 Sep 2014 17:07:58 +0000
From: Justus Ranvier <justus@monetas.net>
Subject: Re: [Bitcoin-development] Proposal: "No-Collision" mode = for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Multisig BIP32 Wallets
To: bitcoin-development@lists.sourceforge.net
Message-ID: <5421A8EE.4060300@monetas.net>
Content-Type: text/plain; charset=3D"utf-8"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/23/2014 04:48 PM, Alan Reiner wrote:
> Please recap/link it here so that it can be part of this
> discussion.

http://sourceforge.net/p/bitcoin/mailman/message/32736455/

http://opentransactions.org/wiki/index.php/Dep= osit_Address_(voting_pools)

Currently being implemented here:

https://github.com/monetas/btcwallet/commits/vp

- --

Really what's so annoying is how the BIP numbering process is handled i= n
such a way that proposals can be silently pigeonholed.

Especially so in the case of an *informational* BIP which requires no
action on anyone's part (except for not using the same BIP43 purpose code).

We resolved this by changing the naming scheme for our proposals, and
their associated purpose codes, to not rely on centrally-allocated
numbers.

https://github.com/Open-Transactions/rfc/tree/master/bips<= br>
- --
Justus Ranvier=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Monetas <h= ttp://monetas.net/>
<mailto:justus@m= onetas.net>=C2=A0 =C2=A0 =C2=A0 | Public key ID : C3F7BB2638450DB5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| BM-2cTepVtZ6AyJAs2Y8LpcvZB8K= bdaWLwKqc
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJUIajuAAoJEMP3uyY4RQ215dQH/1GNOmZd19/e2Ys7MNFx0gqz
rDmTFBylU3lhJrMY4CDd4Duq5+2U7HgaovqgX8UqxquHWLQUwEzZLqdEPCifLg0c
d/u90cRlClFAaOxPh4HV2/3aZoS2R27N+ZjOfziW7RZySBP/2fMt4/ra+SPbkcAQ
oeplYgqMRDqW52C/o2zm4y4yb0TJPS+lzSNM+JfxHSPRyY55l0KzLJfUNz1RSOze
A8UAwdsLiJROKPKiSrQcqFOejPV7uqSPh10ukm/AI0k8TbvX8ffGQ083394M9IuE
DB/1eyeLQVP5+lQMWNrTHk3BQ75XBEDJoSukaRENcqxtHV2m1JzTWoS2CQBXi2M=3D
=3DTwI3
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available

------------------------------

---------------------------------------------------------------------------= ---
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D154622311&iu=3D/4140/ostg.clktrk

------------------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


End of Bitcoin-development Digest, Vol 40, Issue 9
**************************************************


-----------------------------------------------------------------------= -------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D154622311&iu=3D/4140/ostg.clktrk
__________________= _____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11c11cd44fa2de0503bff966--