archive snowblossom slack dev
prev 2018-06-12 next
2018-06-12 01:41:34
Clueless
I went down the rabbit hole last night
2018-06-12 05:47:45
GitHub
[snowblossomcoin/snowblossom] #70 fix newlines
2018-06-12 05:47:54
GitHub
[snowblossomcoin/snowblossom] #70 fix newlines
2018-06-12 05:49:04
Tyler Boone
@Fireduck, for the DB table of address-keyed data, do you plan on storing that for partial nodes as well?
2018-06-12 05:50:02
Tyler Boone
And if so, I assume the plan would be to prune as blocks move out of the node's window
2018-06-12 05:51:36
Tyler Boone
I was thinking having a design where you store the height and hash of all the blocks of data you have in the table. in another table.
2018-06-12 05:52:23
Tyler Boone
that way you can know how much to prune, and you can tell if the current longest chain is the same as the chain for which you have the data stored
2018-06-12 05:55:40
Fireduck
ok, so the address data would only be for a certain class of full nodes that is interested in being good to light clients and being able to give them full history
2018-06-12 05:55:50
Fireduck
I don't see that intersecting with a pruned node at all
2018-06-12 05:56:31
Fireduck
and yeah, almost always wise to keep block headers even if discarding the transactions
2018-06-12 05:56:59
Fireduck
however, as excited as Zac is about the idea of checkpointing or pruned nodes, that is really not of much use to anyone right now
2018-06-12 05:57:08
Fireduck
the entire chain is pretty small
2018-06-12 06:20:56
Clueless
@Fireduck It will only be of use in the future.
2018-06-12 06:21:01
Clueless
(mobile) Client tools will absolutely rely on it.
2018-06-12 06:52:23
Tyler Boone
A client could get address balances (from utxo trie) without having the address data table.
2018-06-12 06:53:30
Tyler Boone
If a client wants to display transaction history, that is different. And it would be easy to generate a "recent transaction" list by just scanning the known blocks (which should be a small set)
2018-06-12 06:56:13
Clueless
hm, the other method a user might differentiate payments is by using multiple addresses
2018-06-12 06:57:14
Clueless
Basically, I don't want laymen to have to run a node at home to connect to for privacy.
2018-06-12 06:57:33
Clueless
I'm under the impression trie would inform the node of your address? giving up privacy
2018-06-12 11:55:24
ez8
@ez8 has joined the channel
2018-06-12 12:28:57
Tyler Boone
if someone wants privacy they can run a full node. Basically nobody actually cares about privacy (see: Facebook). For the rare person who does care, he can run a full node.
2018-06-12 19:53:41
GitHub
When pool miner submits a share add a counter to how many shares have been accepted or rejected. 1253/1253 or 1222/1253. This way we can get a running time on how many shares have been accepted over time. It's a bit difficult to see stats
2018-06-12 21:30:06
GitHub
Currently when the .bat files are run the resulting CMD window has C:\Windows\System32\cmd.exe in the titlebar which is useless for indentification when you have multiple CMD windows open (I have three windows open pertaining to Snowblossom and two unrelated ones). This would be easy to address by putting something like: TITLE Snowblossom node and TITLE Snowblossom client at the very top of the existing node.bat and client.bat etc etc. I've edited my own .bat files so that the windows are easier to identify but it would be nicer for end users if the ones downloaded from Github were like this.
2018-06-12 22:17:04
Rotonen
@Fireduck mr plow seems very light on the cpu so far, well done
2018-06-12 22:29:52
Fireduck
Yeah, it does very little
2018-06-12 22:32:03
Rotonen
the base loop of too many software has a larger idle overhead than mr plow in actual use
2018-06-12 22:33:30
Fireduck
Ha, yeah
2018-06-12 22:34:22
Rotonen
interrupts are a forgotten art, but i suppose java helps with getting evented stuff like networking right on the base level
2018-06-12 22:45:55
GitHub
A lot of mining programs will tell the user what the hashrate is measured at an instant and also what the hashrate is when averaging values over the last 5, 10 or 15 minutes. These averaged values don't vary as much as the immediate measurements and make it easier to optimise configurations.
2018-06-12 23:41:58
Clueless
Snowday's hashrates seem to fluctuate wildly
2018-06-12 23:42:18
Clueless
209652.304/sec 419325.569
2018-06-12 23:42:31
Fireduck
It is a 20 second average, aka complete nonsense
2018-06-12 23:42:54
Clueless
Ah. I even tried to average the last 10 values for the website to display, smooth it out
2018-06-12 23:42:59
Clueless
it's fine though
2018-06-12 23:45:00
Rotonen
the logging could be a lot less verbose
2018-06-12 23:45:06
Fireduck
Yeah
2018-06-12 23:45:29
Fireduck
I just started a new job so not hacking on snowblossom all day
2018-06-12 23:45:51
Clueless
@Rotonen I'll see if I can fix that
2018-06-12 23:46:07
Clueless
java isn't my language so I've been letting that issue hang
2018-06-12 23:46:53
Rotonen
i log via systemd journald anyway so the timestamp is redundant (and it's anyway a multi-line log format or so?)
2018-06-12 23:47:10
Clueless
@Rotonen exactly
2018-06-12 23:47:24
Clueless
Java by default prints context, then it prints the log message
2018-06-12 23:48:19
Rotonen
i'd not invest much effort into log formatting at this point
2018-06-12 23:49:02
Rotonen
voting, whoopsie catching via voting, variable diff