commit scripts
Timón
Ryan Fugger
I'm not convinced this complexity is helpful at this point. For a
start, it doesn't seem to be able to replicate registries' function,
as registries must be able to not just sign a commit token, but
actually timestamp and sign a message vouching for either the
existence or non-existence of a particular commit token at a
particular time. I'm not sure how this would be accomplished with the
bitcoin scripting language.
If it can be done, then the bitcoin-ripple exchange example can be
simplified: Just script a bitcoin transaction to depend on the success
of an atomic Ripple transaction. If it can't be done, then it's not
useful for replacing registries at all. Either way, scripting isn't
needed or useful on the Ripple side.
One idea is to just use registries that can act as Bitcoin oracles:
https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state
(In fact, Bitcoin oracles are remarkably similar to registries as I
have envisioned them.)
That way, Ripple can be used to speed up block-chain-currency
transactions, or trigger a useful sequence of them for the purposes of
exchange. Maybe. I'm not quite sure. Nor am I terribly concerned
with this use case at the moment, since anything other than simple
value transfer transactions seem to be still mainly theoretical.
Ryan
> --
> You received this message because you are subscribed to the Google Groups
> "Ripple Project" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rippleusers/-/G0zAH-Gq5TMJ.
> To post to this group, send email to rippl...@googlegroups.com.
> To unsubscribe from this group, send email to
> rippleusers...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rippleusers?hl=en.
>
Jorge Timón
> On Mon, Oct 10, 2011 at 3:44 AM, Timón <timon....@gmail.com> wrote:
>> Hi, I added a proposal to substitute commit registries. It is something
>> similar to my commit conditions earlier proposal but I think more generic
>> and robust.
>>
>> http://ripple-project.org/Main/CommitScripts
>> Tell me what you think about it and other applications that you think
>> could
>> be interesting.
>>
>
> I'm not convinced this complexity is helpful at this point. For a
> start, it doesn't seem to be able to replicate registries' function,
> as registries must be able to not just sign a commit token, but
> actually timestamp and sign a message vouching for either the
> existence or non-existence of a particular commit token at a
> particular time. I'm not sure how this would be accomplished with the
> bitcoin scripting language.
That would be done outside the protocol. Or maybe another message
"have you sign this transaction? Has it expired?".
All that is needed is an expiry field in the transaction (commit
accept) that is as lower as the lower expiry date in the promises.
When the registry signs, he's signing that the expiry time has not
been reached yet.
> If it can be done, then the bitcoin-ripple exchange example can be
> simplified: Just script a bitcoin transaction to depend on the success
> of an atomic Ripple transaction.
It could be done with ripple registries acting as oracles, but then
the exchange wouldn't be trust-less, because both parties have to
trust the registry.
> If it can't be done, then it's not
> useful for replacing registries at all. Either way, scripting isn't
> needed or useful on the Ripple side.
Although not necessarily scripts,something equivalent to registries is
needed. But registries as they are now are not needed neither in this
same sense.
I think scripts can be very useful for ripple. I'll try to think in
more use cases.
> One idea is to just use registries that can act as Bitcoin oracles:
>
> https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state
>
> (In fact, Bitcoin oracles are remarkably similar to registries as I
> have envisioned them.)
>
> That way, Ripple can be used to speed up block-chain-currency
> transactions, or trigger a useful sequence of them for the purposes of
> exchange. Maybe. I'm not quite sure. Nor am I terribly concerned
> with this use case at the moment, since anything other than simple
> value transfer transactions seem to be still mainly theoretical.
But I see no reason why not to enable it for the future.
You argue that it is unnecessary complexity. But I think that in fact
this is simpler than creating new messages for the registries and will
allow to save complexity to protocols built on top of ripple.
Some of these protocols (without scripts) will not even be compatible
with the ripple base protocol and will therefore need to send their
ripple modified messages outside of the regular ripple network.
The current protocol is not as simple as it could be to "allow simple
value transaction". It has some useful (but not strictly needed)
optimizations in it:
1) A public key certificate system
2) An special message for the exchange rates that optimizes exchanges
that happen very often.
3) Credit lines (the two accounts can be managed independently and the
users can take care of simplifying the "connected" balances themselves
or at a higher level outside of the protocol)
4) Maybe (honestly I should think more about this) the ripple protocol
could be transport agnostic (instead of using TCP connections) like
open transactions is:
"Open Transactions is agnostic to transport. Meaning that libOTLib.a,
the actual library (containing the bulk of the code), includes no
transport code at all. Zero. At its core, Open Transactions is a
financial crypto and digital cash library, not a transport library."
Messages could be sent over mail, TCP, Tor, i2p...
So if these additional complexities are included in the protocol,
maybe is room for one more. Actually, there is. Something that
performs the registries function has to be still included in the
protocol.
--
Jorge Timón
Ryan Fugger
> 2011/10/11, Ryan Fugger <a...@ryanfugger.com>:
>> I'm not convinced this complexity is helpful at this point. For a
>> start, it doesn't seem to be able to replicate registries' function,
>> as registries must be able to not just sign a commit token, but
>> actually timestamp and sign a message vouching for either the
>> existence or non-existence of a particular commit token at a
>> particular time. I'm not sure how this would be accomplished with the
>> bitcoin scripting language.
>
> That would be done outside the protocol. Or maybe another message
> "have you sign this transaction? Has it expired?".
> All that is needed is an expiry field in the transaction (commit
> accept) that is as lower as the lower expiry date in the promises.
> When the registry signs, he's signing that the expiry time has not
> been reached yet.
>
What's the script opcode for verifying that the date on the
registry-signed commit token is less than or equal to the date on the
promise?
>> If it can be done, then the bitcoin-ripple exchange example can be
>> simplified: Just script a bitcoin transaction to depend on the success
>> of an atomic Ripple transaction.
>
> It could be done with ripple registries acting as oracles, but then
> the exchange wouldn't be trust-less, because both parties have to
> trust the registry.
>
In the scripted version you still have to trust the registry to only
sign if the expiry date hasn't passed, so that's not a valid argument
in favour of scripts.
> You argue that it is unnecessary complexity. But I think that in fact
> this is simpler than creating new messages for the registries and will
> allow to save complexity to protocols built on top of ripple.
I'm not sure in which universe adding an entire scripting language for
specifying arbitrary sequences of functions in order to validate
transactions is less complicated than adding a couple extra messages
and fields for registries.
Ryan
Jorge Timón
> What's the script opcode for verifying that the date on the
> registry-signed commit token is less than or equal to the date on the
> promise?
There isn't. The registry is supposed to sign the transaction only if
it hasn't expired. The registry could sign after that, but a registry
could also sign false timestamps with the regular registry messages.
> In the scripted version you still have to trust the registry to only
> sign if the expiry date hasn't passed, so that's not a valid argument
> in favour of scripts.
The trust needed is far lower. In the oracle based exchange they need
to trust the registry to tell them if the ripple tx has happened or
not. In the scripting exchange, the registries have already signed and
only the secrets are left. They only trust the registry for
timestamping not to act as a escrow. For that they could just use a
regular web exchange that accept ripple credits to make deposits.
>> You argue that it is unnecessary complexity. But I think that in fact
>> this is simpler than creating new messages for the registries and will
>> allow to save complexity to protocols built on top of ripple.
>
> I'm not sure in which universe adding an entire scripting language for
> specifying arbitrary sequences of functions in order to validate
> transactions is less complicated than adding a couple extra messages
> and fields for registries.
Maybe you're right, after all is hard to define complexity here.
But the scripting language doesn't have to be very complex. With just
OP_HASH160
OP_EQUALVERIFY
OP_CHECKSIG
OP_DUP
You can make regular transactions (where the recipient acts as the
only registry) and registry transactions. These would be very
convenient for registries:
OP_BOOLAND
OP_BOOLOR
For the bitcoin exchange, you don't need anything else in the ripple side.
The following would be also very useful:
OP_IF
OP_ELSE
OP_ENDIF
OP_DROP
The really important thing is verifying signatures and hashes, the
rest is only to enhance computation.
But the point is that if the base ripple protocol doesn't allow this,
new ripple-like protocols will appear to enable different use cases
like the trust-less exchange and others that we haven't taken into
account.
And the scripting language doesn't have to be fully implemented from
the beginning. Only what is needed to implement registries is needed
at first. Those can be considered standard transactions and an error
can be thrown for the not implemented operations.
--
Jorge Timón
Ryan Fugger
> 2011/10/11, Ryan Fugger <a...@ryanfugger.com>:
>> What's the script opcode for verifying that the date on the
>> registry-signed commit token is less than or equal to the date on the
>> promise?
>
> There isn't. The registry is supposed to sign the transaction only if
> it hasn't expired. The registry could sign after that, but a registry
> could also sign false timestamps with the regular registry messages.
>
Right, but how does the script specify that the signature is a
registry then? It could be any signature, right? That's the point of
scripting. To script a registry, you have to have the date comparison
function somewhere, otherwise registries still require extra fields
somewhere.
>> In the scripted version you still have to trust the registry to only
>> sign if the expiry date hasn't passed, so that's not a valid argument
>> in favour of scripts.
>
> The trust needed is far lower. In the oracle based exchange they need
> to trust the registry to tell them if the ripple tx has happened or
> not. In the scripting exchange, the registries have already signed and
> only the secrets are left. They only trust the registry for
> timestamping not to act as a escrow. For that they could just use a
> regular web exchange that accept ripple credits to make deposits.
>
Registries *are* only trusted for timestamping.
Ryan
Jorge Timón
> Right, but how does the script specify that the signature is a
> registry then?
It doesn't. The intermediary could require his signature instead of
the registry one and there would be no difference.
> It could be any signature, right?
Exactly.
> That's the point of
> scripting. To script a registry, you have to have the date comparison
> function somewhere, otherwise registries still require extra fields
> somewhere.
I think you mean that an script operation including an expiry date
would be needed.
But the script is executed by anyone who wants to check the validity
of the transaction, not the registry, so an expiry time doesn't makes
much sense within the script.
A possibility of that would be a comparison between a time in the
script and a time in the verification stack included and signed by the
registry.
But I think it would be much simpler to just add an expiry time (as
low as the lowest promise expiration time) to the
per-commit/transaction/payment accept message.
>>> In the scripted version you still have to trust the registry to only
>>> sign if the expiry date hasn't passed, so that's not a valid argument
>>> in favour of scripts.
>>
>> The trust needed is far lower. In the oracle based exchange they need
>> to trust the registry to tell them if the ripple tx has happened or
>> not. In the scripting exchange, the registries have already signed and
>> only the secrets are left. They only trust the registry for
>> timestamping not to act as a escrow. For that they could just use a
>> regular web exchange that accept ripple credits to make deposits.
>>
>
> Registries *are* only trusted for timestamping.
In the oracle based exchange you proposed a server is trusted for the
validity of the whole ripple transaction, not only the timestamping.
You need a third party to sign the bitcoin transaction. That's what
you avoid by having scripts with hashes of secrets in ripple.
--
Jorge Timón
Ryan Fugger
> 2011/10/11, Ryan Fugger <a...@ryanfugger.com>:
>> Right, but how does the script specify that the signature is a
>> registry then?
>
> It doesn't. The intermediary could require his signature instead of
> the registry one and there would be no difference.
>
There must be a way to specify that a registry is being used, and what
address to query that registry for non-existence of a commit at a
given time, in order that promises can be rolled back.
> But I think it would be much simpler to just add an expiry time (as
> low as the lowest promise expiration time) to the
> per-commit/transaction/payment accept message.
>
That could work.
> In the oracle based exchange you proposed a server is trusted for the
> validity of the whole ripple transaction, not only the timestamping.
> You need a third party to sign the bitcoin transaction. That's what
> you avoid by having scripts with hashes of secrets in ripple.
>
No, the registry is only trusted for timestamping, which both
endpoints can use to infer transaction validity with 100% certainty
based on their knowledge of the promises in the transaction, and their
possession of payment init/accept messages that, combined with a
timestamped commit, constitute proof of transaction completion.
Remember, the Ripple endpoints are the same entities as the Bitcoin
endpoints, so they have full knowledge of the Ripple transaction.
Once they know the Ripple transaction is complete, they have the key
to trigger the Bitcoin transaction that has already been cemented in
the block chain.
Ryan
> --
> Jorge Timón
>
> --
> You received this message because you are subscribed to the Google Groups "Ripple Project" group.
Jorge Timón
> 2011/10/11 Jorge Timón <timon....@gmail.com>:
>> 2011/10/11, Ryan Fugger <a...@ryanfugger.com>:
>>> Right, but how does the script specify that the signature is a
>>> registry then?
>>
>> It doesn't. The intermediary could require his signature instead of
>> the registry one and there would be no difference.
>>
>
> There must be a way to specify that a registry is being used, and what
> address to query that registry for non-existence of a commit at a
> given time, in order that promises can be rolled back.
I don't like it much, but a "different" operation that is identical to
OP_CHECKSIG, called OP_CHECKSIG_REG or something like thatcould be
added.
And the address...Isn't the public key enough to send the message from
one node to other in ripple?
I think that should be the case.
>> But I think it would be much simpler to just add an expiry time (as
>> low as the lowest promise expiration time) to the
>> per-commit/transaction/payment accept message.
>>
>
> That could work.
>
>> In the oracle based exchange you proposed a server is trusted for the
>> validity of the whole ripple transaction, not only the timestamping.
>> You need a third party to sign the bitcoin transaction. That's what
>> you avoid by having scripts with hashes of secrets in ripple.
>>
>
> No, the registry is only trusted for timestamping, which both
> endpoints can use to infer transaction validity with 100% certainty
> based on their knowledge of the promises in the transaction, and their
> possession of payment init/accept messages that, combined with a
> timestamped commit, constitute proof of transaction completion.
> Remember, the Ripple endpoints are the same entities as the Bitcoin
> endpoints, so they have full knowledge of the Ripple transaction.
> Once they know the Ripple transaction is complete, they have the key
> to trigger the Bitcoin transaction that has already been cemented in
> the block chain.
But the oracle is a server that signs the bitcoin transaction. So the
registry (or another third party) would need to sign the bitcoin
transaction.
If the ripple tx can depend on a secret, both transaction can be
executed pseudo-atomically.
--
Jorge Timón
Ryan Fugger
> I don't like it much, but a "different" operation that is identical to
> OP_CHECKSIG, called OP_CHECKSIG_REG or something like thatcould be
> added.
Starts to feel more like a hack.
> And the address...Isn't the public key enough to send the message from
> one node to other in ripple?
> I think that should be the case.
>
Registries aren't nodes.
>> No, the registry is only trusted for timestamping, which both
>> endpoints can use to infer transaction validity with 100% certainty
>> based on their knowledge of the promises in the transaction, and their
>> possession of payment init/accept messages that, combined with a
>> timestamped commit, constitute proof of transaction completion.
>> Remember, the Ripple endpoints are the same entities as the Bitcoin
>> endpoints, so they have full knowledge of the Ripple transaction.
>> Once they know the Ripple transaction is complete, they have the key
>> to trigger the Bitcoin transaction that has already been cemented in
>> the block chain.
>
> But the oracle is a server that signs the bitcoin transaction. So the
> registry (or another third party) would need to sign the bitcoin
> transaction.
Yes.
> If the ripple tx can depend on a secret, both transaction can be
> executed pseudo-atomically.
>
How so?
Ryan
Jorge Timón
> 2011/10/12 Jorge Timón <timon....@gmail.com>:
>> I don't like it much, but a "different" operation that is identical to
>> OP_CHECKSIG, called OP_CHECKSIG_REG or something like thatcould be
>> added.
>
> Starts to feel more like a hack.
That's why I prefer that only their signature is required and the
expiry is in the payment accept message.
>> And the address...Isn't the public key enough to send the message from
>> one node to other in ripple?
>> I think that should be the case.
>>
>
> Registries aren't nodes.
Why not?
>>> No, the registry is only trusted for timestamping, which both
>>> endpoints can use to infer transaction validity with 100% certainty
>>> based on their knowledge of the promises in the transaction, and their
>>> possession of payment init/accept messages that, combined with a
>>> timestamped commit, constitute proof of transaction completion.
>>> Remember, the Ripple endpoints are the same entities as the Bitcoin
>>> endpoints, so they have full knowledge of the Ripple transaction.
>>> Once they know the Ripple transaction is complete, they have the key
>>> to trigger the Bitcoin transaction that has already been cemented in
>>> the block chain.
>>
>> But the oracle is a server that signs the bitcoin transaction. So the
>> registry (or another third party) would need to sign the bitcoin
>> transaction.
>
> Yes.
>
>> If the ripple tx can depend on a secret, both transaction can be
>> executed pseudo-atomically.
>>
>
> How so?
As explained in the example, when the ripple tx is committed through
by adding the secret, the bitcoin transaction can be completed too.
And there's no risk of double-spending because the funds need both
signatures to be moved. If they aren't moved when the contract tx
(already in the chain) is activated, the funds go back to an address
controlled by the bitcoins owner.
--
Jorge Timón
Ryan Fugger
> 2011/10/13, Ryan Fugger <a...@ryanfugger.com>:
>> Registries aren't nodes.
>
> Why not?
>
The don't have lines of credit.
Ryan
Jorge Timón
And why can't they have connections?
I though a regular ripple node could act as a registry.
2011/10/14, Ryan Fugger <a...@ryanfugger.com>:
> --
> You received this message because you are subscribed to the Google Groups
> "Ripple Project" group.
> To post to this group, send email to rippl...@googlegroups.com.
> To unsubscribe from this group, send email to
> rippleusers...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rippleusers?hl=en.
>
>
--
Jorge Timón
Ryan Fugger
> But why can't they be like a ripple node just without connections?
> And why can't they have connections?
> I though a regular ripple node could act as a registry.
>
The node functionality has nothing to do with the registry
functionality. You can operate both, but there's no reason for a
registry to be a node, just like there's no reason for an email server
to be a website. A registry can have a node, but it doesn't need to
*be* a node to accomplish its task.
Ryan
Jorge Timón
with it having the same public key/address scheme than regular nodes?
Registries also need to sign and a way to "contact with" them is
needed too.
Any node could accomplish the registry task if trusted. Why more
infrastructure is needed?
2011/10/14, Ryan Fugger <a...@ryanfugger.com>:
Ryan Fugger
> I understand that it doesn't need to be a node. But what's the problem
> with it having the same public key/address scheme than regular nodes?
> Registries also need to sign and a way to "contact with" them is
> needed too.
> Any node could accomplish the registry task if trusted. Why more
> infrastructure is needed?
>
The main way to contact a node is to make a regular TCP connection to
its server. This is the same with a registry. No extra
infrastructure required either way.
The secondary method for contacting a node is to relay messages
through the credit network. This is relatively unreliable, since any
intermediary node could fail to relay the message, but it allows nodes
more anonymity. I suppose we could allow a registry to advertise that
it can receive messages at a particular node, but I don't see that as
being an important feature.
The message-relay feature is a low-budget version of TOR, and would
need to be improved for better performance and security if it turns
out to be used a lot.
Ryan
Jorge Timón
> 2011/10/14 Jorge Timón <timon....@gmail.com>:
> The main way to contact a node is to make a regular TCP connection to
> its server. This is the same with a registry. No extra
> infrastructure required either way.
>
> The secondary method for contacting a node is to relay messages
> through the credit network. This is relatively unreliable, since any
> intermediary node could fail to relay the message, but it allows nodes
> more anonymity. I suppose we could allow a registry to advertise that
> it can receive messages at a particular node, but I don't see that as
> being an important feature.
>
> The message-relay feature is a low-budget version of TOR, and would
> need to be improved for better performance and security if it turns
> out to be used a lot.
Say we are A, B, C and D.
A is connected (data p2p network) to B, B to C and C to D
If A wants to send a message to D (say a credit message), the simplest
way to do it is:
1) A asks B for D connection data to connect directly with it.
2) Encrypt the message with D public key and send it through B and C.
I don't know why a TOR-like messaging scheme is needed. Once the peers
are connected (through TCP, TOR, i2p or whatever) they can just send
messages to a target public address and encrypt them with the public
key so that only the recipient can read it.
A to B: Do you have D_public_key connection data?
B to A: No, but I'll ask my other peers
B to C: Do you have D_public_key connection data?
C to B: Yes, here it is {D_public_key, IP (or TOR address), D signature}
B to A: I got it, here it is {D_public_key, IP (or TOR address), D signature}
A to D: Hi, D, take my message encrypted exclusively for you.
When a node wants to connect to another node, he does it refers to it
by its public key, right?
How a node identifies a registry when he wants to contact it?
How does he ask to his peers for the data address (say IP) of a
certain registry?