add: track P2A inputs and outputs in backend

[andrewtoth]

Could be useful to track mining pools upgrading to v28.

[0xB10C]

looks good to me modulo the rawtx-rs dependency.

I'll fix the frontend CI job. (edit: done in #19)

[0xB10C]

feel free to upgrade to rawtx-rs v0.1.14 and rebase on master (to include #19)

[andrewtoth]

@0xB10C done!

[0xB10C]

Thanks! I'll re-run the backend with this and then look into setting up a frontend chart. (#22)

[0xB10C]

Seems to be working for the outputs:

sqlite> select height, outputs_p2a from output_stats where outputs_p2a > 0;
850000|1
850307|1
850457|1
867257|1
867322|1
867335|1
867352|1
874230|1
877358|1
879678|1
879682|1
879684|1
881521|1

But P2A input detection seem to be weird:

select height, inputs_p2a from input_stats where inputs_p2a > 0;
211914|2
211997|1015
249387|2
249976|1
488047|1
692261|4
831489|10
867278|1
874207|3
874534|1
876523|3
879613|7309
880159|1
880512|7394
881521|1
881696|3

[0xB10C]

This is related to these custom blocks https://mempool.space/de/block/00000000000000000001c3fbc76a7efe7a320a8236ea6250bc15e4f7a67e727d.

They used empty inputs: https://mempool.space/de/tx/e0c7e627793bb9da1003fd86323f94fdd02a1513a4ac62a573287dc0ae92ce17

[andrewtoth]

Right, there's no way to really differentiate p2a inputs from other non-standard txs that don't have script sigs or witnesses.
We would have to get the prevout for these inputs.

[andrewtoth]

What do you recommend?
We can fetch the prevout via REST if we encounter a p2a like input, but that would make us inject async all the way down.

[0xB10C]

I think just leaving a note on potential charts that P2A inputs don't have a distinct signature and there are known false-positives is fine.

[murchandamus]

Would it perhaps be possible to keep track of P2A outputs and detect P2A inputs per them spending P2A outputs?

[andrewtoth]

That's essentially what fetching prevouts does. The outputs are stored in bitcoind. If there's lots that will be a lot of duplicate data in postgres.

[0xB10C]

Yeah, that'd essentially be like keeping an index for P2A outputs, which transactionfee-info currently does not do and can't do with it's current architecture (as it processes blocks in multiple threads and possibly out of order).

[0xB10C]

One option would be to fetch the block as JSON via the getblock RPC with verbosity 3, which includes prevout information.

However, the REST interface is faster, is easier to set up as it doesn't require authentication, and we don't need to parse JSON transactions, convert the hex values in JSON to binary, and then deserialize these to rust-bitcoin transactions.

[andrewtoth]

We could fetch and parse the tx that contains the prevout via REST, only for inputs that are potential P2As.

Oh, but that would require txindex.

[andrewtoth]

Oh, since bitcoin/bitcoin#22918 the JSON response from REST has the prevout information as well. So, we can get the prevouts using REST. It will be slower, but we can still do it using REST and in parallel.

Perhaps if we encounter a possible P2A input, we can then fetch the block using .json.

[0xB10C]

Oh, indeed! Cool. Then it probably makes sense to only have a .json alternative to

transactionfee-info/backend/src/rest.rs

Lines 93 to 100 in 5e2dc02

	let url = format!("http://{}:{}/rest/block/{}.bin", self.host, self.port, hash);
	let response_block = minreq::get(url).send()?;
	if !(response_block.status_code == 200 && response_block.reason_phrase == "OK") {
	return Err(RestError::HTTP(
	response_block.status_code,
	response_block.reason_phrase,
	));
	}

which deserializes it into a lightweight Transaction and InputPrevOut type similar to:

#[derive(Deserialize)]
pub struct Transaction {
    pub txid: String,
    pub hex: String,
    pub fee: f64,
    pub inputs: Vec<InputPrevOut>,
}

#[derive(Deserialize)]
pub struct InputPrevOut {
    pub height: u64,
    pub value: f64,
    pub script: String, // hex
}

This would allow us to:

1. detect fees and feerates (again)
2. use the prevouts identifying scripts (e.g. P2A, but also P2SH outputs which we currently can't https://transactionfee.info/charts/inputs-and-outputs-p2sh/)
3. use the prevout height to track how old spent value is on average (similar to bitcoin-days-destroyed)

[0xB10C]

Or possibly even better: implement verbosity 3 for https://crates.io/crates/corepc-types similar to https://docs.rs/corepc-types/0.5.0/corepc_types/v28/struct.GetBlockVerbosityOne.html