ethers / ethereumbitcoinswap Goto Github PK

ensure no errors in JS console

separate issue from #48 since the contract balance is in a different template

to avoid locking up the browser

to guarantee that stopWatching() on the filter is called

perhaps a 3rd state/button is needed if a ticket has been reserved by someone other than currentUser

may be able to use https://github.com/ConsenSys/testrpc

an example is to test the behavior when a reserved ticket expires

provide guidance to ether buyers that need a 3rd party, how much etherFeePercent they should specify for 3rd parties.

this involves analysing the costs of reserveTicket() and claimTicket(). probably do after work on #15

duplication in watches and the call-then-sendtx pattern could probably be reduced

it will be replaced by PoW on the txHash

should try to always ensure ticketId is a number; remove parseInt call

this was found by reserving a ticket, then remaining on the claim view, change the ticketID, click Lookup, and try reserving a differnt ticket. in ethReserveTicket() ticketId was a string instead of number, so the subequent switch statement wasn't equal

• use viewmodel like done in other views
• use call-then-sendtx pattern
• check behavior against cpp eth

group them all together

when a new ticket is created, a user should be able to look at the tickets and see the new ticket, without doing a refresh

add a field for forwards compatibility of allowing a ticket to be partially reserved

macro CLAIM_FAIL_INVALID_TICKET: 99990050
macro CLAIM_FAIL_UNRESERVED: 99990070

create 2 identical tickets. the tickets should probably not be claimable by reusing the same tx

needs review and addition of other info such as the first block

#46 only updates the claimTicket view, so if the user clicks on Tickets tab, the ticket will still show "Reserve" instead of claim.

something like TicketColl.update(ticketId, { viewm.claimerAddr(web3.eth.defaultAccount.substr(2)), viewm.claimTxHash(txHash.substr(2), viewm.claimExpiry(moment().add(4,'hours').unix()) } might fix it

a mechanism to prevent txhash-nonce from being repeated

Claim a ticket, and then click on Tickets tab. a (manual) refresh is needed to see that the ticket is removed from the table

In table view, click Claim. Then change ticket id with one that's already been claimed. Use a valid raw transaction (perhaps same one that claimed the original ticket). Click Lookup.
EXPECTED: no buttons enabled
OBSERVED: Reserve button is enabled blue. UI is using the details from the prior ticket.

sortOrder should be a positive number, and the primary sort will be the field with the lowest sortOrder. sortDirection should be 1 for ascending or -1 for descending. Either of these can also be a ReactiveVar, which will be updated whenever the user changes the sorting, and will update the table whenever it's changed.

inputs for txhash and powNonce and output pass/fail

they are high, but probably should become small negative numbers

reserve a ticket (fast expiry)
go to the Claim tab
observe the expiry change to OPEN
press Claim

EXPECTED
CLAIM_FAIL_UNRESERVED

OBSERVED
Claim would succeed (ticketId was returned)

this condition needs to be expanded

    if (claimExpiry == FRESH_TICKET_EXPIRY):
        log(type=ticketEvent, ticketId, CLAIM_FAIL_UNRESERVED)
        return(0)

CLAIM_FAIL_FALLTHRU should not happen, instead when verifyTx fails it should return something else like CLAIM_FAIL_PROOF

should re-check if sending the ticket price is enough

eth_call should return same error code as what is logged, instead of always returning 0

the first it verifies ok, but after changing the nonce to a failing one, changing the nonce to a passing one still keeps failing