Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Implemented micropayment channels for counterparty assets. #944
All commits needed have been squashed, see micropayment_channels branch for an unsquashed version and added micropayment code has 100% coverage. Note that this may contain some changes from @rubensayshi, if he has not already merged them.
New api calls start with mpc_ and micropayment code is in counterpartylib.lib.micropayments
Additionally I added an api call "sendrawtransaction" which pipes through to bitcoind, this helps a lot with mitigating race conditions in clients.
I also moved much of the signing/script code to its own python libray (github, pypi) so client that need it will not have to depend on counterpartylib and its extensive dependencies. This should belong to counterparty and I will gladly transfer ownership.
I will of course maintain this code and make any changes needed so this patches is accepted.
This was referenced
Nov 15, 2016
I'm gonna keep all discussion in this PR and avoid commenting in the documentation PR except for inline nits to avoid having a discussion split amongst multiple PRs.
first off; damn nice job, everything looks very well thought through and coded up.
A thing that took me a moment to realize is that these payment channels differ from a "traditional" bitcoin payment channel because of the lack of change in the counterparty protocol.
The commit TX only contains the send to the payee, the remaining "change" is left behind in the deposit and is eventually redeemed by the payer in the Change TX using the spend secret.
Another thing that I think would be good to clarify is that reusing a payment channel is impossible due to how Counterparty works (if you can do 1 spend from an P2SH address you can spend all assets in that address) and that the code has a safeguard in there.
It's unclear to me what the purpose is of the revoke TX.
Can you elaborate on the default of 2 blocks delay time that allows the payer to use the revoke secret? is 2 blocks a sensible delay?
I think the docs should elaborate a bit more on choosing the expire_time of the deposit TX and how a margin of error is necessary even when the time of how long the channel will stay open is known to keep a safe margin for blocks being found quickly etc. considering as soon as the expire is hit the payer to undo the whole transaction.
Again something should be documented is the fee that is required for the various TXs that can follow the deposit TX.
... continueing on this submit later ;-) ...
The commit tx will determine the funds transferred, to transfer additional funds a new commit tx with a higher amount is created. Funds can also be returned by the payee if they reveal the revoke secret. This effectively makes it impossible for the payee to publish revoked commits, as the payer can recover all funds using the revoke secret. This is accomplished by the commit delay time (default two block) that the payee has to wait until they can recover the funds using a payout tx.
Hope this clears things up a bit, documentation never was my strong point. I will go through the documentation and try to clear up what is going on.
hmm I think a check should be added for the payee to make sure the commit TX fee is enough and the extra BTC provided to pay for the fee of the payout TX is enough.
a low fee on the commit TX could allow the payer to use his expiration TX if the commit TX won't get confirmed.
and the 2nd check is mostly just to avoid having to go though the hassle of construction a TX with additional inputs to pay for the fee.
@rubensayshi I'm guessing the seperate package you mean is micropayment-core. If you want to adopt into counterparty org now is the best time to make any renaming or such. I will continue to support it and transfer the pypi package ownership if possible/desired/needed.
The reason the code is in a separate package, is so a client doesn't need all the counterparty lib dependencies.
@rubensayshi request feedback
Generally a good idea I think, but I'm not sure if we need a changed API for this. It seems that this is a higher level client issue. Checking the fee is simple in most bitcoin libs, as not to need an extra call. I will try change my client to check tx fees and likely prefer using pycoin calls over any cp API call anyway.
Adding more inputs doesn't help with the commit tx, it may take a long time for the channel to settle and the fee may be to low by that point.
This is different for the payout. Constructing the payout tx with more inputs may be a good extension to the API (so far as counterparty allows for extra btc inputs/outputs).
#952 can ensure that good estimates can be obtained "natively", as long as Bitcoin Core estimates work properly.