Supports returned for a claim should include the address the support was sent to #92

Closed
opened 2018-02-06 17:29:46 +01:00 by jackrobison · 4 comments
jackrobison commented 2018-02-06 17:29:46 +01:00 (Migrated from github.com)

Currently the txid, nout, and amount of the support is returned. By including address, clients can determine if a support is a "tip" (a support sending to the address of the claim) versus a typical support. Otherwise if addresses are desired all of the support transactions in the list have to be queried and parsed.

Currently the txid, nout, and amount of the support is returned. By including address, clients can determine if a support is a "tip" (a support sending to the address of the claim) versus a typical support. Otherwise if addresses are desired all of the support transactions in the list have to be queried and parsed.
kaykurokawa commented 2018-07-18 18:26:11 +02:00 (Migrated from github.com)

Noting here that there may not necessarily be an address attached to a support so it would have to handle that case.

Noting here that there may not necessarily be an address attached to a support so it would have to handle that case.
tzarebczan commented 2018-07-18 19:09:22 +02:00 (Migrated from github.com)

@kaykurokawa when would that happen? Can that support never be spent? Or would it go back to the sending address?

@kaykurokawa when would that happen? Can that support never be spent? Or would it go back to the sending address?
kaykurokawa commented 2018-07-25 21:32:05 +02:00 (Migrated from github.com)

Claims can be attached to any kind of Bitcoin transaction.
Bitcoin transactions do not necessarily have an address attached to it (i.e., some kind of un-spendable transaction )

Claims can be attached to any kind of Bitcoin transaction. Bitcoin transactions do not necessarily have an address attached to it (i.e., some kind of un-spendable transaction )
BrannonKing commented 2019-09-06 22:14:59 +02:00 (Migrated from github.com)
Merged via https://github.com/lbryio/lbrycrd/pull/303
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbrycrd#92
No description provided.