ripple-protocol — Ripple concept and protocol development

Re: [Ripple-protocol] reimagining the Ripple narrative — favours not dollars

[Ryan F. <ar...@ry...>]

I've definitely been thinking about it more in terms of favours for
the last couple of years.  And that interview you sent was excellent
(still reading it).  My goal with this project has been to try to take
the violence out of money and return to the friendly neighbourly IOU
days.

I'd love to discuss this more, but this list is pretty dead.  There
are more people involved over at the Google group:

https://groups.google.com/forum/#!forum/rippleusers

Maybe Jiri you could repost the interview and your thoughts below to
start a discussion there?

Thanks,
Ryan

On Fri, Aug 26, 2011 at 5:46 AM, Jiri Baum <ji...@ba...> wrote:
> Hi,
>
> I've been thinking that it might be an interesting excercise to rewrite the
> Ripple narrative with the standard example unit of account being "favours"
> rather than "dollars". I think I mentioned this in passing before, but never
> quite explicitly...
>
> That is: Ripple keeps track of the fact that Alice owes Bob a favour, and when
> Bob needs a favour from Carol, etc. Standard Ripple narrative, just with the
> one word replaced by another.
>
> Maybe it wouldn't be any use, but maybe it would provide quite interesting new
> insight into what Ripple really is or what it could become.
>
>
> Jiri
> --
> Jiri Baum <ji...@ba...>                   http://www.baum.com.au/sabik
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>

[Ripple-protocol] reimagining the Ripple narrative — favours not dollars

[Jiri B. <ji...@ba...>]

Hi,

I've been thinking that it might be an interesting excercise to rewrite the 
Ripple narrative with the standard example unit of account being "favours" 
rather than "dollars". I think I mentioned this in passing before, but never 
quite explicitly...

That is: Ripple keeps track of the fact that Alice owes Bob a favour, and when 
Bob needs a favour from Carol, etc. Standard Ripple narrative, just with the 
one word replaced by another.

Maybe it wouldn't be any use, but maybe it would provide quite interesting new 
insight into what Ripple really is or what it could become.


Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/sabik

[Ripple-protocol] Interesting article — What is Debt? – An Interview with Economic Anthropologist David Graeber

[Jiri B. <ji...@ba...>]

Came across an interesting article... I think it was a tweet that linked to a 
Bitcoin forum...

What is Debt? – An Interview with Economic Anthropologist David Graeber
http://www.nakedcapitalism.com/2011/08/what-is-debt-%E2%80%93-an-interview-
with-economic-anthropologist-david-graeber.html
(watch the line-break...)

Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/sabik

Re: [Ripple-protocol] New Bitcoin-inspired ideas

[Ryan F. <ar...@ry...>]

2011/5/25 Jorge Timón <tim...@gm...>:
> Ryan, I have a proposal for changing the registries. To facilitate
> regular nodes to be registrties. Fisrt some questions.
>
> Can nodes (or try) send a message to another node just indicating its
> public key?
>
> If so, I think registries should be indicated by their public key too,
> instead of an url.
> This way, any node can act as a registry without further preparation
> and intermediaries can just designate their friends as registries.
>
> Different combinations of registries should be allowed.
> For example: (node1 OR node2) AND (node3 OR node4 OR node5)...
> The commits can be broadcasted or something.
> This way registries become closer to zecrets proposal.
>

Registries will be identified by a key, but there's no reason for it
to be the same key as a node, even if the person who owns the node
operates the registry.  Most likely registry operators will also be
Ripple server operators, at least at the beginning.

Ryan

Re: [Ripple-protocol] New Bitcoin-inspired ideas

[Ryan F. <ar...@ry...>]

On Tue, May 24, 2011 at 6:28 AM, Stephen Paul Weber
<sin...@si...> wrote:
> I'm sure this has been discussed countless times: but what's wrong with just
> using OSPF or even simpler stuff?  Like, node A knows about some
> connections, builds them and broadcasts to nodes reachable from account A1,
> those nodes do the same (with broadcast path being kept to prevent flooding
> and such) and eventually after some TTL the request comes back with either a
> match or "no match withing that TTL" (where TTL is probably a number of
> hops).
>

Broadcast search was my original idea years ago, but it definitely
won't scale.  The current draft uses link-state routing, like OSPF,
but it differs in that we're looking for the *cheapest* path, not the
shortest path, and also that the path must be reserved before passing
the IOUs, because best-effort isn't good enough here.

Ryan

Re: [Ripple-protocol] New Bitcoin-inspired ideas

[Ryan F. <ar...@ry...>]

On Tue, May 24, 2011 at 5:25 AM, Jiri Baum <ji...@ba...> wrote:
> Ryan:
>> No, it does actually require them to be online as I've designed it.  I
>> can't imagine a way to allow for offline nodes to participate in
>> transactions other than a block chain or centralized transaction
>> authority.
>
> Why?
>
> A transaction only involves the parties to it. As long as they're connected to
> each other, they can conclude a transaction among themselves. A transaction
> has no effect beyond its parties, so why would they need to be connected to
> the wider Internet?
>

I define "online" as "connected to each other", however that might be.
 Internet is the default.

> Usage cases would probably all be in-person transactions where everyone is on
> the same wifi, LAN or even a near-field communication link.
>

Not likely at all.  You can't expect all the intermediaries to be in
the store with you while you make your purchase ;)

> I'm wondering whether there might be another algorithm that provides
> acceptable guarantees without registries...
>

Definitely propose an idea if you have one.  I am quite content with
registries though.

Ryan

Re: [Ripple-protocol] New Bitcoin-inspired ideas

[Jorge T. <tim...@gm...>]

Not sure, but it seems you're talking about path discovery. The issue
registers solve is transaction atomicity (and the possible attack of
locking intermediaries credit with fake transactions that never commit
?).

2011/5/24, Stephen Paul Weber <sin...@si...>:
> Somebody claiming to be Ryan Fugger wrote:
>>On Tue, May 24, 2011 at 2:57 AM, Jiri Baum <ji...@ba...> wrote:
>>> Hmm, again I was skimming rather quickly, but my first impression is that
>>>
>>> the
>>> registries would become central points of trust... and Ripple design
>>> should
>>> probably avoid that.
>>
>>Unfortunately, it is necessary for transaction atomicity.  I've
>>discussed the dangers of registries abusing their powers here (near
>>the bottom of the message):
>
> I'm sure this has been discussed countless times: but what's wrong with just
> using OSPF or even simpler stuff?  Like, node A knows about some
> connections, builds them and broadcasts to nodes reachable from account A1,
> those nodes do the same (with broadcast path being kept to prevent flooding
> and such) and eventually after some TTL the request comes back with either a
> match or "no match withing that TTL" (where TTL is probably a number of
> hops).
>
> --
> Stephen Paul Weber, @singpolyma
> See <http://singpolyma.net> for how I prefer to be contacted
> edition right joseph
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>

Re: [Ripple-protocol] New Bitcoin-inspired ideas

[Stephen P. W. <sin...@si...>]

Somebody claiming to be Ryan Fugger wrote:
>On Tue, May 24, 2011 at 2:57 AM, Jiri Baum <ji...@ba...> wrote:
>> Hmm, again I was skimming rather quickly, but my first impression is that 
>> the
>> registries would become central points of trust... and Ripple design should
>> probably avoid that.
>
>Unfortunately, it is necessary for transaction atomicity.  I've
>discussed the dangers of registries abusing their powers here (near
>the bottom of the message):

I'm sure this has been discussed countless times: but what's wrong with just 
using OSPF or even simpler stuff?  Like, node A knows about some 
connections, builds them and broadcasts to nodes reachable from account A1, 
those nodes do the same (with broadcast path being kept to prevent flooding 
and such) and eventually after some TTL the request comes back with either a 
match or "no match withing that TTL" (where TTL is probably a number of 
hops).

-- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

Re: [Ripple-protocol] New Bitcoin-inspired ideas

[Jiri B. <ji...@ba...>]

Hello,

Ryan:
> > Meanwhile, Ripple doesn't require everyone to be on-line, merely the
> > parties to a transaction to be connected to each other.

> No, it does actually require them to be online as I've designed it.  I
> can't imagine a way to allow for offline nodes to participate in
> transactions other than a block chain or centralized transaction
> authority.

Why?

A transaction only involves the parties to it. As long as they're connected to 
each other, they can conclude a transaction among themselves. A transaction 
has no effect beyond its parties, so why would they need to be connected to 
the wider Internet?

Usage cases would probably all be in-person transactions where everyone is on 
the same wifi, LAN or even a near-field communication link.

> > Hmm, again I was skimming rather quickly, but my first impression is that
> > the registries would become central points of trust... and Ripple design
> > should probably avoid that.

> Unfortunately, it is necessary for transaction atomicity.  

I'm wondering whether there might be another algorithm that provides 
acceptable guarantees without registries...

In any case, registries don't really solve much, because they have the same 
problem, just one level removed. Thus they would seem to complicate the 
protocol for no real gain.

> > For instance, what happens when one or more of the
> > registries goes off-line mid-transaction? You're back to the same
> > problem, only among the registries rather than among the transaction
> > participants.

> > If you do use some sort of Byzantine transaction commit consensus
> > algorithm, as someone proposed on the thread, then you might as well use
> > it among the transaction participants directly rather than among the
> > registries, as you responded. It'll probably be easier to design for
> > transaction participants, because there are pre-existing trust
> > relationships in the same shape as the transaction, but it is a
> > difficult problem.

> A consensus algorithm doesn't work among the participants:  the payer
> can add an arbitrary number of dummy nodes at the beginning of the
> chain and therefore control the commit/rollback to his own advantage
> without being detected.  Only if the participants all know and trust
> each other does this work.  But if the recipient knows and trusts the
> payer, then there is no need for a Ripple transaction at all -- the
> recipient can just accept the payer's IOUs.

Hmm, I wonder if that would be a workable restriction. In any case, the ripple 
transaction completes either before or after the goods are handed over. Would 
it be possible to break down such a transaction into two, one involving only 
the two parties and the goods, the other a circular transaction? Depending on 
the situation, these could be carried out in either order.

In this order, the goods are exchanged for the payer's IOU, who is required to 
stay until the circular transaction clears the debt. This is analogous to a 
restaurant, where one eats first and pays at the end of the meal.

The other way, the buyer gives the seller an account denominated in apples 
(for instance) and initiates circular transaction(s) until the account stands 
at the required number of apples. The seller settles the account in apples.


Of course, a consensus algorithm doesn't necessarily mean majority voting. 
Still, it's not that simple, especially if a node can induce a partition in 
the transaction (which it well might, if it has accounts that it's unwilling 
to trade between, so that the same node appears in two separate places in the 
transaction).

> > Other comments:
> > ============
> > 
> > * If there is no mining and only payers generate blocks in the chain,
> > then the system will be really really susceptible to better-resourced
...

> Don't worry, I have no plans to implement any block chain for Ripple.

No worries :-)

> > * Personally, I suspect that separating out the credit-limit system would
> > really help neaten up the protocol. Whether or not to accept each
> > transaction would then be up to each node, which might use a simple
> > credit limit or some other policy to decide which transactions to accept
> > and which to reject.

> Whether or not to accept each transaction *is* up to each node at
> transaction time.  Credit advertisements are informational only, but
> they are needed to allow the payer to determine what path a
> transaction will use.  Distributed path-finding at transaction time is
> much less efficient.

OK. It just seems that the credit limit policy is informing rather a lot of 
the transaction mechanism design. Obviously, transactions that may or may not 
have completed are a problem beyond that, but they may not be quite as serious 
as we might think. I don't know.

Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/sabik

Re: [Ripple-protocol] New Bitcoin-inspired ideas

[Ryan F. <ar...@ry...>]

On Tue, May 24, 2011 at 2:57 AM, Jiri Baum <ji...@ba...> wrote:
> Actually, block-chain does require everyone to be on-line, otherwise they
> can't submit transactions to the cloud or retrieve the confirmations.

No, the intermediaries and recipient can all be offline and the rest
of the network will process the transaction just fine.

> Meanwhile, Ripple doesn't require everyone to be on-line, merely the parties
> to a transaction to be connected to each other.
>

No, it does actually require them to be online as I've designed it.  I
can't imagine a way to allow for offline nodes to participate in
transactions other than a block chain or centralized transaction
authority.

>> Have you read my proposed atomicity extension for the current protocol?
>
>> https://groups.google.com/forum/#!topic/rippleusers/Ruy_QIb0AAY
>
>> I'd be interested in what you think.
>
> Hmm, again I was skimming rather quickly, but my first impression is that the
> registries would become central points of trust... and Ripple design should
> probably avoid that.

Unfortunately, it is necessary for transaction atomicity.  I've
discussed the dangers of registries abusing their powers here (near
the bottom of the message):

https://groups.google.com/d/msg/rippleusers/Ruy_QIb0AAY/Ih2rGfSlZfEJ

You can still perform transactions without registries -- registries
just enable more (and cheaper) transactions than would be possible
without them.

> For instance, what happens when one or more of the
> registries goes off-line mid-transaction? You're back to the same problem,
> only among the registries rather than among the transaction participants.
>
> If you do use some sort of Byzantine transaction commit consensus algorithm,
> as someone proposed on the thread, then you might as well use it among the
> transaction participants directly rather than among the registries, as you
> responded. It'll probably be easier to design for transaction participants,
> because there are pre-existing trust relationships in the same shape as the
> transaction, but it is a difficult problem.
>

A consensus algorithm doesn't work among the participants:  the payer
can add an arbitrary number of dummy nodes at the beginning of the
chain and therefore control the commit/rollback to his own advantage
without being detected.  Only if the participants all know and trust
each other does this work.  But if the recipient knows and trusts the
payer, then there is no need for a Ripple transaction at all -- the
recipient can just accept the payer's IOUs.

> Other comments:
> ============
>
> * If there is no mining and only payers generate blocks in the chain, then the
> system will be really really susceptible to better-resourced opponents. I get
> the impression that a fairly ordinary virus author can command CPU power
> roughly equivalent to the current-day Bitcoin network. No doubt so can any
> number of governments and other institutions. Are you really sure none of them
> will try to destroy it, whether for the lulz (virus author) or to maintain
> control of monetary policy (government)?
>

Don't worry, I have no plans to implement any block chain for Ripple.

> * Personally, I suspect that separating out the credit-limit system would
> really help neaten up the protocol. Whether or not to accept each transaction
> would then be up to each node, which might use a simple credit limit or some
> other policy to decide which transactions to accept and which to reject.
>

Whether or not to accept each transaction *is* up to each node at
transaction time.  Credit advertisements are informational only, but
they are needed to allow the payer to determine what path a
transaction will use.  Distributed path-finding at transaction time is
much less efficient.

Ryan

Re: [Ripple-protocol] New Bitcoin-inspired ideas

[Jiri B. <ji...@ba...>]

Hello,

Ryan:
> Hi Jiri.  Yes, I eventually came to those same conclusions in the
> google group threads, 

No worries... I was catching up and skimming most of that rather quickly...

> The one advantage to a block-chain mechanism is that it doesn't
> require all participating nodes to be online for the duration of the
> transaction, and achieves full transaction atomicity, albeit only
> probabilistically over time.  

Actually, block-chain does require everyone to be on-line, otherwise they 
can't submit transactions to the cloud or retrieve the confirmations. 
Meanwhile, Ripple doesn't require everyone to be on-line, merely the parties 
to a transaction to be connected to each other.

> Have you read my proposed atomicity extension for the current protocol?

> https://groups.google.com/forum/#!topic/rippleusers/Ruy_QIb0AAY

> I'd be interested in what you think.

Hmm, again I was skimming rather quickly, but my first impression is that the 
registries would become central points of trust... and Ripple design should 
probably avoid that. For instance, what happens when one or more of the 
registries goes off-line mid-transaction? You're back to the same problem, 
only among the registries rather than among the transaction participants.

If you do use some sort of Byzantine transaction commit consensus algorithm, 
as someone proposed on the thread, then you might as well use it among the 
transaction participants directly rather than among the registries, as you 
responded. It'll probably be easier to design for transaction participants, 
because there are pre-existing trust relationships in the same shape as the 
transaction, but it is a difficult problem.

So, basically, you're adding another layer of indirection with no clear 
benefit; while this may be compliant with RFC1925 (6a), it doesn't help...


Other comments:
============

* If there is no mining and only payers generate blocks in the chain, then the 
system will be really really susceptible to better-resourced opponents. I get 
the impression that a fairly ordinary virus author can command CPU power 
roughly equivalent to the current-day Bitcoin network. No doubt so can any 
number of governments and other institutions. Are you really sure none of them 
will try to destroy it, whether for the lulz (virus author) or to maintain 
control of monetary policy (government)?

* Personally, I suspect that separating out the credit-limit system would 
really help neaten up the protocol. Whether or not to accept each transaction 
would then be up to each node, which might use a simple credit limit or some 
other policy to decide which transactions to accept and which to reject.


Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/sabik

Re: [Ripple-protocol] New Bitcoin-inspired ideas

[Ryan F. <ar...@ry...>]

Hi Jiri.  Yes, I eventually came to those same conclusions in the
google group threads, and have posted an updated protocol draft that I
think is suitable for implementation:

http://ripple-project.org/Protocol/Protocol05

The one advantage to a block-chain mechanism is that it doesn't
require all participating nodes to be online for the duration of the
transaction, and achieves full transaction atomicity, albeit only
probabilistically over time.  Have you read my proposed atomicity
extension for the current protocol?

https://groups.google.com/forum/#!topic/rippleusers/Ruy_QIb0AAY

I'd be interested in what you think.

Thanks,
Ryan

On Mon, May 23, 2011 at 6:26 PM, Jiri Baum <ji...@ba...> wrote:
> Hello,
>
> Ryan:
>> Not sure who's still listening on this old list, but there's a new
>> thread on the Ripple Project group (formerly Ripple Users) that has
>> some new ideas for a distributed Ripple protocol:
>
>> https://groups.google.com/forum/#!topic/rippleusers/6sBQXKTluDk
>
> Somewhat late to the party (and maybe in the wrong forum), but...
>
> Personally, I think the Bitcoin proof-of-work block chain solves entirely the
> wrong problem for Ripple.
>
> Bitcoin requires everyone to know the sequence of all transactions; in Ripple,
> only the parties to a transaction need to know about it.
>
> Bitcoin requires transactions to be ordered; in Ripple, transaction order
> mostly doesn't matter, and with only minor redesign wouldn't matter at all.[1]
>
> Bitcoin assumes nobody trusts anyone and everone is semi-anonymous; in Ripple,
> each transaction happens along a linear or circular path where adjacent
> participants know and trust each other in any case.
>
>
> So, for Ripple, the block chain mechanism would give no clear advantage, and
> would bring all its disadvantages (computational load, storage footprint,
> susceptibility to better-resourced opponents, requirement for global
> connectivity, long delay in confirmation).
>
> If you want a peer-to-peer Ripple, then just write a peer-to-peer Ripple! Yes,
> consensus among transaction participants is a non-trivial problem, but it's a
> different problem to the global consensus problem of Bitcoin, so the solution
> will almost certainly also be different.
>
>
> Jiri
>
> [1] The only part where transaction order matters is for checking the credit
> limits; these should probably be separated out from the transaction mechanism
> anyway, because they're policy and it's generally good to separate mechanism
> and policy.
> --
> Jiri Baum <ji...@ba...>                   http://www.baum.com.au/sabik
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>

Re: [Ripple-protocol] New Bitcoin-inspired ideas

[Jiri B. <ji...@ba...>]

Hello,

Ryan:
> Not sure who's still listening on this old list, but there's a new
> thread on the Ripple Project group (formerly Ripple Users) that has
> some new ideas for a distributed Ripple protocol:

> https://groups.google.com/forum/#!topic/rippleusers/6sBQXKTluDk

Somewhat late to the party (and maybe in the wrong forum), but...

Personally, I think the Bitcoin proof-of-work block chain solves entirely the 
wrong problem for Ripple.

Bitcoin requires everyone to know the sequence of all transactions; in Ripple, 
only the parties to a transaction need to know about it.

Bitcoin requires transactions to be ordered; in Ripple, transaction order 
mostly doesn't matter, and with only minor redesign wouldn't matter at all.[1]

Bitcoin assumes nobody trusts anyone and everone is semi-anonymous; in Ripple, 
each transaction happens along a linear or circular path where adjacent 
participants know and trust each other in any case.


So, for Ripple, the block chain mechanism would give no clear advantage, and 
would bring all its disadvantages (computational load, storage footprint, 
susceptibility to better-resourced opponents, requirement for global 
connectivity, long delay in confirmation).

If you want a peer-to-peer Ripple, then just write a peer-to-peer Ripple! Yes, 
consensus among transaction participants is a non-trivial problem, but it's a 
different problem to the global consensus problem of Bitcoin, so the solution 
will almost certainly also be different.


Jiri

[1] The only part where transaction order matters is for checking the credit 
limits; these should probably be separated out from the transaction mechanism 
anyway, because they're policy and it's generally good to separate mechanism 
and policy.
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/sabik

Re: [Ripple-protocol] Next protocol draft messages

[Ryan F. <ar...@ry...>]

Hi Stephen.  Yes, relationships are not secret.  Encoding would be
JSON.  More here:

http://ripple-project.org/Protocol/Core

(I'll be updating it a bit soon, but I don't think there will be any
drastic changes.)

There are loads of examples on the v0.4 pages here:

http://ripple-project.org/Protocol/Protocol

The new protocol will be somewhat different, but the messages are similar.

Ryan

On Wed, Mar 2, 2011 at 2:08 PM, Stephen Paul Weber
<sin...@si...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Somebody claiming to be Ryan Fugger wrote:
>>I put up a brief summary of the messages for the next draft of the
>>Ripple protocol:
>>
>>http://ripple-project.org/Protocol/Messages
>>
>>Comments welcome, if there's anyone still reading this list...
>
> This seems like a start.  It seems like this is based on using routing where
> relationships are not secret?  What is the idea on encoding for these
> messages?  MIME-style seems like it could work, but I'd need to better sense
> of what the different messages look like.  Examples maybe?
>
> - --
> Stephen Paul Weber, @singpolyma
> See <http://singpolyma.net> for how I prefer to be contacted
> edition right joseph
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJNbr/3AAoJENEcKRHOUZzeW5oP/2LKoMg3vug5ZHUN7Gcd+ckp
> 4NAETtPhjgyTGHnaXShq6/ez9AYRTrX4TGyefTpplR2IdxCQwMisy0ZqPOvEo2cA
> vp5wpgWwTuji6BADF5rrk/qAGPTJ8GI9Q91Zxe+aX1ElsQbU4dbS2Vd3d3Hw5OGZ
> +w+ex123wH9hLhc0G2gM8qHlg+aP/4Mi558XIZwXg1YdmEPXWMbyv52cCQpS1N3P
> 6MA90emghKYu59jKQgRvHuqyHnoG6mzvU0VxkVuGiHEVE5MTZ7KPz5P9cHws4sEC
> sXmvbsh8Ddx5flHN+neOBRVMcu6KG4N4Fy5XZm7haHjPfjK1gA6PVLeFrj4AJwEm
> Ahwlu20Am0fAPgS9EL6ryrYqB+8c/05gTxiYMN2Uy8sUH/nt8w5E4B0tP9hkKjsn
> s+QR8uo5s57nSSCEzLz28gNfV+C52zjVu39LjGFqcXW6FlxycIqDmYJu4dGpTQGv
> AyiFdg6qRoP+ScOLBYLf8ROmeXkJ9hKajVcMZDQi8+QRKLuFB+jklWiBs6ZRZJWt
> 6ynExc9JPIVVKjnxjTkfWPdmiJ82MjhDwxMgHP25RIeLQj7NlouzsvrogFaKf7N0
> HDxic0ywuOZpl3ydMinAD8rGOvrR7TwZH8Sg5nByvr5W+4F8Cv23SI5uNOLInE+P
> 68nrShh8JJdVjzWVpo2e
> =Nphe
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>

Re: [Ripple-protocol] Next protocol draft messages

[Stephen P. W. <sin...@si...>]

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

Somebody claiming to be Ryan Fugger wrote:
>I put up a brief summary of the messages for the next draft of the
>Ripple protocol:
>
>http://ripple-project.org/Protocol/Messages
>
>Comments welcome, if there's anyone still reading this list...

This seems like a start.  It seems like this is based on using routing where 
relationships are not secret?  What is the idea on encoding for these 
messages?  MIME-style seems like it could work, but I'd need to better sense 
of what the different messages look like.  Examples maybe?

- -- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJNbr/3AAoJENEcKRHOUZzeW5oP/2LKoMg3vug5ZHUN7Gcd+ckp
4NAETtPhjgyTGHnaXShq6/ez9AYRTrX4TGyefTpplR2IdxCQwMisy0ZqPOvEo2cA
vp5wpgWwTuji6BADF5rrk/qAGPTJ8GI9Q91Zxe+aX1ElsQbU4dbS2Vd3d3Hw5OGZ
+w+ex123wH9hLhc0G2gM8qHlg+aP/4Mi558XIZwXg1YdmEPXWMbyv52cCQpS1N3P
6MA90emghKYu59jKQgRvHuqyHnoG6mzvU0VxkVuGiHEVE5MTZ7KPz5P9cHws4sEC
sXmvbsh8Ddx5flHN+neOBRVMcu6KG4N4Fy5XZm7haHjPfjK1gA6PVLeFrj4AJwEm
Ahwlu20Am0fAPgS9EL6ryrYqB+8c/05gTxiYMN2Uy8sUH/nt8w5E4B0tP9hkKjsn
s+QR8uo5s57nSSCEzLz28gNfV+C52zjVu39LjGFqcXW6FlxycIqDmYJu4dGpTQGv
AyiFdg6qRoP+ScOLBYLf8ROmeXkJ9hKajVcMZDQi8+QRKLuFB+jklWiBs6ZRZJWt
6ynExc9JPIVVKjnxjTkfWPdmiJ82MjhDwxMgHP25RIeLQj7NlouzsvrogFaKf7N0
HDxic0ywuOZpl3ydMinAD8rGOvrR7TwZH8Sg5nByvr5W+4F8Cv23SI5uNOLInE+P
68nrShh8JJdVjzWVpo2e
=Nphe
-----END PGP SIGNATURE-----

[Ripple-protocol] Next protocol draft messages

[Ryan F. <ar...@ry...>]

I put up a brief summary of the messages for the next draft of the
Ripple protocol:

http://ripple-project.org/Protocol/Messages

Comments welcome, if there's anyone still reading this list...

Ryan

[Ripple-protocol] New Bitcoin-inspired ideas

[Ryan F. <rf...@gm...>]

Not sure who's still listening on this old list, but there's a new
thread on the Ripple Project group (formerly Ripple Users) that has
some new ideas for a distributed Ripple protocol:

https://groups.google.com/forum/#!topic/rippleusers/6sBQXKTluDk

I've summarized these on the wiki, and added a few new formulations of
old ideas (under "Ideas for v0.5"):

http://ripple-project.org/Protocol/Index

Any thoughts are welcome.  Thanks.

Ryan

Re: [Ripple-protocol] "Circular Multilateral Barter 1.0" Release Announcement

[Ryan F. <rf...@gm...>]

On Thu, Nov 25, 2010 at 2:46 PM, Evgeni Pandurski <epa...@gm...> wrote:
> You are both right! But the problem, in my view, is much harder than it looks
> (and this probably applies to ripplepay too). I believe that creating
> a reliable
> reputation system is a very, very hard thing to do, so I rule it out right away
> (But I might be wrong, so I am open to suggestions)!
>

What I want to do with Ripplepay is to allow users to look at other
users' profile information and account histories, as well as
marketplace history once there is a marketplace.  (User's could make
some or all of their data private by default, and there could be a way
to request to view another's data, or propose to both expose their
private data simultaneously, etc.)  The way you summarize the
histories is important.

More details on Ripplepay plans here: http://ripple-project.org/Main/Roadmap

Maybe a good thing would be to only let me see details of the other
user's dealings with people who are in my network, or at least
highlight that data as most likely to be genuine and relevant.

Fundamentally though, the ability to connect with strangers is most
important at the start, when there is little of value in the system to
steal.  So connecting to strangers should be relatively safe early on.
 Later, the ability to look at other users' profiles will be used more
to find people you already know and trust, because there will be more
of them on there, and less need to connect to strangers.

So maybe the reputation system isn't that big of a deal.  Just being
able to find and connect to other people in order to try the system
out is most important to start I think.

>> Can I forward this annoncement to the Ripple Users list, or would you like to?
>
> Sure! This will be great!
>

Done.  I should mention that this list is pretty much dormant now that
distributed Ripple protocol discussions are on a back-back-burner.
Probably more useful to post these things to Ripple Users where there
are still active discussions...

Ryan

Re: [Ripple-protocol] "Circular Multilateral Barter 1.0" Release Announcement

[Evgeni P. <epa...@gm...>]

On Thu, Nov 25, 2010 at 10:00 PM, Ryan Fugger <rf...@gm...> wrote:
> I agree with
> Thomas: in order to be useful, there should be a way to discover new
> partners in your area, and maybe some way to gauge their reputation by
> their history in the system.  Ripplepay is definitely moving in this
> direction.

You are both right! But the problem, in my view, is much harder than it looks
(and this probably applies to ripplepay too). I believe that creating
a reliable
reputation system is a very, very hard thing to do, so I rule it out right away
(But I might be wrong, so I am open to suggestions)!

Therefore, users should always verify that the ID they've found is the
genuine ID
of the person they know (or otherwise they lose money, so to  speak).
So users will probaby prefer to go to person's website directly (or to make a
phone call) and discover the real user ID instantly (assuming that most local
traders already *do* have IDs!).

But there are 2 problems with my reasoning: 1) In the beginning most traders
*will not* have IDs, so users will probably want to search only for
traders that
are already in the system. 2) It is extremely unusual not to have an
user-search
in such kind of a website.

An analogy that comes to my mind: you "google" some trader's site and there
they say "Our bank account is 1234567890 -- send us money and we will send
you the stuff!". Well, this is a perfectly valid way to do business!
But it is quite
unusual in internet! Nevertheless, nobody expect banks to maintain an open
directory,  listing all their customers.

Obviously, it is really hard to compete with eBay or VISA :-) They've leveraged
users expectation too much! Also, money still works quite well, at
most places at
least.

> Can I forward this annoncement to the Ripple Users list, or would you like to?

Sure! This will be great!

Evgeni

Re: [Ripple-protocol] "Circular Multilateral Barter 1.0" Release Announcement

[Ryan F. <rf...@gm...>]

Awesome, Evgeni.  Congratulations.  Looks really good.  I agree with
Thomas: in order to be useful, there should be a way to discover new
partners in your area, and maybe some way to gauge their reputation by
their history in the system.  Ripplepay is definitely moving in this
direction.

Can I forward this annoncement to the Ripple Users list, or would you like to?

Ryan

On Thu, Nov 25, 2010 at 6:16 AM, Evgeni Pandurski <epa...@gm...> wrote:
> ===========================================================
> "Circular Multilateral Barter 1.0" Release Announcement
> ===========================================================
>
> We are pleased to announce the first stable release of our free (as in
> freedom) software for peer-to-peer circular barter exchange.  You can
> download the source code at: https://sourceforge.net/projects/cmb/
>
> Here is the first website running our software:
> https://www.multiswap.net/about/
>
> What is "Circular Multilateral Barter 1.0"?
> --------------------------------------------------
>
> "Circular Multilateral Barter 1.0" (CMB) is a free server-side
> software that operates peer-to-peer networks for circular barter
> exchange. CMB tremendously advances the conventional barter by making
> it multilateral.  It does so by engaging peers' trust to decouple the
> actual delivery of goods from the agreement to deliver the goods.
> Here are some of the advantages that CMB offers compared to
> traditional approaches:
>
> * Traditional approaches (fiat money, barter dollars, LETS points)
> unfortunately blend social trust into a fragile system of
> collectivized credit.  CMB makes it possible for individuals to use
> their own judgement in choosing whom they are willing to trust.  That
> is: you supply products to customers who trust you, and you receive
> products from partners whom you trust.
>
> * CMB does not suffer the double coincidence of wants problem.  The
> trader you deliver goods to and the trader you obtain what you need
> from do not need to be the same person, so there is much more
> flexibility for arranging trades.
>
> * CMB allows virtual money to circulate at infinite velocity so that
> no real money is actually needed.  That is: trading is not limited by
> the global scarcity of money or any other token or commodity.
>
> * CMB uses money solely as a standard of value for a short period of
> time (typically a day).  Thus CMB is insusceptible to changes in the
> value of money.
>
> You can read CMB's high-level software design document here:
> https://sourceforge.net/projects/cmb/files/cmb-design/cmb-dd.pdf/download
>
>
> 25 November 2010,
> CMB's developers
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>

Re: [Ripple-protocol] "Circular Multilateral Barter 1.0" Release Announcement

[Thomas H. <tho...@go...>]

It would be exceedingly useful to have a feature where you can view all
users in the system, where they are living, and what they are offering.

Next, you could have a search feature that searches by region, or by offer
-- eg, search for everybody that has an auto garage and does multibarter, in
the Venice, CA area.

And put this in the flash demo too ;)

If there are privacy concerns, you could have a "share my profile" checkbox
option, which I would have checked by default.

Incidentally, all of the above applies equally in my opinion to ripplepay.

Cheers, thomas.

Re: [Ripple-protocol] "Circular Multilateral Barter 1.0" Release Announcement

[Thomas H. <tho...@go...>]

This is great news evgeni! It looks like you put a lot of work into this and
it shows.

I particularly like the flash demo. Quick attention grab, and gives a great
overview of what it does. What's with the robo-voice though? :)

But seriously, everyone should check this out.

Also done in django I see, like ripplepay, for interested pythonistas.

On Thu, Nov 25, 2010 at 6:16 AM, Evgeni Pandurski <epa...@gm...>wrote:

> ===========================================================
> "Circular Multilateral Barter 1.0" Release Announcement
> ===========================================================
>
> We are pleased to announce the first stable release of our free (as in
> freedom) software for peer-to-peer circular barter exchange.  You can
> download the source code at: https://sourceforge.net/projects/cmb/
>
> Here is the first website running our software:
> https://www.multiswap.net/about/
>
> What is "Circular Multilateral Barter 1.0"?
> --------------------------------------------------
>
> "Circular Multilateral Barter 1.0" (CMB) is a free server-side
> software that operates peer-to-peer networks for circular barter
> exchange. CMB tremendously advances the conventional barter by making
> it multilateral.  It does so by engaging peers' trust to decouple the
> actual delivery of goods from the agreement to deliver the goods.
> Here are some of the advantages that CMB offers compared to
> traditional approaches:
>
> * Traditional approaches (fiat money, barter dollars, LETS points)
> unfortunately blend social trust into a fragile system of
> collectivized credit.  CMB makes it possible for individuals to use
> their own judgement in choosing whom they are willing to trust.  That
> is: you supply products to customers who trust you, and you receive
> products from partners whom you trust.
>
> * CMB does not suffer the double coincidence of wants problem.  The
> trader you deliver goods to and the trader you obtain what you need
> from do not need to be the same person, so there is much more
> flexibility for arranging trades.
>
> * CMB allows virtual money to circulate at infinite velocity so that
> no real money is actually needed.  That is: trading is not limited by
> the global scarcity of money or any other token or commodity.
>
> * CMB uses money solely as a standard of value for a short period of
> time (typically a day).  Thus CMB is insusceptible to changes in the
> value of money.
>
> You can read CMB's high-level software design document here:
> https://sourceforge.net/projects/cmb/files/cmb-design/cmb-dd.pdf/download
>
>
> 25 November 2010,
> CMB's developers
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>



-- 
Thomas Hartman
Chief Technical Officer
MarketPsy Capital, LLC
2400 Broadway, Suite 220
Santa Monica, CA, USA
______________________
This e-mail message and any attachments may contain information that is
confidential, proprietary or privileged, and is for the named person’s use
only.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you are not the intended recipient or agent responsible
for delivering it to the intended recipient, you are hereby notified that
any dissemination, distribution, copying or other use of this message or its
attachments is strictly prohibited.  If you have received this message in
error, please notify us immediately and destroy all copies of this message
and attachments without disclosing the contents to anyone.  Neither this
message nor any information included herein constitute an offer to sell or
the solicitation of an offer to buy any securities or investment product, or
legal, tax, accounting, or investment advice.

The fees and expenses charged in connection with the MarketPsy Long Short
Fund LP ("the Investment") may be higher than the fees and expenses of other
investment alternatives and may offset profits.  No assurance can be given
that the investment objective will be achieved or that an investor will
receive a return of all of her/his investment. Investment results may vary
substantially over any given time period.  An investment in this Fund is
speculative and involves a high degree of risk. The performance data
represents the performance of the Fund as calculated by the management
company. The performance figures include the reinvestment of any dividends
and other earnings as appropriate. Past performance is not necessarily
indicative of future results and there is always the possibility of loss.

[Ripple-protocol] "Circular Multilateral Barter 1.0" Release Announcement

[Evgeni P. <epa...@gm...>]

===========================================================
"Circular Multilateral Barter 1.0" Release Announcement
===========================================================

We are pleased to announce the first stable release of our free (as in
freedom) software for peer-to-peer circular barter exchange.  You can
download the source code at: https://sourceforge.net/projects/cmb/

Here is the first website running our software:
https://www.multiswap.net/about/

What is "Circular Multilateral Barter 1.0"?
--------------------------------------------------

"Circular Multilateral Barter 1.0" (CMB) is a free server-side
software that operates peer-to-peer networks for circular barter
exchange. CMB tremendously advances the conventional barter by making
it multilateral.  It does so by engaging peers' trust to decouple the
actual delivery of goods from the agreement to deliver the goods.
Here are some of the advantages that CMB offers compared to
traditional approaches:

* Traditional approaches (fiat money, barter dollars, LETS points)
unfortunately blend social trust into a fragile system of
collectivized credit.  CMB makes it possible for individuals to use
their own judgement in choosing whom they are willing to trust.  That
is: you supply products to customers who trust you, and you receive
products from partners whom you trust.

* CMB does not suffer the double coincidence of wants problem.  The
trader you deliver goods to and the trader you obtain what you need
from do not need to be the same person, so there is much more
flexibility for arranging trades.

* CMB allows virtual money to circulate at infinite velocity so that
no real money is actually needed.  That is: trading is not limited by
the global scarcity of money or any other token or commodity.

* CMB uses money solely as a standard of value for a short period of
time (typically a day).  Thus CMB is insusceptible to changes in the
value of money.

You can read CMB's high-level software design document here:
https://sourceforge.net/projects/cmb/files/cmb-design/cmb-dd.pdf/download


25 November 2010,
CMB's developers

[Ripple-protocol] "Circular Multilateral Barter" Beta 2 Release Announcement

[Evgeni P. <epa...@gm...>]

===========================================================
"Circular Multilateral Barter" Beta 2 Release Announcement
===========================================================

We are pleased to announce that the second public beta release of our
software for peer-to-peer barter exchange is now available. This beta
release is made available to allow a broad user base to test and
evaluate the novel approach to bartering that we propose.  The source
code is available at: https://sourceforge.net/projects/cmb/

"Circular Multilateral Barter" (CMB) is free server-side software for
managing peer-to-peer networks for barter exchange.  CMB advances
conventional barter by making it multilateral.  It does so by engaging
peers' trust to decouple the actual delivery of goods from the
agreement to deliver the goods.  Here are some of the advantages that
CMB offers compared to traditional approaches:

 * Traditional approaches (fiat money, barter dollars, LETS points)
   unfortunately blend social trust into a fragile system of
   collectivized credit. CMB makes it possible for individuals to use
   their own judgement in choosing whom they are willing to
   trust. That is: you supply products to customers who trust you,
   and you receive products from partners whom you trust.

 * CMB does not suffer the double coincidence of wants problem. The
   trader you deliver goods to and the trader you obtain what you
   need from do not need to be the same person, so there is much more
   flexibility for arranging trades.

 * CMB allows virtual money to circulate at infinite velocity so that
   no real money is actually needed.  That is: trading is not limited
   by the global scarcity of money or any other commodity.

 * CMB uses money solely as a standard of value for a short period of
   time (typically a day). Thus CMB is insusceptible to changes in
   the value of money.

You can try the newest version of the software on our demo-site:
http://www.multiswap.net/

Re: [Ripple-protocol] Some protocol questions

[Stephen P. W. <sin...@si...>]

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

Somebody claiming to be Miles Thompson wrote:
> The wiki page here:
> http://ripplep2p.com/wiki/Main/GroupedLink-StateRouting
> 
> lays out two main reasons not to use a simple routing protocol like OSPF:
>  - privacy and
>  - scalability
> 
> My thinking is that the former is not so much a feature as a liability
> (in the FBI raids your servers sense, http://bit.ly/aDu4p). I have no
> particular desire to duck KYC (Know Your Customer) legalities, and if
> it actually makes the technical job harder then I would argue to at
> least build the proof of concept with a relatively manageable amount
> of transparency and then if people want to make it more private - by
> group routing and sutff - they can do that, later.

Well, privacy is *between* servers.  Of course each server knows all the
accounts held by its members.  There is no good way around that.

> There is another reason transparency is important. If I make a payment
> via Ripple, I do want to make it work good for both ends of the
> equation, and in that sense it makes sense that I should care *who*
> the payment routes through. Potentially a bad egg could come on to the
> network and extend massive lines of credit to lots of people. If they
> manage (through social engineering) to convince lots of other people
> to trust them then you could end up with a situation where due to the
> stupidity of *others* my payment is routed (automatically) through
> this bad egg. If I consider that person to be a bad egg I may prefer
> *not* to have my payment route through them. (just because I want to
> make good on the payment).

??

If the "bad egg" is routed through, why do I care?  I have fufilled my
obligation to the neighbour I routed through (who trusts me), and the final recipient is
obligated by their neighbour (whom they trust).  What happens in between
does not affect us.  I didn't trust the "bad egg".  Whoever did will be
screwed, but that's their problem.

> As for the second reason, scalability.. well  as you say in your basic
> OSPF type routing its true that:
> 
> 'The link-state information is maintained on each router as a
> link-state database (LSDB) which is a tree-image of the entire network
> topology. Identical copies of the LSDB are periodically updated
> through flooding on all OSPF routers.'
> 
> http://en.wikipedia.org/wiki/Open_Shortest_Path_First
> 
> But I'd say that if this system is workable for "large enterprise
> networks" (up to say 70,000 different routes) its probably workable
> for us - at least to start. Global scale is a nice long term goal, but
> as they say 'premature optimization is the route of all evil' ;-)
> 
> Maybe we can talk about fancy stuff like hazy sighted link state
> routing once we have a couple of servers up and running.

As long as transitioning is easy.  I just don't want to have us get
somewhere, only to discover we've painted ourselved into a corner.

> Actually, thinking about this a bit more I'm not sure the 'link state
> routing' literature is the most relevant to the problem we have.
> 
> Sure, there is a good analogy in that we need to find an optimal
> 'route' of obligations through a network, and by analogy you could
> consider the 'credit range' / 'line of credit' statements to be like
> 'link state advertisements' etc..
> 
> But the situation is different, in that we don't at the same time have
> to deal with a reach-ability problem. That is we don't have to depend
> entirely on our immediate neighbours to relay all routing information.
> If, for instance we need to know the neighbours of node x we can just
> ask x directly (with actual routing to x taking place over TCP/IP).

Sure.

> Link state routing (of any type) also requires that at least most of
> the relevant nodes are online most of the time (to relay route
> advertisements for one)..
> 
> However, in most practical implementation of Ripple the situation is
> where you have a few main servers which (hopefully) are online plus a
> lot of 'offline' nodes that we are trying to find routes between.
> Maybe the some of the distance vector type routing protocols are more
> relevant (but I don't really know).

Well, the primary difference is that in IP routing, the nodes are all
first-order (that is, the things doing the routing are part of the system
that is being routed across) in Ripple we have "servers" and "nodes".  The
nodes are what is routed *between* but it is done *by* servers.  The servers
("routing nodes") will always be online.  They can do their work whether the
"nodes" they serve are on or not.

It's a lot more like email.  Only, we don't really route email independantly
of IP these days.

> Basically, I think it makes it a lot simpler (though complicated
> enough) to start by assuming you have the whole routing table
> available to start with. Optimizations should come later.

Sure.  That makes sense, as long as we don't paint ourselves into a corner.

> Don't get me wrong, I think the time component is crucial from a
> social perspective - lots of real world alt currency systems have a
> real problem with zombie defaults (that is defaults that aren't quite
> formally defaults yet) so to keep those from clogging up the system, I
> think time limits will be crucial. But that can come later. yes.

I'm still not sure about this problem.  It seems to me that if I'm cool with
the fact that my cousin owes me $200 and has for 8 years, then it doesn't
matter to anyone else as long as *I* can meet my obligations to *them* it
doesn't matter if people have met their obligations to *me*.

- -- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKle8oAAoJENEcKRHOUZzetXAP/RWbyQcUlz4xasrzYKAhvoBB
SQYmAHkOkPCYMfc+Z4kmiBTnngmtPvQIegV//kbnqt4e492rL7ShtsXyoVNKffkA
JaFAhvZjk66yNht6/UfV9FvRkyl8PPr5Y1eklbqdD1AOh+J69i367/6Qh8n5Q++v
QuwdptEx7bduhkIADDVgekvt34fh3TDkU1TeO8y4HH84KTwyt6ovbBoeb1c2edKe
5dPNu2sn2AG0wVUwf/7RGRNfro6xR8x4ge8zKXMuOSHoO4mQb1p9CgZosZM+m9q3
fq9/fmLprz5Y3+N7I7WeTUzUuvPb2ssfhduQO0IzBWpmN9EIUaDRB/2zP6/NSYPv
3GDrjlRYOJIEf9l6K4/9cgPFVv/UiIIew3IFpmr/QiUgGKV6gJWlKmfSPWiA+cJO
Pao38aPVglWjyxwliFUHzGoHtgcD2WynlWINNqJW0JCildHZBJQfN3l/DoRUtNcW
w9g3jBNWemY3AF2xX509J9yQAwqlvsG3UAjdIbxxhVWBxAxtdV7njJbqQ+3A6YOj
xcdBifV+/YukMsb7wE/bAiCq6BNuCaX+GJhRC79TyLXc3A7jGcXhkmNEajX3Qkc7
Ddef6nK5j8hvUVteC2sTezYw5ilHWdiXoyDrs1qpYI1E5Ji6bR0fp5vCsEglX+0s
Vsq+jYkvxId54UrAjHln
=8Vv3
-----END PGP SIGNATURE-----