< aj>
MarcoFalke: wow, pgp signed github acks? intense
< tyrick>
Is this where I come to bug people about core code?
< mlz>
tyrick, you can ask in #bitcoin channel
< LumberCartel>
tyrick: This is where core developers are collaborating. I suggest not trying to "bug" anyone here. You might try asking about your issue in the #bitcoin channel first.
< ossifrage>
I tried to rbf a transaction with 2 outputs, one in my wallet and one external, but it didn't mark the one from my wallet as a change address. Is this a bug?
< ossifrage>
[I didn't use the change address field, just manually added it as an output]
< BGL>
why can't bitcoin core start where it left off on re-indexing blocks, i seriously just had to restart twice in the last day and i'm back to zero again
< BGL>
probly not even going to finish by tomorrow
< BGL>
not even sure why i bothered manually transferring the block files
< gmaxwell>
BGL: it does continue where it left off, though if you've set your dbcache large then most of its work won't have been written to disk yet.
< BGL>
it's default
< BGL>
450mb, and now i'm 7 years behind again
< BGL>
for the 3rd time
< BGL>
this is on a brand new ssd so .. i don't get that either
< luke-jr>
BGL: why did you have to restart? ie, how did your computer stop doing it?
< luke-jr>
might be best to take this to #bitcoin ..
< BGL>
windows update
< BGL>
this last time
< BGL>
and the first time was because i forgot the program closes instead of minimizing to the tray by default
< BGL>
i've blown a whole day, literally now
< luke-jr>
hmm, I would expect a clean shutdown to work properly at least regardless of dbcache state
< BGL>
i don't know if i'd consider windows update a clean shutdown
< BGL>
according to it anyways
< meshcollider>
I guess the first should have been a clean shutdown though, if you just hit close?
< BGL>
well i guess that's a good point i'm not sure
< BGL>
i copied the blockchain, chainstate and some otehr stuff from another machine
< BGL>
i'd hoped this wouldn't be so involved by doing that
< BGL>
but maybe i incorrectly copied some file into this new machine that's causing a problem?
< luke-jr>
when you start it, does it mention corruption or anything?
< BGL>
no
< BGL>
if i manage to get fully through and it decides to start all over then i'll just clean install and download the chain again directly
< BGL>
but i sure wish this wasn't ungodly slow and gave some explanation or something
< luke-jr>
it's just going to get slower and slower until the block size is reduced :<
< BGL>
i was wondering if that blocks dir can be compressed for transfer? or does it not compress well at all
< BGL>
by the time i thought of it i was halfway through anyways
< luke-jr>
BGL: it probably can be compressed, but not exceptionally well with standard tools
< luke-jr>
in terms of syncing, compression may be more harm than good since ideal compression could break parallelism
< gmaxwell>
[OT] TD-Linux was able to disable ME on my new T470p using me_cleaner, it was zero difficulty (releatively speaking: requires clamping a flash programmer into the board)
< luke-jr>
gmaxwell: any effect on battery life?
< gmaxwell>
luke-jr: dunno yet, not expecting so, but will test tomorrow.
< matt42>
quit
< sher48>
what about big hashrate fluctuations? -28.68% _in 24 hours) is not good
< sher48>
it's time to switch miners mostly to commission income...
< ossifrage>
Should dumprivkey work for a segwit address? validateaddress lists the address, but dumpprivkey returns 'Address does not refer to a key (code -3)'
< sher48>
quit
< sher48>
exit
< sipa>
ossifrage: not yet
< ossifrage>
sipa, thanks... eventually I was able to backtrack to the original address I used for the 'addwitnessaddress' and the privkey for that address...
< luke-jr>
ossifrage: note that ordinarily people should not use dumpprivkey at all - it's for wallet debugging, nothing more
< ossifrage>
luke-jr, yeah I just did that as a sanity check when the dumprivkey key was confusing me
< ossifrage>
When I saw that none of the segwit addresses where in the dump I realized it wasn't specific to the key I was looking for
< bitcoin-git>
[bitcoin] mikedennis closed pull request #11670: [Docs] Update with instructions for WSL for Win 10 fall 2017 creator update (master...master) https://github.com/bitcoin/bitcoin/pull/11670
< blockchain>
@luke-jr why not ? I used dumprivkey to dump all my privat keys and save them seperatly
< luke-jr>
blockchain: 1) you'll miss metadata for sure, 2) novices will miss change, 3) newer wallets are HD, which don't have individual per-address private keys
< blockchain>
so what do you recommend. I don´t want all my bitcoins in one wallet
< blockchain>
individual per-address privat keys? I have about 100 privat keys with my bitcoins in it spreaded
< sipa>
blockchain: bitcoin core now supports multiple wallets
< sipa>
since 0.15
< blockchain>
i like the idea being able to redeem by privat keys on other wallets as well. So i can use my privat keys to redeem on blockchain.info for example. Its precarious ?
< sipa>
you can, but you're on your own
< sipa>
it's not what bitcoin core was designed for
< blockchain>
So actually I have saved one wallet.dat with all my bitcoins stored some years ago. Then when I want to use some bitcoin I just load one privat key into my new wallet.dat. I am somehow concerned loading my whole wallet with all my bitcoins stored evertime I want to move some bitcoins
< blockchain>
Although my computer is crypted, someone might catch up while I am outside or some police raid or forced robbery.
< eck>
I was told that there's a proposal from someone (I forget who!) to do multi-process bitcoin core, where some of the processes could be sandboxed (similar to firefox/chrome); does anyone know where I could learn more about this?
< BGL>
i think this core client really is downloading all the dat again despite it saying its reindexing blocks on disks
< sipa>
why do you think so?
< BGL>
it's been like 15 hours and it's at 8%
< oerauakk>
"But in reality that's bullshit, full nodes are useless in the Bitcoin beyond providing connection points, what matter is the ring of inter connected mining nodes that guarantee your new transactions to reach 99% of hash power within 3 seconds."
< oerauakk>
How much truth is there to this statement?
< sipa>
oerauakk: full nodes are there to keep miners in check
< sipa>
if all miners are honest, full nodes are useless
< sipa>
but in that case, why do we have mining in the first place?
< sipa>
the whole point is to design a system where we don't rely on assuming miners - or anyone - is honest
< oerauakk>
sipa: but is there a limit to how many extra full nodes still benefit the network? Less nodes means more centralisation, but does more nodes mean a healthier network, or is there some threshold where there is not really any point in adding more nodes?
< oerauakk>
Can more nodes actually hinder the network?
< sipa>
oerauakk: *using* a full node matters
< sipa>
as in: basing your economic activity on one
< sipa>
not accepting transactions unless *your own* full node accepts ot
< sipa>
that is how you reduce trust
< oerauakk>
I see
< oerauakk>
Thanks, I understand it a little better now
< sipa>
you shouldn't care about others full nodes, except as an indication for how hard it is
< oerauakk>
But is there any merit to the argument that adding more nodes doesn't necessarily mean a healthier network?
< oerauakk>
how hard?
< sipa>
adding random nodes that nobody looks at doesn't matter at all
< sipa>
the network doesn't have a need for more nodes
< sipa>
but the ecosystem needs much more players that *use* their own nodes
< sipa>
also, this discussion probably belongs on #bitcoin
< oerauakk>
Sorry, I wasn't sure where to go
< oerauakk>
But thanks for your answers
< luke-jr>
BGL: quite often, the bottleneck is your CPU/disk, not bandwidth
< luke-jr>
BGL: it's not just loading data; it's verifying and processing it into a database
< BGL>
it's on a brand new ssd and not putting more than a ~25% load on the cpu
< BGL>
i've benchmarked both and they are acting as expected
< sipa>
BGL: increase your dbcache
< BGL>
for some reason i thought i'd save time by copying the blocks folder to this machine
< sipa>
also, validation early on in the chain is limited to 1 core
< BGL>
increasing that on the fly while re-indexing will make a diff?
< luke-jr>
BGL: you need to restart the node to change it (although it *should* resume where it left off)
< BGL>
it didn't restart where it left off when i accidentally closed the window the first time, or when windows update re-booted the machine unexpextedly
< luke-jr>
I remember, hence the "should"
< oerauakk>
sipa: can I just ask though, if adding more nodes does not necessarily benefit the network, then why is it important to have more players use their own node?
< sturles>
Can I make bitcoin use segwit addresses for change now, on master, or is that still a subject for discussion on how to do it properly?
< BGL>
sipa when does validation start using more than 1 core?
< luke-jr>
oerauakk: I answered that already in #Bitcoin fyi
< BGL>
you can't change the dbcache without a client restart
< luke-jr>
sturles: pretty sure you can't right now at least
< sturles>
Will it do it automatically, or optionally as an agrument to sendmany etc?
< oerauakk>
luke-jr: I seem to have missed it (disconnected)