archive snowblossom slack dev
prev 2018-08-28 next
2018-08-28 17:12:12
bitbumper
@Fireduck Is there a way to get chain info from RPC? Something similar to http://chainquery.com/bitcoin-api/getblockchaininfo would be great. Bitcoin API getblockchaininfo: A web based interface to the Bitcoin API JSON-RPC
2018-08-28 17:12:39
Fireduck
What info specifically are you looking for?
2018-08-28 17:12:57
bitbumper
Height mostly, to ensure that my mining thread has generated enough blocks to confirm something.
2018-08-28 17:13:01
Fireduck
There is a bunch of stuff in get node status
2018-08-28 17:13:37
bitbumper
Honestly last block hash and height are the most important to me, but I didn't see them in get_status
2018-08-28 17:14:42
Fireduck
if is in there: jq .result.node_status.headSummary.header.blockHeight
2018-08-28 17:15:06
Fireduck
ugly, the understores are me, the camel case is protobuf converted to json
2018-08-28 17:15:19
bitbumper
Ah, my bad, must've missed it, thanks.
2018-08-28 17:15:30
Fireduck
no problem, it is a dump truck of data in there
2018-08-28 17:36:56
bitbumper
I think I found what tripped me up. It appears that get_status sometimes omits this field, I think it's shortly after a new block is solved. I'm working around it in a simple hacky way, but it would be nice to be able to count on its presence. ``` {'node_status': {'headSummary': {'totalTransactions': '1', 'header': {'prevBlockHash': 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=', 'powProof': [...], 'merkleRootHash': 'MHuw6LfN5sYWomgMF82/ylF2wVhEWO5fN4yfZC9tTsA=', 'utxoRootHash': 'wV7DoOvZ/IaH2ay3fJ7C9EzsgiT1ng6hPSGhiEDkUFg=', 'snowHash': 'AB6gRnrqYYrVFQk1E6S8I9SvPc7726A055lzt+sIqh4=', 'version': 1, 'nonce': 'dGXaWMC052sgSaWd', 'timestamp': '1535477134886', 'target': 'ACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='}, 'targetAverage': '56539106072908298546665520023773392506479484700019806659891398441363832832', 'workSum': '1024', 'blocktimeAverageMs': '1000'}, 'estimatedNodes': 1, 'nodeVersion': '1.3.2', 'versionMap': {'1.3.2': 1}}, 'balance': {'spendable': '100000000', 'unconfirmed_snow': 0.0, 'spendable_snow': 100.0, 'confirmed': '100000000', 'confirmed_snow': 100.0}}```
2018-08-28 17:37:21
Fireduck
interesting
2018-08-28 17:37:54
Fireduck
it shouldn't ever omit that...that would mean that the latest block summary in the BlockIngester was null for some reason
2018-08-28 17:38:31
Fireduck
ah, I see, that is the header for block 0
2018-08-28 17:38:36
Fireduck
for some damn reason
2018-08-28 17:39:30
Fireduck
protobuf omits things that are default value (like zero)
2018-08-28 17:39:43
Fireduck
so in the places where I am just converting a proto to json it can be a little confusing
2018-08-28 17:41:14
GitHub
{'node_status': {'headSummary': {'totalTransactions': '1', 'header': {'prevBlockHash': 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=', 'powProof': [...], 'merkleRootHash': 'MHuw6LfN5sYWomgMF82/ylF2wVhEWO5fN4yfZC9tTsA=', 'utxoRootHash': 'wV7DoOvZ/IaH2ay3fJ7C9EzsgiT1ng6hPSGhiEDkUFg=', 'snowHash': 'AB6gRnrqYYrVFQk1E6S8I9SvPc7726A055lzt+sIqh4=', 'version': 1, 'nonce': 'dGXaWMC052sgSaWd', 'timestamp': '1535477134886', 'target': 'ACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='}, 'targetAverage': '56539106072908298546665520023773392506479484700019806659891398441363832832', 'workSum': '1024', 'blocktimeAverageMs': '1000'}, 'estimatedNodes': 1, 'nodeVersion': '1.3.2', 'versionMap': {'1.3.2': 1}}, 'balance': {'spendable': '100000000', 'unconfirmed_snow': 0.0, 'spendable_snow': 100.0, 'confirmed': '100000000', 'confirmed_snow': 100.0}}
2018-08-28 17:47:45
bitbumper
Yeah that looks right, not a big deal then.
2018-08-28 17:47:53
bitbumper
Thought it might be a race condition thing.
2018-08-28 17:48:13
bitbumper
Did a bit more testing with my harness and couldn't get it to happen past height 2.
2018-08-28 18:05:19
Fireduck
yeah, I am having a hard time seeing how it would happen
2018-08-28 20:32:49
bitbumper
Is there an RPC call for address history? I saw it mentioned in #111 but not seeing it in the wiki.
2018-08-28 20:35:47
Fireduck
No, I wasn't sure it would be needed. I can add it quickly.
2018-08-28 20:42:27
bitbumper
Yeah we need some way to check for new deposits. If there's a recommended alternative I'm happy to use it instead, but I didn't see any way to detect new transactions via RPC.
2018-08-28 20:43:10
Fireduck
I was expecting you would use listunspent
2018-08-28 20:43:24
Fireduck
But depends on your flow
2018-08-28 20:43:42
bitbumper
That would work better honestly
2018-08-28 20:43:51
bitbumper
I just didn't see reference to it, one second
2018-08-28 20:44:04
Fireduck
list unspent should be fast and work on all nodes
2018-08-28 20:44:26
bitbumper
Ah, I just missed it, sorry.
2018-08-28 20:44:28
Fireduck
History will need a node with addr_idx turned on
2018-08-28 20:44:39
Fireduck
No worries
2018-08-28 20:48:55
Fireduck
Oh yeah, in latest update getunspent verifies proofs all the way back to utxo root for the block
2018-08-28 21:02:31
Fireduck
you want to see stuff from the mempool as well?
2018-08-28 21:03:04
bitbumper
That would be nice. I'm seeing mempool txs right now I think.
2018-08-28 21:03:50
bitbumper
Is there a way for end users to attach 'extra' to their transactions? Or would it be wiser to generate unique addresses for each end user?
2018-08-28 21:03:51
Fireduck
oh, yeah you are
2018-08-28 21:03:57
Fireduck
sorry, confused myself for a minute
2018-08-28 21:04:37
Fireduck
probably way wiser to do unique addresses per end user
2018-08-28 21:05:01
Fireduck
while the feature exists in the protocol, it isn't very accessible
2018-08-28 21:06:08
bitbumper
Got it. Are all wallets HD? And if so, is there a way to export the root key?
2018-08-28 21:06:53
Fireduck
They are not HD, specifically because some of the key types are not HD compatible and I didn't want there to be confusion of some wallets working with HD and some not
2018-08-28 21:07:58
bitbumper
Gotchya. Are all addresses currently using ECDSA secp256k1?
2018-08-28 21:08:33
Fireduck
default, yes. There is a key_mode=qhard where the keys are ECDSA, RSA-8192bit and DSTU4145 in 3of3 multisig
2018-08-28 21:08:46
bitbumper
Neat
2018-08-28 21:09:24
bitbumper
I read through the import wallet guide. It's close to our flow, but I think some massaging will be needed. Still thinking on best way to proceed.
2018-08-28 21:10:09
Fireduck
cool, let me know if I can do anything to help
2018-08-28 21:10:29
bitbumper
Something like importaddress may work well since we already have infrastructure for generating from HD keys. I'll think on it more before I bother you.
2018-08-28 21:10:59
Fireduck
yeah, can do
2018-08-28 21:11:47
Fireduck
if you went that route, what format would the keys be in?
2018-08-28 21:13:28
bitbumper
I could probably just match the encoding that you're using. We're already doing that for Amoveo and it's working well.
2018-08-28 21:14:50
bitbumper
BTW, is your address format checksummed? Looks similar to bech32
2018-08-28 21:15:16
Fireduck
in that case, just 'import' command and creating a json file with public/private key pair and an address spec would work
2018-08-28 21:15:21
Fireduck
yeah, it is checksummed
2018-08-28 21:16:28
bitbumper
Excellent. I was always surprised that ETH launched w/o checksums.
2018-08-28 21:16:31
Fireduck
honestly, I couldn't understand the math for the bech32 error correction so did my own thing. The comments in Duck32.java spell it out.
2018-08-28 21:16:46
Fireduck
so it has error detection, but not correction
2018-08-28 21:17:34
bitbumper
Ah, I gotchya. You may be able to use an off the shelf library, I know BitcoinJ is well built out.
2018-08-28 21:18:18
bitbumper
Certainly using an established addressing standard helps a lot if in the future we want to setup cold storage. We can then use Trezor or similar without much fuss.
2018-08-28 21:18:46
bitbumper
But I understand that switching address formats is a serious undertaking...
2018-08-28 21:31:56
Rotonen
@bitbumper sidenote - as a user i’d like to be able to crank out more / throwaway receive addresses too, but sure, that costs you cpu time
2018-08-28 21:33:07
Fireduck
the new changes to get unspent make it very efficent, it caches results on the rpcserver per block (since they cannot change until there is a new block). It still checks the mempool again, but that is quite fast.
2018-08-28 21:33:35
bitbumper
Noted. It's actually not so much CPU time as it is simplifying secret management and backup. Juggling a lot of private keys becomes cumbersome to manage and maintain high security.
2018-08-28 21:34:00
bitbumper
@Fireduck Cool, good to know we have the performance headroom.
2018-08-28 21:35:18
Rotonen
@bitbumper limit it to rolling last 4 or so and eat some flakes / satoshi every time one generates a new one and demand the 2nd factor to create a new one and i’m a happy camper
2018-08-28 21:36:41
Rotonen
but, as said, a sidenote, which i’ve now voiced
2018-08-28 21:39:24
bitbumper
Appreciate the feedback. Right now we actually don't support getting a "new" deposit address, but it's on the radar. Why 2FA for generating a new deposit address?
2018-08-28 21:40:23
Rotonen
so there is both an inconvenience to it and a funnel for you to lock more behind the second factor to incentivize people using it
2018-08-28 21:40:26
Fireduck
just to make it a pain so people don't do it unless they actually care
2018-08-28 21:41:12
Rotonen
also then if someone is using a stable address for real, a single post auth session capture will not enable to burn that one
2018-08-28 21:42:14
Rotonen
ux and security are an unhappy marriage and marketing is the old salt, or somesuch
2018-08-28 21:49:09
Fireduck
@bitbumper get
2018-08-28 21:49:29
Fireduck
get_unspent on a wallet with 10,000 address is taking about 15 seconds on a virt with a really questionable cpu
2018-08-28 22:13:19
bitbumper
Cool, good to have a ballpark number. Is that scaling on number of accounts or UTXOs?
2018-08-28 22:32:21
Fireduck
Accounts
2018-08-28 22:32:38
Fireduck
One account with 24,000 utxos is a second