networks/eth: Add methods to decode tx data. #1215
Conversation
JoeGruffins
commented
Sep 16, 2021
•
JoeGruffins
commented
|
What do you want to use this for? Just wondering. |
|
For the server, when initially receiving an initialize or redeem request, it is able to do more verification while the tx is in mempool. Otherwise we can only take the client's word that they sent a swap with x secret hash and conterparty y. We can look at the mempool tx to decided if it looks ok before mined, and can fail faster in the case it is a bum transaction. We will still check the contract once there are confirmations. |
JoeGruffins
force-pushed
the
ethdecodedata
branch
2 times, most recently
from
9af3b4d to
22fadf9
Compare
JoeGruffins
changed the title
| // This file is part of the go-ethereum library. | ||
| // | ||
| // The go-ethereum library is free software: you can redistribute it and/or modify | ||
| // it under the terms of the GNU Lesser General Public License as published by |
There was a problem hiding this comment.
I think it's OK to mix LGPL without tainting the blue oak (both permissive, allowed to be used in proprietary software). Fortunately they only use gpl for the actual geth executable app.
There was a problem hiding this comment.
OK, so feedback from @jrick ... the benefit of lgpl over gpl only applies when dynamically linking. While we are an open source project and it doesn't affect us, any proprietary software building on dcrdex would be affected unless they rip out these bits. If we revisit the plugins idea, which is is dynamically linked libraries if I understand that correctly, it would be alright, but plugins sucked for a number of reasons including cgo.
Possibly we could make just eth dynamically linked.
Thoughts? Ask go-ethereum CR holders permission to use these functions under a different license (ha!)?
There was a problem hiding this comment.
This affects the imports of go-ethereum as well actually, so let's decide on a plan for keeping such code segregated from the most common importable packages in dcrdex.
As long as we only import go-ethereum from obviously eth-specific packages (we do), a third party consumer can fairly easily avoid accidentally importing (and statically linking) LGPL code.
The design we have of only the actual applications like dexc and dcrdex importing the asset drivers is fortunate since all other importable packages in our repository, other than the .../eth ones, will be free of the LGPL code.
To make sure this doesn't change, I suggest we comment or make a readme in each package that either imports go-ethereum code or has such lifted code, describing clearly that by importing the package the consumer is linking LGPL code.
There was a problem hiding this comment.
gate all eth usage behind a build tag.
| } | ||
| // Everything valid, assemble the call infos for the signer | ||
| decoded := decodedCallData{signature: method.Sig, name: method.RawName} | ||
| for i := 0; i < len(method.Inputs); i++ { |
There was a problem hiding this comment.
We should probably just leave the code verbatim so we can more easily apply fixes/updates from upstream, but it bugs me they don't just range... or allocate decoded.inputs. Oh well
JoeGruffins
force-pushed
the
ethdecodedata
branch
3 times, most recently
from
cf62249 to
60054b1
Compare
|
I assume this is the right direction. |
JoeGruffins
force-pushed
the
ethdecodedata
branch
from
60054b1 to
9fcf740
Compare
There was a problem hiding this comment.
Looks about right, although I request a little less specific wording about the consequences of using LGPL in closed source software because it's a lot more nuanced and really the concern of those developers. We just want to make it harder to screw up an use lgpl code assuming everything in this repo is permissive.
Also, my gofmt is segregating the build tag comments. You must be using Go 1.16 or earlier, because the formatter changed in Go 1.17. So I'd like to separate and reorder file comments: license, build tags, and then package docs (the ones that should start // Package eth ... ). Examples from golang packages: golang/text@8f690f2#diff-e03ec920b0cdec012a5f833c15db00c9d4ce59332ac08e9a90bd5e32e9ad16fb
In order to check data in a mempool transaction is formatted as we expect and in order to read its arguments, add package methods that are able to parse and validate Initiate and Redeem transaction data. Some of this code is taken directly from the go-ethereum repository where it is unexported there. abi.go and abi_test.go should be updated if they change over there.
The ethereum-go library requires a more restrictive liscense. Our code that uses that code must respect the same restrictions. Add a build tag to prevent building code that requires extra permissions without adding the gpl tag.
JoeGruffins
force-pushed
the
ethdecodedata
branch
from
9fcf740 to
9beb950
Compare
