Implementing blockchain.transaction.get merkle arg

[JeremyRand]

Would a pull request be accepted that implements the merkle argument for blockchain.transaction.get, without implementing the other features that are currently in the protocol 1.5 spec? (I have a direct use for that argument and would possibly like to implement it, but I don't have time to implement the rest of the 1.5 spec.) If it would be accepted, should the protocol be marked as 1.5 (thus bumping the rest of the features to 1.5.1), or should it be marked as 1.4.2 (leaving the rest of the features for 1.5)?

[kyuupichan]

How do you intend to get the height?

[kyuupichan]

Oh, and regarding 1.5; I wish I'd never named it that. If you're updating the docs call it 1.10 or something

[JeremyRand]

How do you intend to get the height?

@kyuupichan You're asking about how I would obtain the height arg to pass to transaction_merkle? Hmm, so I see two approaches:

1. If we pass True to the daemon's getrawtransaction verbose arg, then we'll get a block hash; we can then pass that to the daemon's getblockheader method (with verbose set to True) which will yield a height.
2. For the use cases I'm interested in, the client already knows the desired height when it calls blockchain.transaction.get, so I could replace the boolean merkle argument with an integer merkle_height argument, where a default value of 0 disables returning a Merkle proof.

For selfish reasons (i.e. it gets the job done for my use cases without introducing extra latency from a daemon request), I prefer the 2nd option myself. Thoughts?

[kyuupichan]

Sounds good to me

[kyuupichan]

I'm taking the protocol in a different direction going forwards