Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add postSignedTx to HttpBridge #130

Merged
merged 3 commits into from
Apr 2, 2019
Merged

Add postSignedTx to HttpBridge #130

merged 3 commits into from
Apr 2, 2019

Conversation

Anviking
Copy link
Member

@Anviking Anviking commented Mar 28, 2019

Issue Number

#89

Overview

Adds support for submitting signed transactions to the node / httpBridge.

  • Added encodeSignedTx, encodeWitness,
  • Improved decodeSignedTx and decodeWitness
  • Added SignedTx <base64> type and sign :: Tx -> [Witness] -> SignedTx
  • Added support for submitting txs to POST :network/txs/signed

Comments

  • Rebased into 3 commits: 1) stub API, 2) extend Binary.hs, 3) connect the two and add integration tests for submitting signed txs

Copy link
Contributor

@akegalj akegalj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good so far

src/Cardano/Wallet/Binary.hs Outdated Show resolved Hide resolved
src/Cardano/Wallet/Binary.hs Outdated Show resolved Hide resolved
@Anviking Anviking force-pushed the anviking/89/network-post-tx branch from fe4769d to eb58cda Compare April 1, 2019 11:32
@Anviking Anviking marked this pull request as ready for review April 1, 2019 11:33
src/Cardano/Wallet/Binary.hs Show resolved Hide resolved
src/Cardano/Wallet/Binary.hs Outdated Show resolved Hide resolved
<> mconcat (map encodeOne list)

sign :: Tx -> [Witness] -> SignedTx
sign tx witnesses = signedTxFromBS . toBS $ encodeSignedTx (tx, witnesses)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure about the location of this function as well as SignedTx

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For lack of a better place, I think they're fine here for now. Though here I think the name is misleading. I'd expect a "sign" function to produce the actual witnesses for a given address. Here, it's really just composing things together.

(as mentioned in another comment, I don't think there's any need for that at this stage and encodeSignedTx is enough on its own).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(It is currently removed) but I don't like polluting the integration tests with imports to CBOR and BL + and forced to add cborg as dependency.

I do think/suspect something with the signature :: Tx -> [Witness] -> SignedTx should exist.

src/Cardano/Wallet/Network/HttpBridge.hs Outdated Show resolved Hide resolved
cborRoundtrip decode encode a = do
let bytes = CBOR.toLazyByteString $ encode a
let a' = unsafeDeserialiseFromBytes decode bytes
a `shouldBe` a'
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two thoughts:

  1. Arbitrary for roundtrips?
  2. Use ToCBOR/FromCBOR classes more? (I say despite having expressed scepticism of classes perviously)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no such classes (which I think is a good thing here). And, providing arbitrary instance for Tx, Block and others is trickier than it seems., although, if it just for testing encoder / decoder, we may get away with semantically invalid generators 🤔

@Anviking Anviking changed the title Anviking/89/network post tx Add postSignedTx to HttpBridge Apr 1, 2019
@Anviking Anviking requested a review from KtorZ April 1, 2019 12:02
@Anviking Anviking force-pushed the anviking/89/network-post-tx branch 3 times, most recently from 61a52c7 to 09224c7 Compare April 1, 2019 14:38
Copy link
Member

@KtorZ KtorZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work. One thing to fix before merging is the representation for SignedTx and a couple of small remarks 👍

cardano-wallet.cabal Outdated Show resolved Hide resolved
encodeTxWitness wit = mempty
<> CBOR.encodeListLen 2
<> CBOR.encodeWord8 tag
<> CBOR.encodeTag 24 -- "magic" constant
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the by, I figured while looking at the RFC 7049. 24 corresponds to the semantic "Encoded CBOR data item"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought about adding it, but didn't fit on a line, and there are multiple existing Hard-Coded Tag value in cardano-sl comments. Would go in the module level comment, or a separate solitary comment in that case 🤷‍♂️

<> mconcat (map encodeOne list)

sign :: Tx -> [Witness] -> SignedTx
sign tx witnesses = signedTxFromBS . toBS $ encodeSignedTx (tx, witnesses)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For lack of a better place, I think they're fine here for now. Though here I think the name is misleading. I'd expect a "sign" function to produce the actual witnesses for a given address. Here, it's really just composing things together.

(as mentioned in another comment, I don't think there's any need for that at this stage and encodeSignedTx is enough on its own).

@@ -318,6 +323,16 @@ newtype Timestamp = Timestamp
} deriving (Show, Generic, Eq, Ord)


-- | A signed tx is just a base64-encoded string.
newtype SignedTx = SignedTx { signedTx :: String }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The base64 encoding (or any sort of encoding actually) is good for some contexts; I'd suggest to have our core types work with types directly and perform conversions to base64, base58 or base16 (or anything else) when needed (similarly to what we do with Hash or Address).

newtype SignedTx = SignedTx { signedTx :: ByteString }

src/Cardano/Wallet/Primitive/Types.hs Outdated Show resolved Hide resolved
src/Cardano/Wallet/Network/HttpBridge.hs Outdated Show resolved Hide resolved
src/Cardano/Wallet/Network/HttpBridge.hs Outdated Show resolved Hide resolved
cborRoundtrip decode encode a = do
let bytes = CBOR.toLazyByteString $ encode a
let a' = unsafeDeserialiseFromBytes decode bytes
a `shouldBe` a'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no such classes (which I think is a good thing here). And, providing arbitrary instance for Tx, Block and others is trickier than it seems., although, if it just for testing encoder / decoder, we may get away with semantically invalid generators 🤔

@Anviking Anviking force-pushed the anviking/89/network-post-tx branch 2 times, most recently from 82e18ad to 35306d7 Compare April 2, 2019 11:17
@Anviking Anviking force-pushed the anviking/89/network-post-tx branch from 35306d7 to c6eaea7 Compare April 2, 2019 12:02
return $ ApiT . SignedTx $ bs
where
c :: String -> Either String ByteString
c bs = convertFromBase Base64 (B8.pack bs)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I should definitely add roundtrip tests

@Anviking Anviking force-pushed the anviking/89/network-post-tx branch from c6eaea7 to 028a5ef Compare April 2, 2019 12:10
@KtorZ KtorZ merged commit 598fb61 into master Apr 2, 2019
@KtorZ KtorZ deleted the anviking/89/network-post-tx branch April 2, 2019 12:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants