initial commit of metadata on supports #312

Merged
BrannonKing merged 2 commits from metadata_for_supports into master 2019-09-14 00:18:37 +02:00
BrannonKing commented 2019-09-04 22:29:15 +02:00 (Migrated from github.com)

The nonstandard transactions themselves should be okay in the current code; we just don't want a different hash or trie computation until the fork height.

Fixes #272

The nonstandard transactions themselves should be okay in the current code; we just don't want a different hash or trie computation until the fork height. Fixes #272
lbrynaut (Migrated from github.com) reviewed 2019-09-04 22:29:15 +02:00
bvbfan (Migrated from github.com) reviewed 2019-09-09 13:28:12 +02:00
bvbfan (Migrated from github.com) commented 2019-09-09 13:12:17 +02:00

It does not look correct or we miss OP_SUPPORT_CLAIM && !allowSupportMetadata it's same as OP_CLAIM_NAME ?

It does not look correct or we miss OP_SUPPORT_CLAIM && !allowSupportMetadata it's same as OP_CLAIM_NAME ?
bvbfan (Migrated from github.com) commented 2019-09-09 13:27:40 +02:00
switch (op) {
    case OP_SUPPORT_CLAIM:
        if (allowSupportMetadata)
        // fallthrough
    case OP_UPDATE_CLAIM: {
        if (opcode < 0 || opcode > OP_PUSHDATA4)
            return false;
        if (!scriptIn.GetOp(pc, opcode))
            return false;
    } // fallthrough
    case OP_CLAIM_NAME:
        if (opcode != OP_2DROP)
           return false;
    break;
}
``` switch (op) { case OP_SUPPORT_CLAIM: if (allowSupportMetadata) // fallthrough case OP_UPDATE_CLAIM: { if (opcode < 0 || opcode > OP_PUSHDATA4) return false; if (!scriptIn.GetOp(pc, opcode)) return false; } // fallthrough case OP_CLAIM_NAME: if (opcode != OP_2DROP) return false; break; } ```
BrannonKing (Migrated from github.com) reviewed 2019-09-09 21:44:02 +02:00
BrannonKing (Migrated from github.com) commented 2019-09-09 21:44:02 +02:00

I don't understand your concern here. The logic is "if not a claim op and have another data chunk", that's fine -- that's what we want. That third data is required on the update op but not required on the support op.

I don't understand your concern here. The logic is "if not a claim op and have another data chunk", that's fine -- that's what we want. That third data is required on the update op but not required on the support op.
bvbfan (Migrated from github.com) reviewed 2019-09-10 08:10:15 +02:00
bvbfan (Migrated from github.com) commented 2019-09-10 08:10:14 +02:00

I was afraid on op == OP_SUPPORT_CLAIM and allowSupportMetadata == false we can enter in by the condition but opcode is OP_2DROP so it's OK.

I was afraid on op == OP_SUPPORT_CLAIM and allowSupportMetadata == false we can enter in by the condition but opcode is OP_2DROP so it's OK.
Sign in to join this conversation.
No reviewers
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#312
No description provided.