Skip to content

Commit

Permalink
shell for a Payment Class for issue renepickhardt#20
Browse files Browse the repository at this point in the history
  • Loading branch information
sebulino committed May 17, 2022
1 parent 8df2c57 commit c03fe39
Show file tree
Hide file tree
Showing 2 changed files with 51 additions and 0 deletions.
7 changes: 7 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
.DS_Store
.idea
__pycache__
docs

# too large to upload
listchannels*.json
44 changes: 44 additions & 0 deletions pickhardtpayments/Payment.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
class Payment:
"""
Payment stores the information about an amount of sats to be delivered from source to destination.
When sending an amount of sats from sender to receiver, a payment is usually split up and sent across
several paths, to increase the probability of being successfully delivered.
The PaymentClass holds all necessary information about a payment.
It also holds information that helps to calculate performance statistics about the payment.
:param int _total_amount: The total amount of sats to be delivered from source address to destination address.
:param str _sender: sender address for the payment.
:param str _receiver: receiver address for the payment.
:param list _attempts: returns a list of Attempts
:param list _successful_attempts: returns a list of successful Attempts
:param bool _successful: returns True if the total_amount of the payment could be delivered successfully.
"""

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt May 18, 2022

I think it would be good to have two timestamps for started (or initiated) finnished(or aborted)


def __init__(self):
self._attempts = []
self._successful_attempts = []

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt May 18, 2022

always this tricky question about memory overhead vs runtime. Keeping attampts redundant seems a bit overkill. but then iterating over a list to collect the successfull ones is also dumb... :(

This comment has been minimized.

Copy link
@sebulino

sebulino May 18, 2022

Author Owner

I decided in favour of just collecting the successful attempts, as they will be needed to manifest the payments in the OracleNetwork. but we can also collect the other ones. It's a collection of references, so should not be too much of an overhead, it I'm not mistaken.


@property
def total_amount(self):
return self._total_amount

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt May 18, 2022

I guess we could also need a fee property that tells us what the total fees where it could also be ppm as most people don't care for the actual sats but the rate that occured in total

@property
def src(self):
return self._sender

@property
def dest(self):
return self._receiver

@property
def attempts(self):
return self._attempts

@property
def successful_attempts(self):

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt May 18, 2022

related to the extra list. if we provide a successful_attempts api why not also the unsuccessful_attempts (which I guess many people will also care about (just in other situations) Or we don't ship both APIs because people just get the list of attempts and have to decide themselves. I imagine with a good Attemp class it should be easy enough to filter oneself?

return self._successful_attempts

@property
def successful(self):

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt May 18, 2022

should we also have something like settled?

return self._successful

0 comments on commit c03fe39

Please sign in to comment.