LearnBitcoin

Bitcoin Dev Archive 2013

Revocability with known trusted escrow services?

10 messages, 6 to 7 Jun 2013. Started by Peter Vessenes.

Melvin Carvalho (2), Peter Vessenes, Alan Reiner, Peter Todd, Leszek Rychlewski, Mike Hearn, Jorge Timón, Mark Friedenbach, +1 more

Permalink Original thread on gnusha.org

Peter Vessenes permalink original

So, this http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 article got posted today, noting that FinCEN thinks irrevocable payments are money laundering tools.

I will hold my thoughts about the net social good of rent-seeking large corporations taking money from consumers over fraudulent reversals. Actually, I won't, I just said it.

At any rate, it got me thinking, can we layer on revocability somehow without any protocol change, as an opt-in?

My initial scheme is a trusted (hah) escrow service that issues time promises for signing. If it doesn't receive a cancel message, it will sign at the end of the time.

The addresses would be listed by the escrow service, or in an open registry, so you could see if you were going to have a delay period when you saw a transaction go out.

This seems sort of poor to me, it imagines that mythical thing, a trusted escrow service, and is vulnerable to griefing, but I thought I'd see if some of the brighter minds than me can come up with a layer-on approach here.

When I think about it, I can imagine that I would put a good number of my coins in a one day reversible system, because I would have warning if someone wanted to try and spend them, and could do something about it. I'm not sure if it gets me anything over a standard escrow arrangement, though.

Peter

Alan Reiner in reply to Peter Vessenes permalink original

The two most basic ways would be simply:

(1) You create your transactions having a locktime of X days and has sequence numbers such that it can be replaced exactly once. The replacement, can be executed within 30 days.

(2) You simply send money to 1-of-2 transactions: me-or-you. If the person who is receiving it wants it, they have to sign for it by sending it to one of their own single-sig addresses. Otherwise, you can return it to yourself at some point in the future.

I don't totally understand the goal, and how/if these solutions actually achieve such goal. But it does add a way for transactions to exist a non-final state for some amount of time. But in both cases, accessibility is still binary: you have complete access to it, until you don't. Which might be seen as the point of irrevocable transfer.

-Alan

On 06/05/2013 08:19 PM, Peter Vessenes wrote:

Quoted text (58 lines)
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
>  article got posted today, noting that FinCEN thinks irrevocable
> payments are money laundering tools.
>
> I will hold my thoughts about the net social good of rent-seeking
> large corporations taking money from consumers over fraudulent
> reversals. Actually, I won't, I just said it.
>
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>
> My initial scheme is a trusted (hah) escrow service that issues time
> promises for signing. If it doesn't receive a cancel message, it will
> sign at the end of the time.
>
> The addresses would be listed by the escrow service, or in an open
> registry, so you could see if you were going to have a delay period
> when you saw a transaction go out.
>
> This seems sort of poor to me, it imagines that mythical thing, a
> trusted escrow service, and is vulnerable to griefing, but I thought
> I'd see if some of the brighter minds than me can come up with a
> layer-on approach here.
>
> When I think about it, I can imagine that I would put a good number of
> my coins in a one day reversible system, because I would have warning
> if someone wanted to try and spend them, and could do something about
> it. I'm not sure if it gets me anything over a standard escrow
> arrangement, though.
>
> Peter
>
> --
>
> ------------------------------------------------------------------------
>
> CoinLab LogoPETER VESSENES
> CEO
>
> *peter@coinlab•com <mailto:peter@coinlab.com> * /  206.486.6856
>  / SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Melvin Carvalho in reply to Peter Vessenes permalink original

On 6 June 2013 02:19, Peter Vessenes <peter@coinlab•com> wrote:

Quoted text (4 lines)
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 article got posted today, noting that FinCEN thinks irrevocable payments
> are money laundering tools.
>

It's great that this article quotes the first page of Sasoshi's white paper. There are some other text that they missed, though, which I think may be relevant.

[[ Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for non- reversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.

What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. ]]

Quoted text (51 lines)
>
> I will hold my thoughts about the net social good of rent-seeking large
> corporations taking money from consumers over fraudulent reversals.
> Actually, I won't, I just said it.
>
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>
> My initial scheme is a trusted (hah) escrow service that issues time
> promises for signing. If it doesn't receive a cancel message, it will sign
> at the end of the time.
>
> The addresses would be listed by the escrow service, or in an open
> registry, so you could see if you were going to have a delay period when
> you saw a transaction go out.
>
> This seems sort of poor to me, it imagines that mythical thing, a trusted
> escrow service, and is vulnerable to griefing, but I thought I'd see if
> some of the brighter minds than me can come up with a layer-on approach
> here.
>
> When I think about it, I can imagine that I would put a good number of my
> coins in a one day reversible system, because I would have warning if
> someone wanted to try and spend them, and could do something about it. I'm
> not sure if it gets me anything over a standard escrow arrangement, though.
>
> Peter
>
> --
>
> ------------------------------
>
> [image: CoinLab Logo]PETER VESSENES
> CEO
>
> *peter@coinlab•com * /  206.486.6856  / SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
Peter Todd in reply to Peter Vessenes permalink original

On Wed, Jun 05, 2013 at 05:19:16PM -0700, Peter Vessenes wrote:

Quoted text (30 lines)
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
> article got posted today, noting that FinCEN thinks irrevocable
> payments
> are money laundering tools.
>
> I will hold my thoughts about the net social good of rent-seeking large
> corporations taking money from consumers over fraudulent reversals.
> Actually, I won't, I just said it.
>
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>
> My initial scheme is a trusted (hah) escrow service that issues time
> promises for signing. If it doesn't receive a cancel message, it will sign
> at the end of the time.
>
> The addresses would be listed by the escrow service, or in an open
> registry, so you could see if you were going to have a delay period when
> you saw a transaction go out.
>
> This seems sort of poor to me, it imagines that mythical thing, a trusted
> escrow service, and is vulnerable to griefing, but I thought I'd see if
> some of the brighter minds than me can come up with a layer-on approach
> here.
>
> When I think about it, I can imagine that I would put a good number of my
> coins in a one day reversible system, because I would have warning if
> someone wanted to try and spend them, and could do something about it. I'm
> not sure if it gets me anything over a standard escrow arrangement, though.

A few issues:

Revocable payments are almost always invoked in cases where the decision that a payment needs to be revoked is done by humans. To worry about the difficulty of finding a "trusted escrow service" is irrelevant at the protocol level - this isn't a problem that can be solved by math.

Legally speaking revocation can generally happen any time in the future, even years in the future. Note the controversies involved around a variety of land transactions that occured hundreds of years in the past in North America and other parts of the world, where distant relatives of those who made the transactions are attempting to have them reversed partially or fully. Technical solutions with a limited revocation window are likely to be found unacceptable in the eyes of the law.

Focusing on the need to "revoke" a transaction is taking a banking idea, and applying it very incorrectly to the Bitcoin world; in banking revoking a transaction can result in your balance being negative.

What you need to focus on is the spirit of what revoking a transaction is about, which is to take money from someone who thought they had it, and give it to someone else. We can easily replicate this effect in Bitcoin by simply giving the private keys for our wallets to the relevant revocation authority, or, if more auditing is desired, storing our coins in 1-of-2 multisig addresses spendable by either us or that authority.

In the event that a transaction needs to be revoked, simply have the escrow service make a transaction that takes the correct amount of coins from your wallet, and gives it to the person who sent you the money.

Problem solved.

Leszek Rychlewski in reply to Peter Todd permalink original

Transactions with cash are even less revocable (there is no negative cash balance while a btc wallet can have a negative balance) so it looks like the authorities are exploiting differences between crypto currencies and the banking system as an excuse to prosecute members of the new industry.

Collecting arguments against such accusations should suffice [but I like the maturation concept for dedicated accounts/transactions :-)].

Leszek

Mike Hearn in reply to Peter Vessenes permalink original

On Thu, Jun 6, 2013 at 2:19 AM, Peter Vessenes <peter@coinlab•com> wrote:

Quoted text (4 lines)
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 article got posted today, noting that FinCEN thinks irrevocable payments
> are money laundering tools.
>

That's not how I read it, I don't see how one could argue that irreversible transactions are a money laundering tool. Credit card transactions aren't completely reversible either, you have to either claim that the card was stolen or that the merchant didn't deliver. If you charge back routinely, then the card companies are supposed to crack down on you. Though I don't know if that really happens.

I think we should expect the head of FinCEN to argue that more or less anything can be seen as money laundering. She directly and personally profits from expansion of the notion of money laundering. That doesn't mean other people have to agree.

Quoted text (3 lines)
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>

I think we need 2-of-3 dispute mediation and have thought that for a long time, indeed, Satoshi's paper says so:

https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation

It doesn't require any core protocol changes but it does require deployment of the payment protocol first, as that's the foundation on which we can add lots of other useful features like that. And then it needs a whole lot of work to define how you open a dispute from your wallet, how you find mutually agreeable mediators, etc. Having reversible payments in which one of the trading parties gets to decide whether to reverse seems pointless to me. If the buyer decides it's simply equivalent to post pay, and if the seller decides then it's just a refund, which the payment protocol already supports.

Jorge Timón in reply to Leszek Rychlewski permalink original

P2SH with 2 of 3: the payer, recipient and a trusted third party. It is explained here:

https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation

Nothing can be done at the protocol level if you want it to remain p2p. Much like the tainted coins stuff. Maybe offtopic but I disliked what everyone but Alan said in that bitcoin2013 "security panel" about it. Well, I didn't like several claims on that panel...

On 6/6/13, Leszek Rychlewski <leszek@bioinfo•pl> wrote:

Quoted text (24 lines)
> Transactions with cash are even less revocable (there is no negative cash
> balance while a btc wallet can have a negative balance) so it looks like
> the
> authorities are exploiting differences between crypto currencies and the
> banking system as an excuse to prosecute members of the new industry.
>
> Collecting arguments against such accusations should suffice [but I like
> the
> maturation concept for dedicated accounts/transactions :-)].
>
> Leszek
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Mark Friedenbach in reply to Peter Vessenes permalink original

If a technical solution could be found, I don't doubt that it will quickly become the only legal way to do transfers in the U.S.

Peter, you are Executive Director of the Bitcoin Foundation. I would like to know that your efforts are focused on fighting this archaic world view, not bending over backwards to comply with it.

Mark On 6/5/13 5:19 PM, Peter Vessenes wrote:

Quoted text (3 lines)
> So, this http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1  article got posted today, noting that FinCEN thinks irrevocable payments are money laundering tools.
>
> I will hold my thoughts about the net social good of rent-seeking

large corporations taking money from consumers over fraudulent reversals. Actually, I won't, I just said it.

Quoted text (2 lines)
>
> At any rate, it got me thinking, can we layer on revocability somehow

without any protocol change, as an opt-in?

Quoted text (2 lines)
>
> My initial scheme is a trusted (hah) escrow service that issues time

promises for signing. If it doesn't receive a cancel message, it will sign at the end of the time.

Quoted text (2 lines)
>
> The addresses would be listed by the escrow service, or in an open

registry, so you could see if you were going to have a delay period when you saw a transaction go out.

Quoted text (2 lines)
>
> This seems sort of poor to me, it imagines that mythical thing, a

trusted escrow service, and is vulnerable to griefing, but I thought I'd see if some of the brighter minds than me can come up with a layer-on approach here.

Quoted text (2 lines)
>
> When I think about it, I can imagine that I would put a good number of

my coins in a one day reversible system, because I would have warning if someone wanted to try and spend them, and could do something about it. I'm not sure if it gets me anything over a standard escrow arrangement, though.

Quoted text (11 lines)
>
> Peter
>
> --
>
> -------------------------
>
> CoinLab LogoPETER VESSENES
> CEO
>
> *peter@coinlab•com <mailto:peter@coinlab.com> * /  206.486.6856  /

SKYPE: vessenes

Quoted text (5 lines)
> 71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104
>
>
>
>

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

Quoted text (11 lines)
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Melvin Carvalho in reply to Peter Vessenes permalink original

On 6 June 2013 02:19, Peter Vessenes <peter@coinlab•com> wrote:

Quoted text (29 lines)
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 article got posted today, noting that FinCEN thinks irrevocable payments
> are money laundering tools.
>
> I will hold my thoughts about the net social good of rent-seeking large
> corporations taking money from consumers over fraudulent reversals.
> Actually, I won't, I just said it.
>
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>
> My initial scheme is a trusted (hah) escrow service that issues time
> promises for signing. If it doesn't receive a cancel message, it will sign
> at the end of the time.
>
> The addresses would be listed by the escrow service, or in an open
> registry, so you could see if you were going to have a delay period when
> you saw a transaction go out.
>
> This seems sort of poor to me, it imagines that mythical thing, a trusted
> escrow service, and is vulnerable to griefing, but I thought I'd see if
> some of the brighter minds than me can come up with a layer-on approach
> here.
>
> When I think about it, I can imagine that I would put a good number of my
> coins in a one day reversible system, because I would have warning if
> someone wanted to try and spend them, and could do something about it. I'm
> not sure if it gets me anything over a standard escrow arrangement, though.
>

Also see satoshi's comments on this, though it may be restating what others have said:

https://bitcointalk.org/index.php?topic=750.0

"Here's an outline of the kind of escrow transaction that's possible in software. This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible.

The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.

While this system does not guarantee the parties against loss, it takes the profit out of cheating.

If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.

The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else.

Now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and I'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone."

Quoted text (26 lines)
>
> Peter
>
> --
>
> ------------------------------
>
> [image: CoinLab Logo]PETER VESSENES
> CEO
>
> *peter@coinlab•com * /  206.486.6856  / SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
Caleb James DeLisle in reply to Melvin Carvalho permalink original

IMO this story falls somewhere between rose colored glasses and outright trolling. Whereas LR was a (relatively shady) company, bitcoin is an entire branch of technology and research, I can't think of any real caselaw in the US with regards to banning a technology, perhaps the cryptography export regulation and we all know how well that worked. Furthermore, the non-reversibility of LR is mostly because they didn't want to deal with mediation while the non-reversibility of bitcoin is technological barrier.

It seems AmericanBanker has a record of hosting articles which urge policy decisions:
  http://www.americanbanker.com/bankthink/governments-must-co-opt-bitcoin-to-avert-disaster-1058380-1.html
that would obviously be of personal benefit to the article's author:
  http://www.clearbit.com/company_management.htm
It is the very job of governments to resist the efforts of lobbyists to line their
pockets at the public expense.

While I don't think significant risk of developed countries actually banning an entire area of research such as bitcoin, I do suspect that bitcoin's popularity lead to LR's downfall as it will other companies which allow people to transact anonymously.

The tragedy of bitcoin's irreversibility is that it makes kidnap/ransom schemes profitable. The relative safety of the first world is largely due to the fact that until now, there has never been any effective way to steal significant amounts of money. While this problem is serious I don't think it's intractable. Bitcoin offers us a modeling tool which like never before allows us to experiment with our motivations and build something better than even bitcoin is today.

I believe regulators are intelligent people who understand this and would rather legitimize bitcoin than ban it. If there ever were such a ban, I would be more concerned for the future of the country imposing it than I would for bitcoin.

Thanks, Caleb

tl;dr haters gonna hate

On 06/06/2013 06:22 PM, Melvin Carvalho wrote:

Quoted text (79 lines)
>
>
>
> On 6 June 2013 02:19, Peter Vessenes <peter@coinlab•com <mailto:peter@coinlab.com>> wrote:
>
>     So, this http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1  article got posted today, noting that FinCEN thinks irrevocable payments are money laundering tools.
>
>     I will hold my thoughts about the net social good of rent-seeking large corporations taking money from consumers over fraudulent reversals. Actually, I won't, I just said it.
>
>     At any rate, it got me thinking, can we layer on revocability somehow without any protocol change, as an opt-in?
>
>     My initial scheme is a trusted (hah) escrow service that issues time promises for signing. If it doesn't receive a cancel message, it will sign at the end of the time.
>
>     The addresses would be listed by the escrow service, or in an open registry, so you could see if you were going to have a delay period when you saw a transaction go out.
>
>     This seems sort of poor to me, it imagines that mythical thing, a trusted escrow service, and is vulnerable to griefing, but I thought I'd see if some of the brighter minds than me can come up with a layer-on approach here.
>
>     When I think about it, I can imagine that I would put a good number of my coins in a one day reversible system, because I would have warning if someone wanted to try and spend them, and could do something about it. I'm not sure if it gets me anything over a standard escrow arrangement, though.
>
>
> Also see satoshi's comments on this, though it may be restating what others have said:
>
> https://bitcointalk.org/index.php?topic=750.0
>
> "Here's an outline of the kind of escrow transaction that's possible in software.  This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible.
>
> The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.
>
> While this system does not guarantee the parties against loss, it takes the profit out of cheating.
>
> If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.
>
> The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else.
>
> Now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and I'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone."
>
>
>
>     Peter
>
>     --
>
>     --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>     CoinLab LogoPETER VESSENES
>     CEO
>
>     *peter@coinlab•com <mailto:peter@coinlab.com> * /  206.486.6856 <tel:206.486.6856>  / SKYPE: vessenes
>     71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104
>
>
>     ------------------------------------------------------------------------------
>     How ServiceNow helps IT people transform IT departments:
>     1. A cloud service to automate IT design, transition and operations
>     2. Dashboards that offer high-level views of enterprise services
>     3. A single system of record for all IT processes
>     http://p.sf.net/sfu/servicenow-d2d-j
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists•sourceforge•net <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>