Add submitpackage support

[tnull]

Based on #22.

Rebased after #22 landed. Should be good for review.

[tcharding]

Looks good so far.

[tcharding]

These structs look good, we will need to also add similar structs in json/src/model and also into_model() functions on each of them here in this module.

[tnull]

Ah, I think on the first attempt I didn't quite get when code would fully live in one of the vXX modules and when it would go in model. IIUC, Is the idea that everthing should be duplicated in model and the model is fed with the respective implementations based on the features?

[tcharding]

In model the structs are fully typed i.e., in the respective json version module we use standard language types (String, u32) and in model we use bitcoin types (BlockHash, Version). The into_model function is to do the conversion. The hope is that then the model structs will be somewhat universal across all the Core versions without having a bunch of conditional logic in them. We will only know if this works after writing a bunch more code though. I did iterate quite a few times already to get to this design, so I am hopeful.

[tnull]

Hmm, I think I still don't fully get why the model is necessary. Why can't we just use serde's with attribute for the fields that need to be de/serialized differently from their Rust type?
It would allow to avoid a lot of redundant boilerplate, at least if I understand the problem at hand correctly?

For example, see these definitions: https://github.com/lightningdevkit/lightning-liquidity/blob/8dd8a1cdf52d5913ff18d9677c152c521b22c4cc/src/lsps0/ser.rs#L603-L678 which are used here: https://github.com/lightningdevkit/lightning-liquidity/blob/8dd8a1cdf52d5913ff18d9677c152c521b22c4cc/src/lsps2/msgs.rs#L85-L105

[tcharding]

The problem the model module is trying to solve is multiple versions of Core returning different things for the same JSONRPC method. This led, in rust-bitcoincore-rpc, to loads of logic inside the types crate to handle the differences, this was scattered all over the place making it hard to know exactly what was supported and what was not. The idea in this repo is to make the version specific types dumb as possible, then the model types are, if possible, some representation of the data returned by all supported Core versions. Each version specific type then implements into_model (if possible). Users are free to not use the model types at all if they only want standard typed fields and not the rust-bitcoin typed fields in model. Does that make sense?

[tcharding]

it's not clear to me what happens if we in fact can't easily accommodate a breaking change, i.e., would we end up with multiple models?

Definitely not, we just modify the model. The model structs can become as convoluted as necessary and still not effect easy reading, writing, and usage of the version specific JSON types. Then there are no strange JSONRPC errors to debug.

[tnull]

I don't think there is a good solution to Core's JSONRPC API returning different data for different versions

Mhh, I see the issue for the raw JSON types, but want to note we could somewhat mitigate the issue in the client implementation by checking the version after connection (e.g., through getnetworkinfo), and switch to the matching types accordingly? In any case, I'll just proceed for now.

[tcharding]

Yes in theory, but someone somewhere said that some ops guys disable that RPC method for some security reason that I don't remember so their is no reliable way to get the version. The fella shortly afterwards did a PR to Core to add a new method to get just the version. I can dig it out if you want but since we want to support old versions it doesn't help us much.

[tnull]

I can dig it out if you want but since we want to support old versions it doesn't help us much.

Since it came up once or twice since you wrote this, I'd actually be interested to hear how and why they do this. Do you think you can still find it?

[tcharding]

Right now I have no clue, but I can keep you in mind and message you if/when I stumble upon it.

[tcharding]

Woops, no need to run CI we know its going to fail because there is no binary to pull down.

[tcharding]

How hard was it to work out how to patch this repo @tnull? I realise its a bit unusual, from your experience do you think I'm correct in thinking that there is no point asking more junior devs to work on this repo because its a little too strange?

[tnull]

How hard was it to work out how to patch this repo @tnull? I realise its a bit unusual, from your experience do you think I'm correct in thinking that there is no point asking more junior devs to work on this repo because its a little too strange?

Given there are no docs describing the ideas behind the project layout (w.r.t. features etc) it took a while to get the hang of it. I think if it would be clearly documented how everything's supposed to work it shouldn't be too hard to contribute though, even for more junior devs.

[tcharding]

No sweat, I actually added a wiki doc yesterday before reading your comment above but we can do even better. Thanks man.

[tnull]

I now rebased this after #22 landed, fixed some minor things and added a really basic test for most of the introduced API types (we don't actually test package submission, but submission of two already-known transactions).

Should be good for review (cc @tcharding)

[tcharding]

Thanks for the work man, I didn't review closely but a few quick comments:

• Can you do this as a single patch please since its a discreet change
• Can you remove the commented out docs from Bitocin Core in json/src/v28/raw_transactions.rs
• We either need an issue saying "Implement into_model for SubmitPackage" or we should implement it in this PR

[tcharding]

Suggested change

	/// Models the result of JSON-RPC method `submitpackage`.
	/// Result of JSON-RPC method `submitpackage`.

So folk don't get confused between this and the model module types.