Merkle Transactions?

[Jorge Timón]

Hi, I want to explain a little more the idea I mentioned in the New
Ripple thread.
I want to make chain/public Ripple compatible with 2PC/private Ripple
within the smae transaction. I'll use an example, please point out any
flaws you find or make the questions you need. Substitute FRC for

It would be a transaction on the chain that goes like this: A -> B ->
C -> D -> E
What happens is...
- A destroys 1 hostCoin cash unit
- A spends 10 public B (that previously owns), to buy 10 D privately from C
- C sends 10 to D privately, and in exchange D will publicly send 10 to E
- D publicly sends 10 to E

Who signs what and when?

* A -> B

This happened earlier. C owns 10 B publicly before starting the transaction

* A
** B
*** B -> C
*** C -> D (private)
** D
*** C -> D (private)
*** D -> E

...............A
......._____|______
.......|...................|
......C..................D
..___|____.....____|___
..|.............|...|.............|
B -> C.....C -> D.....D -> E


This is an ugly merkle tree (I promise I'll draw a picture with
plantUML or something else).
C -> D is not contained publicly in the ledger. But the scripts that C
and D sign both contain its hash.
A builds the transaction and knows all the offers, that are not
binding (private). Maybe A->B was a binding offer instead of a
previous public ownership.
All the scripts must be correctly signed for the whole transaction to be valid.

What do you think? Is this a good idea? Can it work?
What needs to be clarified?

--
Jorge Timón

http://freico.in/
http://ripple-project.org/

[Ryan Fugger]

Basically what you're proposing is that some hops of the transaction
are not divulged publicly, and are instead discovered and committed
using the 2PC protocol or something similar, and are integrated into
the public ledger transaction for blockchain Ripple. Right?

It's not clear to me from your email what role the Merkle tree plays
in all this, nor what exactly is contained in the Merkle tree (what
data does C->D represent/contain?), nor what exactly is published
publicly in ledger exactly.

It should be possible, though, in theory, to hook up 2PC transactions
as subpaths of a public-ledger transaction. What you'd need is:

* a way to validate in the ledger that the 2PC sub-transaction was
pre-approved (promise phase complete) and will be committed by the
overall transaction being confirmed in the ledger (is this what the
Merkle tree does?)

* a way to communicate with the 2PC hubs in question to request this
type of transaction

Doesn't seem like too big a deal -- minor modifications or extra
fields in a few messages in each protocol. This would work well with
the 2PC exchange publishing routing method, where the offers are
public, so the payment networks created by both systems could be
joined together for routing purposes. All that would be necessary
would be for 2PC nodes to publish their ledger addresses.

Ryan

> --
>
>

[Jorge Timón]

On 12/3/12, Ryan Fugger <a...@ryanfugger.com> wrote:
> Basically what you're proposing is that some hops of the transaction
> are not divulged publicly, and are instead discovered and committed
> using the 2PC protocol or something similar, and are integrated into
> the public ledger transaction for blockchain Ripple. Right?

Yes.

> It's not clear to me from your email what role the Merkle tree plays
> in all this, nor what exactly is contained in the Merkle tree (what
> data does C->D represent/contain?), nor what exactly is published
> publicly in ledger exactly.

Well, I'm sure there's many ways to implement the same functionality,
but I was thinking on something simple and generic. Leafs of the tree
could be just a src a destination and a quantity. The scripting
language could navigate the tree to ask for the right signatures and
also make validate conditions on the public leafs. The private leafs
won't appear in the chain. It's not really necessary that the root of
the tree appears in the chain.

> It should be possible, though, in theory, to hook up 2PC transactions
> as subpaths of a public-ledger transaction. What you'd need is:
>
> * a way to validate in the ledger that the 2PC sub-transaction was
> pre-approved (promise phase complete) and will be committed by the
> overall transaction being confirmed in the ledger (is this what the
> Merkle tree does?)

Yes, for both system to combine, the commit method for 2PC should be
the ledger chain.

> * a way to communicate with the 2PC hubs in question to request this
> type of transaction
>
> Doesn't seem like too big a deal -- minor modifications or extra
> fields in a few messages in each protocol. This would work well with
> the 2PC exchange publishing routing method, where the offers are
> public, so the payment networks created by both systems could be
> joined together for routing purposes. All that would be necessary
> would be for 2PC nodes to publish their ledger addresses.

Yes, the exchange routing could be shared, maybe more easily without
integrating both systems the way I'm proposing.
I'm thinking that the example is not very good because in it all the
signatures are published.
Let's say we just have an exchange between A and B of their own currencies.

1) A sends 10 pubA to pubB1.
2) B sends 10 privB to privA1.

Only 1 needs to appear in the ledger, but A holds the whole tree (with
the proper script) signed by privB, that effectively says "2 is true
if 1 gets into the chain".

Maybe my obsession is more about having a common crypto-assets
scripting language for both systems than exclusively about integrating
them in the same transaction. As you point out, it should be possible
to achieve that last thing without making drastic changes to current
designs.

Anyway, thank you for the feedback.

> --