nano-docs
nano-docs copied to clipboard
Incorrect 'account' field for account_history RPC response with epoch blocks
When executing the following RPC request (using raw
set to true):
{
"action": "account_history",
"raw": true,
"account": "nano_3xinwsdt57qo5bcysock15do87r9fuepq84erab5udm6wekymq9e9tiin8hw",
"count": 1
}
The following response JSON is received:
{
"account":"nano_3xinwsdt57qo5bcysock15do87r9fuepq84erab5udm6wekymq9e9tiin8hw",
"history":[
{
"type":"state",
"representative":"nano_3o7uzba8b9e1wqu5ziwpruteyrs3scyqr761x7ke6w1xctohxfh5du75qgaj",
"link":"65706F636820763220626C6F636B000000000000000000000000000000000000",
"balance":"4999994000100000000000000000000000000",
"previous":"3FF8EC2F80C4082376C8CB771361F98133546AAC70B3AF877DA286E80BC9A7BE",
"subtype":"epoch",
"account":"nano_3qb6o6i1tkzr6jwr5s7eehfxwg9x6eemitdinbpi7u8bjjwsgqfj4wzser3x",
"local_timestamp":"1599338646",
"height":"4",
"hash":"5D285CF3B6337D5F3ACC3A579009A25EA50D22790BA000443A0878EE5BF191DF",
"work":"7edeae032b6ef3ea",
"signature":"4FA69BEE4A028D4AAB4EEE214E1E68A971CDB8CD6DE17E6700ABED5BCE5E6F0558750931BC5A4074FF91DB311F3568803800DE6A7B95109CD878132C4918E603"
}
],
"previous":"3FF8EC2F80C4082376C8CB771361F98133546AAC70B3AF877DA286E80BC9A7BE"
}
Note that the account
field for the block is actually the epoch signer, rather than the account which the block belongs to, which is not what I would expect. If this is an intentional feature, it isn't currently mentioned on the docs page and should probably be added.
I don't currently have time to fix the issue myself, sorry.
I believe this is the intended behavior, similarly to how send and receive blocks show the corresponding destination/source , not the account to which the block belongs (which is always the account
you give to this command).
Example from beta. First block at the bottom is the open (receive) block, receiving a block sent from nano_3betagfmasj5iqcayzzssba185wamgobois1xbfadcpqgz9r7e6a1zwztn5o
. Top block is a send to nano_1dotspi3aget1n1j9dmi7ct9ezawm8kfzia3dejbu3zcty1uwoiw3jiix9wj
. If there were an epoch block, it would show the corresponding signer.
{
"account": "nano_3dotcomuaymwna1zbwed1mhaz9cm6zgxnmxn1313udp95ujj8sbkkc39o654",
"history": [
{
"account": "nano_1dotspi3aget1n1j9dmi7ct9ezawm8kfzia3dejbu3zcty1uwoiw3jiix9wj",
"amount": "1000000000000",
"balance": "266496590000000040497182005385687040",
"hash": "032095EFE3B2A9504A3F38297611C9A9E763EC60877C0FC6F18B31DA0D292799",
"height": "2",
"link": "2EBACDA014399A050113AE702AB4767D1C99A4DFC1015B229D87EAD781BE561C",
"local_timestamp": "1601278638",
"previous": "71814930B75CDC296445E5F99DE17C3449A539DF980DF11230DAC56A700E476C",
"representative": "nano_3dotcomuaymwna1zbwed1mhaz9cm6zgxnmxn1313udp95ujj8sbkkc39o654",
"signature": "024540CF66489AD857B4154605C2AC96B58C2BDDDBF5CC18B52D389A7842447E769C1B0005CBCC0117E5FE0C3C23C4C688F1351F5817EDB495C254DE8102CF07",
"subtype": "send",
"type": "state",
"work": "becee4e904ad7bba"
},
{
"account": "nano_3betagfmasj5iqcayzzssba185wamgobois1xbfadcpqgz9r7e6a1zwztn5o",
"amount": "266496590000000040497183005385687040",
"balance": "266496590000000040497183005385687040",
"hash": "71814930B75CDC296445E5F99DE17C3449A539DF980DF11230DAC56A700E476C",
"height": "1",
"link": "DA49368DFB772CDDD3A2194D0AAFE11F371FCC46BAF51B379D5ED236D78A31CB",
"local_timestamp": "1601066704",
"previous": "0000000000000000000000000000000000000000000000000000000000000000",
"representative": "nano_3dotcomuaymwna1zbwed1mhaz9cm6zgxnmxn1313udp95ujj8sbkkc39o654",
"signature": "8D84BBA53A1DED114BECD32E490746CFBF6615202A06BAFD0B8EF2D66CBCB017C7186998621ADBA461153EBA0F427A538BD3E344D96BDC5899E999282F9F0600",
"subtype": "receive",
"type": "state",
"work": "fef665dde80b2a3e"
}
]
}
In that sense, mentioning this behavior in more detail in the docs seems appropriate.
That makes sense then. I assumed that the data represented the actual blocks as it contained additional block fields (signature, link and work), rather than aggregated information about the blocks.