Re: [Bitcoin-development] Payment protocol and reliable Payment messages
On 01/13/2014 06:56 PM, Pieter Wuille wrote: I want to avoid the case where a transaction confirms, but the associated payment is not delivered. If there is a reasonable chance that this case occurs in normal operation, it means the payment transmission cannot be relied upon. I was thinking about this some more. Generally I think you have a point. However, there is one case I'm worried about. Imagine you get a good offer (payment request) from a merchant. You would like to accept that offer, however the merchant has changed his mind. If you don't broadcast the payment to the blockchain, you won't have a chance to accept and legally bind the offer. The merchant will silently discard your payment messages. At some point, you will involve a judge. If you can present the payment request and the payment from the block chain, you're in a much better position than if you just present a request but no confirmed payment. I think in some cases you might want to broadcast your txn to the P2P network, even if the payment messages get lost. What do you think? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
On 01/14/2014 11:45 AM, Mike Hearn wrote: Imagine you get a good offer (payment request) from a merchant. You would like to accept that offer, however the merchant has changed his mind. Usually if the merchant has not delivered, then at that point it's not a problem and he is allowed to change his mind. It's only if they change their mind *after* you pay that it's a problem, right? It was my understanding of the spec that a payment request is legally binding one side for the specified amount of time. Basically I offer you to sell you these 10 eggs (described in the memo) for this amount if you accept until this time. I have even signed this so you can know its me who made you the offer. If you accept (by paying), the contract is valid and there should be nothing I can do about it (except for extreme cases which are covered by law already). Actually what good is the payment request if its not binding? Why do we have an expiry time in the message? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
He's probably thinking of fair advertising rules. There are regulations motivated by consumer protection/advertising standards (prevents merchant listing attractive prices in media, and then when consumer goes to pay the merchant says oh actually that doesnt include X and Y, and the minimum price is 10% more after the user has already partly committed to the purchase. Ryanair, an airline near and dear to Europeans ;) is infamous for aggressive use of such tactics. Or worse systematic abuse of sorry that was a pricing mistake. In trading situations its even more important, you're facing a dynamic price, and revocable bids after acceptance but before payment allow system gaming. There were court cases about such things and trading systems gamed. So I think this is the use case to consider. Payment request is an offer, payment message is an acceptance, transaction broadcast is settlment. After acceptance the asker must not be allowed to retract ther ask. Going back to Pieter's comment it seems there are two approaches: i) send payment message to merchant, merchant broadcasts tx to network to claim funds; ii) user broadcasts tx, and sends payment message to merchant. In case i) the user is relying on the merchant in terms of retraction, for many use-cases that doesnt matter, or consumer law says they can do that in some places. Though transferable proof the merchant is systematically retracting advertised offers could be indirectly useful as it maybe evidence of unfair trading, which can result in censure for the merchant! In case ii) I think Andreas has a point. Maybe the way to do that is to also bind the transaction to the payment message. Eg include the hash of the payment message in the tx (circular ref may have to use multisig approach?), or as Timo Hanke's paper where the offer/acceptance contact hash is bound to the address (ie the address paid is Q'=H(Q+H(contract)G). Adam On Tue, Jan 14, 2014 at 11:45:59AM +0100, Mike Hearn wrote: Imagine you get a good offer (payment request) from a merchant. You would like to accept that offer, however the merchant has changed his mind. Usually if the merchant has not delivered, then at that point it's not a problem and he is allowed to change his mind. It's only if they change their mind *after* you pay that it's a problem, right? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote: It's a given this will be implemented for Payment Protocol. The question is whether it's also usable outside of PP. I think what stealth addresses is showing is that the concept of an address being instructions on how to generate a txout/tx that results in me getting Bitcoins is actually quite valuable; it and BIP32-derivation addresses with chaincodes are pretty clear cases where just replacing address with scriptPubKey isn't sufficient. I was kind of imagining that we could encourage people to replace all their static address text that live on Github pages, and README.me, and forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention could be to require only transporting xSTL addresses within a URI, even going so far as to not support them copy/pasted. 101 characters is not much longer (and sometimes shorter) than PaymentRequest URIs end up being. Yeah, I don't see anything wrong with stealth addresses whatever length they wind up being. It's a good intermediate step, and without them people will just pass around unsigned payment requests and other stuff. I think there are ways to make stealth addresses easy enough to use that people actually prefer using them for P2P payments which do not involve a full-stack merchant. In that case, if it was a PaymentRequest it would almost certainly not be signed, and would be more easily shared over email or SMS as a URI than as a file attachment or, even worse, putting the unsigned PR file up on a third-party server which probably won't do a good job securing it. At the DarkWallet hackathon we had discussed how to integrate stealth addresses into OpenPGP keys as a new user id type for instance, and similarly into x.509 certs. The big advantage here is the identity of *who* you are paying is important, not just I got this signed payment request. Basically the concept becomes identity signed payment address and the signature binding the identity to the address is a one time and offline thing; an issue with the payment protocol as it stands is that it encourages signing keys to be kept online to issue payment requests. If you have a scheme where the private keys that bound the identity to the address can be kept offline you're much better off, because the attacker can only create a fake payment request, they can't divert the funds to themselves. So with that in mind, I strongly suggest sticking with defining a reasonable stealth address spec. But when you do, keep in mind that you may want to upgrade it in the future, preferably in a backwards compatible way. Also, it shouldn't be limited to exactly 2-of-2 CHECKMULTISIG, there's no reason why n and m can't be picked as needed. Sure, it means the addresses are not fixed length, but for something that is mostly an internal detail and only occasionally visible to advanced users, I see no issues there. Along those lines: what would a BIP32 chain code address look like? What happens when you want to use that with a multisig-protected wallet? * PP Implementation Overview * The basic PaymentRequestPaymentDetails is expecting 'output' containing one or more TxOuts with script and amount. I believe the general approach is to put a fallback address into 'output' for backward compatibility, and put Q and Q2 into an extension field. So we add a new optional field to PaymentDetails which contains the one or two PubKeys. Not sure if we want different protobuf tags, or if the difference in length of the value makes it obvious enough which approach is being used; optional bytes stealthOnePubKey = 1000 optional bytes stealthTwoPubKey = 1001 I think you're missing the bigger picture here, not least of which is that backwards compatibility is a bit of a misnomer for an unreleased standard. :) Why put this into the PaymentDetails? That a stealth address is to be used for the payment is a property of the outputs being requested, not the payment itself. We're better off if that goes into the Output message, and further more it suggests that the Output message shouldn't contain raw scriptPubKey's but rather addresses. After all, IsStandard() means we have to inspect the scriptPubKey to see if we can even pay to what the sender is requesting. Once you establish that it's addresses that Outputs specify, then it's easy enough to make a stealth address type, or a BIP32-chain-code address type, or whatever else comes up in the future. Also, ideally I think I would want multiple different stealth payments within a single wallet to the same merchant / pubkeys to be identifiable as such. Agreed. -- 'peter'[:-1]@petertodd.org bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Re: [Bitcoin-development] Stealth Addresses
On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote: Uh while I'm responding again, what I'd discussed with Peter Todd in IRC used two EC points in the stealth address. One for the payment and one for the ECDH. The reason to use two is that it makes delegating detection possible and so you don't have to have you spending keys online to even detect these payments. Why'd that get dropped? I think this is exactly what I've implemented. I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping one of the pubKeys in the OP-RETURN, to prevent a malicious sender from triggering false positives on your online detection key when the funds are actually still fully controlled by the payer. You can still have a false positive (only 1 of 2 keys actually yours) but the funds would be trapped so it's unlikely anyone would do it. How would they trigger false positives? The payee recovers the nonce with ECDH from the payor's ephemereal pubkey and their online detection secret key. They use BIP32 public derivation with their offline spending pubkey(s), if the derived pubkeys match the actual scriptPubKey they know the output is spendable by them. I don't see how that can go wrong. -- 'peter'[:-1]@petertodd.org 7dd7a87aec311fb7fb13770f54edf628e6976f8c6091a5b2638878a7 signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
Hello Peter et. al. As I read more into this stealth discussion I am curious to know what you think of the background microdonation concept I posted recently. It is shown in full here http://sourceforge.net/mailarchive/message.php?msg_id=31837430 Given the lengthy nature of the concept as presented I would be happy to distill it further, but I am interested in your thoughts as to the idea generally and how to further present it. -Odinn On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote: It's a given this will be implemented for Payment Protocol. The question is whether it's also usable outside of PP. I think what stealth addresses is showing is that the concept of an address being instructions on how to generate a txout/tx that results in me getting Bitcoins is actually quite valuable; it and BIP32-derivation addresses with chaincodes are pretty clear cases where just replacing address with scriptPubKey isn't sufficient. I was kind of imagining that we could encourage people to replace all their static address text that live on Github pages, and README.me, and forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention could be to require only transporting xSTL addresses within a URI, even going so far as to not support them copy/pasted. 101 characters is not much longer (and sometimes shorter) than PaymentRequest URIs end up being. Yeah, I don't see anything wrong with stealth addresses whatever length they wind up being. It's a good intermediate step, and without them people will just pass around unsigned payment requests and other stuff. I think there are ways to make stealth addresses easy enough to use that people actually prefer using them for P2P payments which do not involve a full-stack merchant. In that case, if it was a PaymentRequest it would almost certainly not be signed, and would be more easily shared over email or SMS as a URI than as a file attachment or, even worse, putting the unsigned PR file up on a third-party server which probably won't do a good job securing it. At the DarkWallet hackathon we had discussed how to integrate stealth addresses into OpenPGP keys as a new user id type for instance, and similarly into x.509 certs. The big advantage here is the identity of *who* you are paying is important, not just I got this signed payment request. Basically the concept becomes identity signed payment address and the signature binding the identity to the address is a one time and offline thing; an issue with the payment protocol as it stands is that it encourages signing keys to be kept online to issue payment requests. If you have a scheme where the private keys that bound the identity to the address can be kept offline you're much better off, because the attacker can only create a fake payment request, they can't divert the funds to themselves. So with that in mind, I strongly suggest sticking with defining a reasonable stealth address spec. But when you do, keep in mind that you may want to upgrade it in the future, preferably in a backwards compatible way. Also, it shouldn't be limited to exactly 2-of-2 CHECKMULTISIG, there's no reason why n and m can't be picked as needed. Sure, it means the addresses are not fixed length, but for something that is mostly an internal detail and only occasionally visible to advanced users, I see no issues there. Along those lines: what would a BIP32 chain code address look like? What happens when you want to use that with a multisig-protected wallet? * PP Implementation Overview * The basic PaymentRequestPaymentDetails is expecting 'output' containing one or more TxOuts with script and amount. I believe the general approach is to put a fallback address into 'output' for backward compatibility, and put Q and Q2 into an extension field. So we add a new optional field to PaymentDetails which contains the one or two PubKeys. Not sure if we want different protobuf tags, or if the difference in length of the value makes it obvious enough which approach is being used; optional bytes stealthOnePubKey = 1000 optional bytes stealthTwoPubKey = 1001 I think you're missing the bigger picture here, not least of which is that backwards compatibility is a bit of a misnomer for an unreleased standard. :) Why put this into the PaymentDetails? That a stealth address is to be used for the payment is a property of the outputs being requested, not the payment itself. We're better off if that goes into the Output message, and further more it suggests that the Output message shouldn't contain raw scriptPubKey's but rather addresses. After all, IsStandard() means we have to inspect the scriptPubKey to see if we can even pay to what the sender is requesting. Once you establish that it's addresses that Outputs specify, then it's easy enough to make a stealth address type, or a BIP32-chain-code address type, or whatever else comes up in the future.
Re: [Bitcoin-development] Stealth Addresses
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd p...@petertodd.org wrote: On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote: I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping one of the pubKeys in the OP-RETURN, to prevent a malicious sender from triggering false positives on your online detection key when the funds are actually still fully controlled by the payer. You can still have a false positive (only 1 of 2 keys actually yours) but the funds would be trapped so it's unlikely anyone would do it. How would they trigger false positives? The payee recovers the nonce with ECDH from the payor's ephemereal pubkey and their online detection secret key. They use BIP32 public derivation with their offline spending pubkey(s), if the derived pubkeys match the actual scriptPubKey they know the output is spendable by them. I don't see how that can go wrong. Right now I have this: byte[] e = EC.NewPrivateKey(); byte[] P = EC.GetPublicKey(e, compressed: true); byte[] S1 = EC.DH(e, Q1); byte[] S2 = EC.DH(e, Q2); byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1)); byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S2)); stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(.995), 2, 2, q1New, q2New)); stealthTx.Vout.Add(TxOut.OpReturn(P)); In this case, you can scan with d2, calculate S2, and matching payments will have the right 'q2New'. But you need to check again offline with d1 since it's a separate shared secret. Maybe you are saying: byte[] S = EC.DH(e, Q2); byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S)); byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S)); But the payment would have (q2New - q1New) == (Q2 - Q1), so I think not entirely stealth? OK, let's fix that by adding a counter to the hash function... byte[] S = EC.DH(e, Q2); byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S || 1)); byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S || 2)); stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(.995), 2, 2, q1New, q2New)); stealthTx.Vout.Add(TxOut.OpReturn(P)); This is assuming we want to put q2New somewhere into the transaction, which, is it even required? byte[] S = EC.DH(e, Q2); byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S)); stealthTx.Vout.Add(TxOut.PayToPubKeyHash(Util.Amount(.995), q1New); stealthTx.Vout.Add(TxOut.OpReturn(P)); I'll wait for ACK and then update my sample code. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Tue, Jan 14, 2014 at 11:12:40AM -0800, Jeremy Spilman wrote:
Maybe you are saying:
byte[] S = EC.DH(e, Q2);
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));
But the payment would have (q2New - q1New) == (Q2 - Q1), so I think
not entirely stealth? OK, let's fix that by adding a counter to the
hash function...
Good catch, yeah, use the master shared secret to derive per-pubkey
secrets.
byte[] S = EC.DH(e, Q2);
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S || 1));
byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S || 2));
stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(.995), 2, 2,
q1New, q2New));
stealthTx.Vout.Add(TxOut.OpReturn(P));
This is assuming we want to put q2New somewhere into the
transaction, which, is it even required?
byte[] S = EC.DH(e, Q2);
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
stealthTx.Vout.Add(TxOut.PayToPubKeyHash(Util.Amount(.995), q1New);
stealthTx.Vout.Add(TxOut.OpReturn(P));
Well like I said, you shouldn't force the txout to be exactly a 2-of-2
multisig - the recipient might be using a multi-factor wallet for
instance. So, if I understand your code, what you want is the following:
byte[] Q = payee root pubkeys;
byte[] Q_Scan = may or may not be provided in Q
int m = # of pubkeys required to redeem;
byte[] S = EC.DH(e, Q_Scan);
byte[] qDerived[];
for (int = 0; i len(Q); i++){
qDerived[i] = EC.PointAdd(Q[i], Util.SingleSHA256(S || i));
}
// Best to have a single canonical order re: anonymity set.
qDerived = sorted(qDerived);
if (len(Q) 1){
stealthTx.Vout.Add(TxOut.PayToMultiSig(amount, m, len(Q), qDerived));
} else {
stealthTx.Vout.Add(TxOut.PayToPubKeyHash(amount, qDerived[0]);
}
stealthTx.Vout.Add(TxOut.OpReturn(P));
Finally, it would probably be better if the multisig output was wrapped
in a P2SH output to better match the behavior of other wallets for the
sake of a bigger anonymity set - seems that stuff that is implementing
multifactor wallets and escrow is using P2SH to do it rather than bare
multisig. Also there's quite a bit of support for making bare multisig
not IsStandard() to discourage data-storage applications.
--
'peter'[:-1]@petertodd.org
00010c474cd4e25913535ec1c166b6d43fbdd9a5f2726711ced7
signature.asc
Description: Digital signature
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
I saw in the math version you had said Q'=Q+H(S) and I presumed it was a typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G and therefore that Util.SingleSHA256() multiplies by G internally? Adam -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back a...@cypherspace.org wrote:
I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G
and therefore that Util.SingleSHA256() multiplies by G internally?
Adam
Thanks for reviewing this. The relevant line:
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1));
SingleSHA256 is a single application of SHA256 -- named so since 'SHA256'
functions in many Bitcoin libraries too often actually run DoubleSHA256.
32 bytes are returned.
The multiplication by 'G' that you mention is part of my EC.PointAdd...
I should probably just publish all my code as MIT and be done with it ;-)
Thanks,
Jeremy
public static byte[] PointAdd(byte[] point, byte[] scalar, bool compressed
= true)
{
var point1 = new OpenSSL.Crypto.EC.Point(EcGroup, point);
var num = OpenSSL.Core.BigNumber.FromArray(scalar);
var point2 = OpenSSL.Crypto.EC.Point.Multiply(EcGroup, num,
EcBnContext);
var result = point1.Add(point2, EcBnContext);
if (compressed)
return result.GetBytes(ConversionForm.Compressed);
else
return result.GetBytes(ConversionForm.Uncompressed);
}
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote: Signing a payment request for an individual is easy, anyway, depending on the kind of ID you want. If you want to sign with an email address, just go here with a browser like Chrome/Safari/IE that uses the system keystore: http://www.comodo.com/home/email-security/free-email-certificate.php Having now read that page, I'll just leave you with the first bullet point from it: * Digital signature ensures confidentiality (I'm not trying to make any particular point here - I just couldn't resist) roy -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
Sorry this is possibly OT, but someone posted this thread to r/bitcoin and it's gone straight to position 1. People are really enthusiastic about this feature. Drak -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
