LBRYCommunity/lbrycrd

Fork 0

lbrycrdd allows broadcasting transactions containing invalid updates #116

New issue

Closed

opened 2018-04-05 00:53:33 +02:00 by jackrobison · 8 comments

jackrobison commented

2018-04-05 00:53:33 +02:00

(Migrated from github.com)

broadcast will send transactions containing claim update outputs where the claim id is invalid. Invalid claim id sizes as well as incorrect or non-existent claim ids all get through. Attempting to broadcast such transactions should return a transaction rejected error.

`broadcast` will send transactions containing claim update outputs where the claim id is invalid. Invalid claim id sizes as well as incorrect or non-existent claim ids all get through. Attempting to broadcast such transactions should return a transaction rejected error.

bvbfan commented

2018-08-14 14:42:11 +02:00

(Migrated from github.com)

Someone to work on?

bvbfan commented

2018-08-17 13:22:12 +02:00

(Migrated from github.com)

@BrannonKing, @lbrynaut i don't think returning transaction rejected will be suitable for this error, what you think? I'm to find out incorrect statements compile time, rather than returning error condition in runtime. Updating claimId should not make it with incorrect size (i investigate and still not see how the size can be incorrect) or non-existing claimIds.

kauffj commented

2018-08-17 15:26:18 +02:00

(Migrated from github.com)

@jackrobison if you're able include the specific examples of transactions you're able to broadcast but should not be able to, it'd make this ticket stronger.

bvbfan commented

2018-08-20 16:45:40 +02:00

(Migrated from github.com)

https://github.com/lbryio/lbrycrd/pull/192

lbrynaut commented

2018-09-04 15:39:13 +02:00

(Migrated from github.com)

Just noting that #192 does not solve the issue posted.

Edit: While it might help a user not create an invalid transaction, a tx created out of band would still be relayed/broadcasted, so it only addresses a small part of the problem.

Edit 2: On second thought, that shouldn't happen. @jackrobison Can you confirm if this issue is requesting not being able to create txs with invalid claims, or if in fact you saw txs with invalid claims being relayed?

Just noting that #192 does not solve the issue posted. Edit: While it might help a user not create an invalid transaction, a tx created out of band would still be relayed/broadcasted, so it only addresses a small part of the problem. Edit 2: On second thought, that _shouldn't_ happen. @jackrobison Can you confirm if this issue is requesting not being able to create txs with invalid claims, or if in fact you saw txs with invalid claims being relayed?

jackrobison commented

2018-10-10 19:23:41 +02:00

(Migrated from github.com)

@lbrynaut I had encountered this on lbryum-server, where it was running a lbrycrdd node and had made the broadcast rpc call (passing through a transaction sent to it from a lbryum client). The rpc went through without returning an error (I believe it returned a txid).

I'll try this again later today and post the results.

@lbrynaut I had encountered this on lbryum-server, where it was running a lbrycrdd node and had made the `broadcast` rpc call (passing through a transaction sent to it from a lbryum client). The rpc went through without returning an error (I believe it returned a txid). I'll try this again later today and post the results.

BrannonKing commented

2019-02-12 23:45:23 +01:00

(Migrated from github.com)

The sendrawtransaction method relays messages even if they aren't accepted into the local memory pool. This has been repaired in the upstream bitcoin, in mid 2016.

The `sendrawtransaction` method relays messages even if they aren't accepted into the local memory pool. This has been repaired in the upstream bitcoin, in mid 2016.

BrannonKing commented

2019-05-08 16:46:46 +02:00

(Migrated from github.com)

This is fixed now that we have the upstream master merged.

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#116

No description provided.