Comments (1)
It seems there are several issues relating to Pay
, and this is an attempt to distill them a bit:
Pay
has 2 continuations, arguably it should have none (since we hardly ever want to know when a payment has been claimed).
- I did argue for not having continuations in
Pay
orRedeem
, but we decided to keep them for consistency with the rest of constructs. It may as well be that we want to make an exception because they are not useful. We could also argue we don't need continuations forCommit
either. Actually, it is often the case that we want to wait for two or moreCommit
s instead of one, and we may want bothCommit
s to be available simultaneously. In those cases continuations are useless.
Pay
has timeout, arguably it should not have.
- As long as
Pay
is not executed instantly (and it cannot be done, see below) andCommit
s have timeouts (#8), havingPay
without timeout would translate into almost every contract risking issuing aFailedPay
, sincePay
would potentially be waiting until it is to late for the payment to be made (because it expired).
Pay
takes a payer (in addition to a payee), arguably this should not be needed since it is the contract that owns the money (see issue #10).
- This is linked to
Commit
s belonging to someone. In Semantics 2.0, we specify the originCommit
instead of the payee. - Arguably,
Commit
s should not belong to anybody, but all money committed should belong to the contract. I think the whole idea of having ownership forCommit
s is to ensure that money doesn't get locked in the contract. We could allow the change of ownership ofCommit
s, as we have discussed in the past, that would still preserve the safety features, and maybe we can use that to replacePay
altogether.
Pay
waits for a participant to claim it, arguably payment should happen instantly.
- This is not possible because of pull model, see below.
Pay
has to be claimed by the payee, arguably anybody should be able to trigger it or should be triggered automatically.
- We could allow anybody to trigger it, this is a small change to the semantics. Do we want this? Is it fair? Why not?
Pay
value is determined at the moment of claim, arguably it should be fixed instantly when it is activated.
- The problem is that determining the value cannot be done instantly either. But we can allow anybody to trigger the determination of the value and then allow the recipient to claim the payment. I think this would be more elegant than 5.
- Another alternative to 5 is to have the claim of
Pay
to be part of the eval procedure (or reduction in the Semantics 2.0). This has the problems outlined in Alex's post, it is difficult to think of a way of symmetrically and fairly distributing the money atomically, and I think it would not offer any real advantage over 5 or 6.
In general, some of these points that are interleaved. In particular, if Pay
was triggered instantly, then many of the other points would become irrelevant. But since nothing can be triggered instantly because extended UTXO is a pull model, that is impossible. On the other hand, acting like it was triggered and accumulating the computation until it is actually triggered, is possible and promising, but it seems a very unstable model and could translate into very unpredictable/unfair fees.
from marlowe.
Related Issues (20)
- Gateway time-out on Marlowe tutorial HOT 1
- Marlowe Tutorials link on README is broken HOT 4
- Bounds - an extension with Value
- ACTUS contract types HOT 1
- (Issue entered into incorrect repo) HOT 1
- Improving json schema specs HOT 2
- Interactive tutorial in Marlowe Playground
- Marlowe specific cost analysis
- Playground - Warn on Increasing timeouts HOT 1
- Playground - warn on Shadowing of Let bindings HOT 1
- Playground - warn on TrueObs and FalseObs observations HOT 1
- Playground - warn on Pay before deposit
- Playground - warn on Use of bindings that have not being initialised HOT 1
- Convert playground to use Monaco Editor HOT 4
- Investigate usage of LiquidHaskell for proving contracts properties
- Layout of Marlowe contracts in Playground
- HCI HOT 1
- LSP support in the cloud
- LiquidHaskell
- Playground - Static Analysis broken HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from marlowe.