protocol 1.7#2
Conversation
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
SomberNight
force-pushed
the
202502_protocol_next
branch
2 times, most recently
from
d32a69e to
c10f63f
Compare
SomberNight
force-pushed
the
202502_protocol_next
branch
2 times, most recently
from
e74e0f1 to
9e02865
Compare
SomberNight
force-pushed
the
202502_protocol_next
branch
from
ff53c91 to
1c30e19
Compare
SomberNight
force-pushed
the
202502_protocol_next
branch
from
1c30e19 to
337b006
Compare
SomberNight
force-pushed
the
202502_protocol_next
branch
from
f17061d to
7911396
Compare
This is a minimal changeset for a new protocol version. The ideas for the less trivial changes are deferred a bit, just so we get something out. ref spesmilo#2 ref spesmilo/electrumx#90
|
|
||
| **Signature** | ||
|
|
||
| .. function:: blockchain.outpoint.subscribe(tx_hash, txout_idx, spk_hint=None) |
There was a problem hiding this comment.
note: bitcoin core added a txospenderindex, to be used with the gettxspendingprevout RPC.
ref bitcoin/bitcoin#24539
- see what their API looks like and maybe adapt what we add to that
- in particular we could put
spender_blockhashin the response - they also have an option to put the full tx in the response
- in particular we could put
SomberNight
force-pushed
the
202502_protocol_next
branch
2 times, most recently
from
7efc355 to
7eb1d59
Compare
| If a server supports all functionality defined for the negotiated protocol version, | ||
| it can just set this to the empty dict (but the `method_flavours` key itself | ||
| must always be present). | ||
|
|
There was a problem hiding this comment.
I think method_flavours should be postponed for now, because its role is not clear.
it seems that what it wants to achieve collides with the features negotiation proposal in #7
There was a problem hiding this comment.
OTOH it would be good if the server could clearly signal whether it requires spk_hint for blockchain.outpoint.subscribe.
method_flavours["blockchain.outpoint.subscribe"]["requires_spk_hint"]=true was the motivating use case for method_flavours. (see e.g. 4b4dcda)
Or do we accept that there is no way for a client to know whether the server requires spk_hint, for now?
There was a problem hiding this comment.
We could make spk_hint a mandatory field for now, and perhaps make it optional in a future version with proper feature flags. In all reasonable scenarios, the client should know the corresponding spk.
SomberNight
force-pushed
the
202502_protocol_next
branch
2 times, most recently
from
e4a702a to
e3fd26e
Compare
SomberNight
force-pushed
the
202502_protocol_next
branch
from
e3fd26e to
1116c35
Compare
SomberNight
force-pushed
the
202502_protocol_next
branch
from
1116c35 to
ed7724a
Compare
4 participants
This defines a new protocol version: 1.7.
changes compared to 1.6:
blockchain.scripthash.*methods are all replaced withblockchain.scriptpubkey.*methodsblockchain.scriptpubkey.*endpoints #3blockchain.outpoint.subscribeRPC (and related RPCs) to subscribe to a transactionoutpoint, and get a notification when it gets spent.
server.pingcan now also be sent as an unrequested notification, by both the clientand the server. The request/response signature also changed.
blockchain.scriptpubkey.*methodsblockchain.transaction.testmempoolaccepttestmempoolaccept#11mempool.recentto list a few of the latest txs just added to the mempool.mempool.recentprotocol method #13This proposal is less ambitious than previous versions of 1.7:
method_flavoursfield for theserver.featuresresponse is also postponed,as I realised we are not clear re how to signal/negotiate optional features
server.versionfor feature negotiation #7 ideaWe have a client implementation in spesmilo/electrum#10627,
and a server implementation in spesmilo/electrumx#303.