Bitcoin Forum
November 17, 2017, 09:40:55 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Questions about blockchain.address.subscribe  (Read 720 times)
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
May 21, 2014, 08:06:46 PM
 #1

I am in the process of writing an alternative electrum server.  Without derailing into why I am doing that I have a few questions.

When a client calls blockchain.address.subscribe the response seems to be a hash of the transaction IDs and block heights known to that server in a particular form.
- descending order by block height
- For each transaction: "txid:height:"

All this sha256ed and then returned.

Does this checksum need to be the same between electrum servers?  (Do I need to do the same exact things to be compatible?)

If so, what do I put for height if a transaction is unconfirmed?
How do I order them if they are at the same height?

If there is a doc somewhere that has this spelled out, I would love that.
1510954855
Hero Member
*
Offline Offline

Posts: 1510954855

View Profile Personal Message (Offline)

Ignore
1510954855
Reply with quote  #2

1510954855
Report to moderator
A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1510954855
Hero Member
*
Offline Offline

Posts: 1510954855

View Profile Personal Message (Offline)

Ignore
1510954855
Reply with quote  #2

1510954855
Report to moderator
1510954855
Hero Member
*
Offline Offline

Posts: 1510954855

View Profile Personal Message (Offline)

Ignore
1510954855
Reply with quote  #2

1510954855
Report to moderator
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
May 21, 2014, 09:51:05 PM
 #2

Well, my theory of the order was wrong.

It appears the order is something I can't figure out.  I'm going to assume it is probably based on native order of some python hash implementation and didn't need to be consistent across servers.
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
May 27, 2014, 03:28:40 PM
 #3

In case anyone cares and finds this (as per http://xkcd.com/979/) I'll include what I have found.

The order of the transactions does not seem to matter.  However, you need agreement between what you send for blockchain.address.get_history and the order used for making the hash in blockchain.address.subscribe or the client will reject it.

The client is taking the list from the history message (in the order that they appear) and doing the hash and making sure that matches with the hash given by the address subscription.

In both the history and the hash, an unconfirmed transaction should be listed with a height of 0.  This was getting me because I happened to be using the string 'null' instread of zero for the hash and then the client was rejecting my address history.

So I am ordering by transaction ID and that seems to work well.

This of course means there is a race condition between when you report a new hash and when the client asks for the history.  If there is more action on that address between those two, the client will reject the history and not try again.  I think it stayed in state synchronizing which would probably work.  The new address hash should come in and then the client should ask for the new history and get it again, hopefully matching this time.  So this is actually probably a self-correcting problem assuming your server isn't pants-on-head.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!