1 2017-12-27 01:08:36 0|pkaksha|hello everyone .
2 2017-12-27 01:09:27 0|pkaksha|i want to learn about blockchain and developement . can anyone suggest good resources to start from zero
3 2017-12-27 01:10:28 0|rabidus|wrong channel to start from zero
4 2017-12-27 01:10:53 0|pkaksha|where should i go ?
5 2017-12-27 01:12:07 0|mryandao|#bitcoin
6 2017-12-27 01:12:39 0|pkaksha|ok. thanks
7 2017-12-27 01:12:52 0|pkaksha|exit
8 2017-12-27 01:15:49 0|meshcollider|ryanofsky: Thank you so much for pointing that issue with using static! I've been trying to work out what was wrong for hours lol
9 2017-12-27 03:55:12 0|xiedeacc|test
10 2017-12-27 03:55:38 0|xiedeacc|does anybody here
11 2017-12-27 03:56:06 0|xiedeacc|give me a reply, let me know I can use this IRC, thk~
12 2017-12-27 04:12:00 0|echeveria|xiedeacc: #bitcoin please.
13 2017-12-27 04:34:22 0|xiedeacc|what's nChainWork for in class CBlockIndex
14 2017-12-27 04:53:19 0|meshcollider|xiedeacc: as the name suggests, its the total amount of work in the chain :)
15 2017-12-27 04:53:54 0|meshcollider|(Up to and including that block)
16 2017-12-27 04:56:35 0|meshcollider|xiedeacc: If you are working on an altcoin, please move to ##altcoin-dev btw, not this channel
17 2017-12-27 05:12:50 0|xiedeacc|I'm confused with work
18 2017-12-27 05:13:29 0|xiedeacc|I'm newer to IRC
19 2017-12-27 05:13:48 0|xiedeacc|what's meanning of work?
20 2017-12-27 05:14:09 0|meshcollider|xiedeacc: work is roughly how many hashes we expect needed to be done to mine that chain
21 2017-12-27 05:14:54 0|meshcollider|xiedeacc: You should ask questions in #bitcoin channel not here though
22 2017-12-27 05:15:02 0|xiedeacc|ok, gotta
23 2017-12-27 05:15:06 0|xiedeacc|thank you
24 2017-12-27 06:59:40 0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #12032: [backport] #11847 Make boost::multi_index comparators const (060.15...06boost-fix-multi-index) 02https://github.com/bitcoin/bitcoin/pull/12032
25 2017-12-27 07:13:40 0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11993: [Docs] Fixed createrawtransaction help text. (06master...06fix-createrawtransaction-help) 02https://github.com/bitcoin/bitcoin/pull/11993
26 2017-12-27 09:49:43 0|meshcollider|would it make more sense to have the rpc cookie file stored in the "files" argument section or the "rpc" argument section
27 2017-12-27 11:26:14 0|karanlearns|hi , i cloned from github and installed on my online computer. i also added few commits to create segwit address
28 2017-12-27 11:26:39 0|karanlearns|i then copied the bitcoin-qt file from bin folder to my other offline computer.
29 2017-12-27 11:27:22 0|karanlearns|i get this error when i try to run latest source bitcoin-qt from offline computer
30 2017-12-27 11:27:24 0|karanlearns|error while loading shared libraries: libboost_system.so.1.63.0: cannot open shared object file: No such file or directory
31 2017-12-27 11:31:17 0|rafalcpp|karanlearns: move this question to #bitcoin imo. How ever the problem seems to be that you do not have lib boost system installed (system wide) on the target offline computer
32 2017-12-27 11:32:08 0|karanlearns|rafalcpp: this was working fine when i copied the 0.15.1 release bin file to offline computer
33 2017-12-27 11:34:57 0|karanlearns|earlier - i had copied bitcoin-qt from bin/ of the release 0.15.1 on my offline computer and it worked fine.
34 2017-12-27 11:35:45 0|karanlearns|now when i cloned from github,added one commit , make, install and then copied bitcoin-qt file from bin on offline computer - i got error
35 2017-12-27 11:36:17 0|karanlearns|"error while loading shared libraries: libboost_system.so.1.63.0: cannot open shared object file: No such file or directory"
36 2017-12-27 11:36:42 0|rafalcpp|karanlearns: you mean the officially released binaries worked?
37 2017-12-27 11:37:08 0|karanlearns|rafalcpp: yes
38 2017-12-27 11:37:40 0|karanlearns|then i needed one commit not present in released binary. so i cloned, added the commit, make, install
39 2017-12-27 11:38:40 0|karanlearns|and then copied the bitcoin-qt file from src folder first, then tried with bitcoin-qt under bin folder
40 2017-12-27 11:39:04 0|karanlearns|copied to offline computer and bitcoin-qt gives error
41 2017-12-27 11:39:34 0|karanlearns|i created a question here as well - https://bitcoin.stackexchange.com/questions/66695/error-while-loading-shared-libraries-libboost-system-so-1-63-0-cannot-open-sha
42 2017-12-27 11:41:49 0|rafalcpp|karanlearns: official binaries are from Gitian. It could be building it differently then normal Make, e.g. static linking some libraries like boost system. While your normal ./configure + make does not
43 2017-12-27 11:42:00 0|arubi|use this https://github.com/bitcoin/bitcoin/blob/master/depends/README.md
44 2017-12-27 11:45:46 0|karanlearns|arubi: for tails 64 bit - what should i do , i cannot easily figure from the docs.
45 2017-12-27 11:45:57 0|karanlearns|shall i do this make HOST = aarch64-linux-gnu
46 2017-12-27 11:46:07 0|arubi|no that's for arm 64
47 2017-12-27 11:47:03 0|arubi|karanlearns, run `gcc -v` I guess and look at the "Target: " , for me it's "Target: x86_64-linux-gnu"
48 2017-12-27 11:47:13 0|karanlearns|i need the one for 64 bit linux present here - https://bitcoin.org/en/download
49 2017-12-27 11:47:41 0|karanlearns|ok
50 2017-12-27 11:47:41 0|rafalcpp|karanlearns: target computer is 64 bit PC right?
51 2017-12-27 11:47:44 0|karanlearns|yes
52 2017-12-27 11:47:56 0|karanlearns|tails os = linux 64 bit
53 2017-12-27 11:48:24 0|rafalcpp|karanlearns: and you build on what, also 64 bi PC, 64 bit linux?
54 2017-12-27 11:48:29 0|karanlearns|so i just need to do make host = <target>
55 2017-12-27 11:48:29 0|rafalcpp|karanlearns: and you build on what, also 64 bit PC, 64 bit linux?
56 2017-12-27 11:48:33 0|karanlearns|instead of make
57 2017-12-27 11:48:38 0|karanlearns|yes
58 2017-12-27 11:48:44 0|karanlearns|rafalcpp: yes
59 2017-12-27 11:48:53 0|arubi|it's more than that
60 2017-12-27 11:49:07 0|arubi|you have to build the stuff in depends too
61 2017-12-27 11:49:18 0|rafalcpp|if you build and run on same architecture (64 bit intel/amd, 64 bit linux os) then the host=... option is not needed, skip it. Continue to the paragraph below about installing dependencies
62 2017-12-27 11:54:30 0|rafalcpp|arubi: I'm not sure if that README alone address his issue. Doesn't he need to either 1) install lib boost on target OS, or 2) use options to make the build be a [partially] static one?
63 2017-12-27 11:55:06 0|karanlearns|everything works great on my online computer already from cloned,modified source
64 2017-12-27 11:55:37 0|rafalcpp|karanlearns: easiest would be imo to install libboost package (not -dev, just the regular one) on the target offline machine
65 2017-12-27 11:55:38 0|arubi|iirc, it's cd into the depends dir, run make (with host set or not), go back to the root dir, run configure with the prefix flag set to the depends build dir, run make
66 2017-12-27 11:55:42 0|karanlearns|now i need to build this for my target system so that target system doesnt look for libboost_system.so
67 2017-12-27 11:56:50 0|arubi|it's not that the target is wrong, the binary you built is link dynamically
68 2017-12-27 11:57:07 0|arubi|you'll want to use the depends system to build statically with the proper versions of the libs
69 2017-12-27 11:57:38 0|arubi|s/link/linked/
70 2017-12-27 11:58:29 0|rafalcpp|karanlearns: yeap try that method with cd and make in deps first as above; let me know if it worked :)
71 2017-12-27 12:02:24 0|karanlearns|arubi: thanks - i am trying this out.
72 2017-12-27 12:03:28 0|karanlearns|rafalcp: thanks, i shall report back.
73 2017-12-27 12:03:44 0|karanlearns|rafalcpp: thanks, i shall report back.
74 2017-12-27 12:22:30 0|sipa|karanlearns: you can do a depends build if you want release-like binaries without the overhead of gitian's determistic build system
75 2017-12-27 12:22:55 0|arubi|already linked ^
76 2017-12-27 12:23:10 0|sipa|ok, cool, i didn't read backlog
77 2017-12-27 14:08:02 0|rafalcpp|why Bitcoin chooses to link libc dynamically? any pros/cons?
78 2017-12-27 14:10:49 0|contrapumpkin|on macOS, it's effectively required to link it dynamically, to be well behaved. Not that everyone respects that...
79 2017-12-27 14:11:04 0|contrapumpkin|are you concerned about something in particular?
80 2017-12-27 14:14:33 0|rafalcpp|contrapumpkin: I'm generally learning how Bitcoin chooses to use static vs dynamic linking and why so
81 2017-12-27 14:14:48 0|contrapumpkin|do you understand the pros and cons in other contexts?
82 2017-12-27 14:16:39 0|contrapumpkin|I don't think it's all that different for bitcoin, unless you're concerned about someone injecting malicious code by swapping out a dynamically linked dependency. But if they're futzing with executable code on your computer, you're probably screwed anyway (they could do LD_PRELOAD, poke around in memory, and various other shenanigans to mess with your running node)
83 2017-12-27 14:16:57 0|sipa|rafalcpp: release binaries have it statically, no?
84 2017-12-27 14:17:44 0|sipa|or, as BlueMatt tells me irl "because otherwise resolv.conf doesn't work properly"
85 2017-12-27 14:18:09 0|contrapumpkin|because some glibcs interpret nsswitch.conf differently?
86 2017-12-27 14:54:42 0|rafalcpp|sipa: no, released (Gitian) binary dynamically links libc, also librt, libgcc, libpthread, (and ld), and libm in bitcoind but not in -cli. (ldd bitcoin-cli shows)
87 2017-12-27 14:55:20 0|contrapumpkin|those are all pretty basic runtime libs
88 2017-12-27 14:56:49 0|rafalcpp|indeed. Though some could be moved to static too, so I wondered about this reasoning
89 2017-12-27 14:57:15 0|contrapumpkin|I take it you're only asking about the linux situation?
90 2017-12-27 14:59:13 0|rafalcpp|contrapumpkin: nope, for all platforms too
91 2017-12-27 15:00:16 0|contrapumpkin|on macOS, those libraries are all lumped into one called libSystem (minus libgcc/librt which are replaced with their LLVM counterparts), and you're expected to dynamically link against it, because Apple doesn't commit to a syscall ABI from the kernel
92 2017-12-27 15:00:52 0|contrapumpkin|the big exception here is Go, who ignored the advice and wrote their own syscall wrappers, so go binaries compiled before 1.7 will break on recent macOS
93 2017-12-27 15:33:27 0|tyrick|where is the new segwit UI code? I checkout out sipa201709_segwitwallet2
94 2017-12-27 15:33:58 0|tyrick|But not seeing new UI there
95 2017-12-27 15:40:27 0|sipa|tyrick: it'll give you segwit addresses by default everywhere
96 2017-12-27 15:41:18 0|contrapumpkin|oh, is it using bech32 now?
97 2017-12-27 15:41:21 0|sipa|you can control the type of addresses with the -addresstype command line / config option
98 2017-12-27 15:41:38 0|sipa|contrapumpkin: p2sh-p2wpkh by default
99 2017-12-27 15:41:45 0|sipa|bech32 if you ask for it
100 2017-12-27 15:43:02 0|contrapumpkin|nice
101 2017-12-27 15:43:08 0|tyrick|nice job!
102 2017-12-27 15:43:15 0|contrapumpkin|this is to shut up all the people asking for segwit by default?
103 2017-12-27 15:43:20 0|contrapumpkin|erm, I mean, to improve adoption
104 2017-12-27 15:44:06 0|sipa|contrapumpkin: the interesting thing is that about 90% of the complication in that PR is dealing with backward compatibility
105 2017-12-27 15:44:21 0|sipa|(downgrading software, restoring backups, ...)
106 2017-12-27 15:44:36 0|sipa|otherwise having segwit in the wallet would likely have happened much faster
107 2017-12-27 15:44:52 0|contrapumpkin|yeah, makes sense
108 2017-12-27 15:45:23 0|tyrick|Is this being released as 0.16?
109 2017-12-27 15:45:31 0|sipa|tyrick: likely
110 2017-12-27 15:45:50 0|sipa|(it's not even merged yet into master, much less included in a releasr)
111 2017-12-27 15:47:45 0|contrapumpkin|the schnorr stuff only helps space efficiency with multiple inputs to a txn, not outputs, right?
112 2017-12-27 15:53:38 0|sipa|contrapumpkin: indeed
113 2017-12-27 16:09:42 0|bitcoin-git|[13bitcoin] 15jb55 opened pull request #12035: [qt] change õBTC to bits (06master...06qt-bits) 02https://github.com/bitcoin/bitcoin/pull/12035
114 2017-12-27 16:13:33 0|jb55|is anyone working on schnorr stuff?
115 2017-12-27 16:16:22 0|contrapumpkin|jb55: from a similar question I asked yesterday,
116 2017-12-27 16:16:24 0|contrapumpkin|[13:31:53] <andytoshi> to the extent that they're talking about anything specific, i believe they're talking about the aggregate signature proposal that gmaxwell sipa and myself are working on
117 2017-12-27 16:16:46 0|jb55|nice
118 2017-12-27 16:40:23 0|rafalcpp|so cool, so there could be then services to recover dust of various people, and pay then out of bound, e.g. by fiat, or charging their LN?
119 2017-12-27 16:40:31 0|helpplx|hi, i tried to send a tx from bitcoin core with too low fee it seems, it shows as 0/not broadcasted yet. trying to use pushtx services shows the fee is too low. it deducted the balance from the bitcoin-core wallet.. what should i do? restart the wallet? if so will the funds return there? thatnks, sorry
120 2017-12-27 16:40:34 0|helpplx|its 25 btc
121 2017-12-27 16:40:35 0|helpplx|:(
122 2017-12-27 16:41:38 0|helpplx|" Error sending transaction: insufficient priority and fee for relay. " blockcypher push tx shows, and blockchain pushtx shows Validation Error: Insufficient fee. Please try again with a higher fee... bitcoin console showsTX decode failed (code -22) when broadcasting with sendrawtx
123 2017-12-27 16:44:32 0|alf1|hi!
124 2017-12-27 16:45:04 0|alf1|anyone dev here?
125 2017-12-27 16:45:22 0|alf1|or support guy?
126 2017-12-27 16:45:52 0|contrapumpkin|alf1: ask your question and if someone can answer, they will (or will tell you where to ask instead)
127 2017-12-27 16:46:05 0|contrapumpkin|this is not a support channel though
128 2017-12-27 16:48:17 0|helpplx|im sorry too for asking a support question but its a 25 btc transaction. sendrawtransaction fails, i dont understand if the btc are still in my wallet if i restart the bitcoin core wallet..only this..thanks guys
129 2017-12-27 16:56:28 0|helpplx|..+
130 2017-12-27 16:57:09 0|jb55|helpplx alf1: try asking on bitcoin.stackexchange.com
131 2017-12-27 16:59:35 0|helpplx|thanks but its really a "yes" or "no" question, the devs here know this..i used bitcoin-core wallet, set the fee to low (24 hours) and this mess happend. balance is deducted but tx not broadcated. do i need to restart btc core to get those 25 btc (390k $) back into the sender wallet? thanks for the work.
132 2017-12-27 17:01:11 0|provoostenator|contrapumpkin: I made PR #11991 to add a bech32 checkbox in the GUI, which is on top of sipa's changes.
133 2017-12-27 17:01:12 0|gribble|https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors ÷ Pull Request #11991 ÷ bitcoin/bitcoin ÷ GitHub
134 2017-12-27 17:02:25 0|alf1|okay, i try: i have transfer btcs from bitpanda.com to my bitcoin core wallet (0.15.1). (transaction ID 41354056bfe77f201d1aa098b2a2b34505aa9d4812935c44cf66a417abcde3ed). but i cant working with btc, because its still pending. i still waiting for "availible". i try -rescan, but it isnt working. can anybody help?
135 2017-12-27 17:04:32 0|helpplx|is this hard to get a yes or no from the official irc channel of the software i just used to send 390k$ and got issues? sorry but holy shit im stressed out
136 2017-12-27 17:06:49 0|rabidus|calm down. official channel is #bitcoin
137 2017-12-27 17:12:19 0|contrapumpkin|helpplx: short answer is that the core client never gets rid of your private keys unless you delete them yourself, so if the txn really wasn't broadcast, the money is still yours. If it was broadcast and the client is just being weird and not showing you that, then the money is going where you wanted it to. I don't see many chances for bad outcomes
138 2017-12-27 17:13:57 0|rafalcpp|helpplx: this channel is only about C++/etc developers who code bitcoin core client. Ask in #bitcoin. And as others say, you can NOT lose your money by sending it with too low fee.
139 2017-12-27 17:15:23 0|helpplx|thanks, tx shows as "Status: 0/offline, has not been successfully broadcast yet" on my wallet (sender).. so i can safely restart it? and funds will be returned..
140 2017-12-27 17:18:07 0|helpplx|after restarting it shows the same..balance deducted..shit..
141 2017-12-27 17:32:11 0|provoostenator|I might be witnessing #10646 live. Trying to gather some useful info. What aspect of catching up on the latest blocks uses gigabytes of disk I/O but <5% CPU and 350 MB memory, while hardly decreasing the number of blocks left for > 10 minutes?
142 2017-12-27 17:32:12 0|gribble|https://github.com/bitcoin/bitcoin/issues/10646 | Windows Gui becomes non responsive after "Done loading" ÷ Issue #10646 ÷ bitcoin/bitcoin ÷ GitHub
143 2017-12-27 17:32:21 0|provoostenator|(on OSX though)
144 2017-12-27 17:32:50 0|sipa|provoostenator: low dbcache?
145 2017-12-27 17:32:54 0|provoostenator|5 GB
146 2017-12-27 17:33:03 0|sipa|pruning on?
147 2017-12-27 17:33:42 0|provoostenator|Not pruned. I'm running a bitcoind instance in the background, but not on the same network. Also running btcd in the background. So there's probably a lot of disk I/O getting in the way from these competing things.
148 2017-12-27 17:33:59 0|provoostenator|But the machine is very responsive otherwise.
149 2017-12-27 17:34:49 0|provoostenator|Mmm, it also only has 2 peers, that's odd
150 2017-12-27 17:36:42 0|provoostenator|It only received data from one of those peers, and just 5 MB
151 2017-12-27 17:38:02 0|provoostenator|getmemoryinfo -> {"locked": {"used": 32704, "free": 491584, "total": 524288, "locked": 524288,"chunks_used": 1022, "chunks_free": 899}}
152 2017-12-27 17:38:36 0|helpplx|im importing a full datadir from another client (same linux, diff laptop), and keeping only the original wallet.dat. will this return my 25 btc to the wallet? thanks
153 2017-12-27 17:39:07 0|sipa|helpplx: this channel is not for support, take this elsewhere
154 2017-12-27 17:41:15 0|provoostenator|getblockchaininfo takes 64 seconds to respond, but UI remains responsive.
155 2017-12-27 17:41:21 0|helpplx|its a issue of the wallet, it didint warn me. i selected "low fee, 24 hours", it created a transaction that the network doesnt accept. is not my fault, at least add a warning. where to ask? #bitcoin is sandboxed nobody replies its a joke
156 2017-12-27 17:42:19 0|sipa|helpplx: try https://bitcoin.stackexchange.com
157 2017-12-27 17:42:22 0|provoostenator|Oh and as I said in the Github ticket, this is the SegWit wallet branch, though slightly outdated. I'll make sure to update it so I can get more useful info if it happens again.
158 2017-12-27 17:43:34 0|sipa|provoostenator: is the I/O due to bitcoin core, or from other processes?
159 2017-12-27 17:43:45 0|provoostenator|BitcoinQT
160 2017-12-27 17:44:57 0|provoostenator|Bitcoin Core wrote 3.2 GB so far and read 4 GB, not sure how much bitcoind and btcd read/wrote in the same time period.
161 2017-12-27 17:44:58 0|sipa|is it writing the whole time, or only reading, or writing in batches?
162 2017-12-27 17:45:14 0|sipa|bitcoind == Bitcoin Core?
163 2017-12-27 17:45:55 0|provoostenator|No, I meant "Bitcoin Core" when I said "BitcoinQT" (the name of the GUI process)
164 2017-12-27 17:46:25 0|provoostenator|It seems to be reading and writing at the same time, 158 reads/sec, 61 writes/sec. Not sure how aggregated that is.
165 2017-12-27 17:46:52 0|provoostenator|I can run top with your favorite arguments...
166 2017-12-27 17:46:57 0|sipa|the expected behaviour is that it's reading pretty much the whole time, and only writing when flushing
167 2017-12-27 17:47:21 0|sipa|you can see the flushing by seeing the size of the dbcache (in the uodatetip log line) go down
168 2017-12-27 17:49:50 0|provoostenator|And I assume you'd see memory use drop during a flush? I don't see that. It's climing slowly, maybe a couple of MB per minute, at about 400 MB now. Total system memory usage is only 9 GB out of 16.
169 2017-12-27 17:50:27 0|helpplx|it still shows the deducted balance wtf
170 2017-12-27 17:50:32 0|sipa|it should go up until it hits the limit, and then drop back to zero
171 2017-12-27 17:50:44 0|helpplx|what can i do seriously? this is bad
172 2017-12-27 17:51:25 0|sipa|helpplx: i'm sure this is a serious problem for you, but this is not the place to ask. people here are at work and have their own priorities. on stackexchange or other fora there are far more people who can help you
173 2017-12-27 17:52:53 0|provoostenator|Right, that's not happening; and it really shouldn't hit the limit of 5 GB anytime soon Do you mean debug.log or another file? I don't see any "tip" entries for this session.
174 2017-12-27 17:53:35 0|sipa|debug.log should always contain those entries
175 2017-12-27 17:53:54 0|sipa|UpdateTip
176 2017-12-27 17:54:17 0|provoostenator|Oh wait: UpdateTip: new best=0000000000000000008adf168e59c00d74f5a0077993e0c3848eefd82e4daa9c height=500856 version=0x20000000 log2_work=87.723434 tx=285685879 date='2017-12-24 16:07:09' progress=0.997127 cache=22.2MiB(169291txo)
177 2017-12-27 17:55:05 0|sipa|yes
178 2017-12-27 17:55:11 0|sipa|the cache= field
179 2017-12-27 17:55:55 0|helpplx|you understand thousands of people could suffer the same "bug" where the wallet creates invalid tx? if 25 btc its not important i dont know what is lol. i just asked what to do, like "that tx will return to you in X hours, chill" or "do this or that, fine" is ok.
180 2017-12-27 17:59:11 0|provoostenator|sipa: the cache just increased every block during this session: https://gist.github.com/Sjors/a9a383175a6c00e126e090df61dd39e8
181 2017-12-27 17:59:13 0|sipa|helpplx: if you suspect there is a bug, you can also file an issue on https://github.com/bitcoin/bitcoin/issues
182 2017-12-27 17:59:51 0|sipa|helpplx: i don't have time to look into all details of your situation, but i suspect it will just eventually either confirm, or cancellable using abandontransaction
183 2017-12-27 18:01:01 0|provoostenator|Note the block index 369541ms on line 44 , which I assume is there the UI was handing
184 2017-12-27 18:01:31 0|sipa|that's 6 minutes
185 2017-12-27 18:01:37 0|sipa|that may just be the flush
186 2017-12-27 18:04:34 0|provoostenator|Meanwhile disk I/O is now at 3.9 / 5.22 GB (from 3.2 / 4 GB 20 minutes ago)
187 2017-12-27 18:05:34 0|provoostenator|(normally I would just kill everthing in the background and things generally get better, but I'll leave those on now)
188 2017-12-27 18:06:32 0|helpplx|Transaction not eligible for abandonment (code -5)
189 2017-12-27 18:07:54 0|sipa|helpplx: that means the transaction is in the mempool and will confirm when a miner picks it up
190 2017-12-27 18:08:32 0|sipa|helpplx: in any case, either the transaction goes through or it does not; you don't lose money
191 2017-12-27 18:08:42 0|sipa|helpplx: now, please, go to the proper forums
192 2017-12-27 18:15:16 0|sipa|provoostenator: i'm confused, what is the unexpected behaviour you're observing?
193 2017-12-27 18:15:20 0|sipa|is it during a flush?
194 2017-12-27 18:15:46 0|sipa|you'd expect it do several GB of writes during a flush
195 2017-12-27 18:23:30 0|provoostenator|Ok, so you're saying it's been flushing for the past 30 minutes? Flushing what exactly? Is there any way to know for sure?
196 2017-12-27 18:23:59 0|sipa|are there new lines being produced in the log?
197 2017-12-27 18:24:13 0|sipa|flushing the utxo changes
198 2017-12-27 18:24:20 0|provoostenator|yes, every time it receives a block
199 2017-12-27 18:24:32 0|sipa|flushing is blocking
200 2017-12-27 18:24:33 0|sipa|so no
201 2017-12-27 18:24:44 0|sipa|you wouldn't see anything during a flush
202 2017-12-27 18:25:15 0|provoostenator|Right, so there's some other reason why it's slowly reading and writing gigabytes of data...
203 2017-12-27 18:26:02 0|sipa|there shouldn't really been any writes at all
204 2017-12-27 18:26:09 0|sipa|apart from writing the new block to disk
205 2017-12-27 18:26:24 0|sipa|oh, with txindex enabled you'd see much more writes
206 2017-12-27 18:26:30 0|sipa|if that turned on?
207 2017-12-27 18:26:35 0|provoostenator|Oh yes, I probably should have mentioned that.
208 2017-12-27 18:26:59 0|sipa|yes, that will kill performamce
209 2017-12-27 18:27:30 0|provoostenator|That's an understatement.
210 2017-12-27 18:28:00 0|sipa|i don't believe actual progress is that much slowed down by it
211 2017-12-27 18:28:15 0|sipa|but it's not optimized in any way, really
212 2017-12-27 18:29:34 0|provoostenator|txindex is useful if you want to run Lightning against your own full node. So presumably more people will run into this, if performance really is a problem. Although I should compare against a scenario of not having other processes with disk i/o in the background.
213 2017-12-27 18:29:56 0|provoostenator|Does it have to rewrite the index every time a tx comes in?
214 2017-12-27 18:31:40 0|sipa|provoostenator: what?
215 2017-12-27 18:31:47 0|sipa|does loghtning require txindex?!
216 2017-12-27 18:31:59 0|jb55|no
217 2017-12-27 18:32:04 0|sipa|that's pretty terrible
218 2017-12-27 18:32:06 0|provoostenator|eclair does: https://github.com/ACINQ/eclair
219 2017-12-27 18:32:11 0|jb55|clightning does not
220 2017-12-27 18:32:21 0|provoostenator|Obviously lightning doesn't intrisically.
221 2017-12-27 18:32:37 0|provoostenator|So does lnd I believe, although they currently don't support bitcoin core yet.
222 2017-12-27 18:33:29 0|provoostenator|btcd is taking two weeks to just do an IBD, because it doesn't have any of Core's recent performance enhancement stuff. But I've never tried that without txindex=1
223 2017-12-27 18:34:01 0|sipa|well it's ridiculous to assume end users can run with txindex imho
224 2017-12-27 18:34:39 0|provoostenator|I guess now I have an excuse to try https://github.com/ElementsProject/lightning (at least the README doesn't specify that such an index is needed)
225 2017-12-27 18:34:54 0|jb55|it's a bit buggy but it works sometimes
226 2017-12-27 18:35:08 0|sipa|it's for debugging or running a rudinentary explorer like thing
227 2017-12-27 18:35:32 0|provoostenator|sipa: is it inherently resource intensive?
228 2017-12-27 18:37:41 0|jb55|I want to write a standalone indexing daemon but I wonder how much internal state I would need...
229 2017-12-27 18:37:57 0|provoostenator|lnd will let you connect to somebody else's node fairly easily, but that uses the still experimental neutrino protocol.
230 2017-12-27 18:38:59 0|provoostenator|eclair needs RPC and ZMQ and sends and receive directly using the Core wallet, so hard to avoid the problem there.
231 2017-12-27 18:39:43 0|provoostenator|I don't know what they need the index for, I'd have to dig a bit more and maybe file some Github tickets there to make them rethink that.
232 2017-12-27 18:39:50 0|molz|lnd requires txindex in bitcoind too
233 2017-12-27 18:40:04 0|provoostenator|molz: yes, but in *somebody elses* bitcoind :-)
234 2017-12-27 18:40:34 0|sipa|provoostenator: just the idea that you'd need the entire history of the currency for any end user application is already ridiculous - it being fully indexed even more so
235 2017-12-27 18:45:58 0|provoostenator|I asked: https://github.com/lightningnetwork/lnd/issues/527
236 2017-12-27 18:48:39 0|provoostenator|I'll ask the Eclair folks as well once I know a bit more why lnd needs this. Anyway, I'll let it run for a few more hours here... will let you know if anything interesting happens.
237 2017-12-27 18:54:48 0|alpha_red|disconnect
238 2017-12-27 18:57:03 0|gmaxwell|if something needs txindex that means that it is incompatible with pruning, which means that it is at least eventally incompatible with decenteralized operation.
239 2017-12-27 19:00:37 0|provoostenator|gmaxwell: it could at least use a txindex that starts at the block height of the oldest open channel I assume.
240 2017-12-27 19:01:15 0|provoostenator|But as I said, I have no idea why they need it at all. Hopefully there's a better approach possible.
241 2017-12-27 19:02:31 0|provoostenator|My guess would be that they're not tracking any state and just tell the node "hey, have you seen this specific tx id yet?". And if so, tell the user the channel just got closed / they got cheated.
242 2017-12-27 19:08:36 0|cluelessperson|why use berkeleydb for wallet.dat ?
243 2017-12-27 19:10:59 0|luke-jr|cluelessperson: only because nobody has done the work of replacing it, basically
244 2017-12-27 19:12:09 0|zelest|lets migrate it to mysql! *trollface*
245 2017-12-27 19:13:35 0|cluelessperson|luke-jr: Ah. Well my intention isn't to disrespect. I just don't know why it would have been chosen. Perhaps there was some discussion about effeciency or large scaling for vendors, I dunno. I'm a HUGE fan of json, sqlite, postgres myself.
246 2017-12-27 19:13:35 0|cluelessperson|zelest: not for exchanges.
247 2017-12-27 19:13:35 0|zelest|any relation database sounds a bit overkill tbh
248 2017-12-27 19:13:35 0|zelest|true
249 2017-12-27 19:13:36 0|zelest|but for a single users' wallet.dat
250 2017-12-27 19:13:39 0|cluelessperson|zelest: I've had cases where people used tens of thousands of addresses.
251 2017-12-27 19:13:54 0|cluelessperson|has to scale
252 2017-12-27 19:14:34 0|cluelessperson|luke-jr: Can you help me understand the skills I need to help? I'm planning on taking classes, but that's going to take me months-year to even start working in c++
253 2017-12-27 19:14:48 0|eck|berkeleydb can handle tens of thousands of database entries too
254 2017-12-27 19:15:08 0|cluelessperson|eck: it's just impossible for laymen to use/troubleshoot in this state.
255 2017-12-27 19:15:14 0|zelest|i dunno, i might lack the understanding of the bitcoin protocol, but having a whole database because a few single corner cases has to scale feels a bit bloated tbh :o
256 2017-12-27 19:15:15 0|cluelessperson|outside of through bitcoin core itself
257 2017-12-27 19:15:33 0|cluelessperson|Hell, I'm doing this in python
258 2017-12-27 19:15:33 0|Randolf|For a Wallet application written in Java, I'd lean heavily to using the H2 database engine for a high-performance pure-Java SQL option (it has a built-in AES encryption option that encrypts the entire database file): http://www.h2database.com/
259 2017-12-27 19:15:34 0|cluelessperson|w = db.DB()
260 2017-12-27 19:15:34 0|cluelessperson|w.open("wallet.dat", "main", db.DB_BTREE, db.DB_RDONLY)
261 2017-12-27 19:16:06 0|cluelessperson|for i in w.items(): print(i) and it's 1000 lines of human unreadable info. :/
262 2017-12-27 19:17:18 0|zelest|this just reminds me of when people setup mail servers.. they demand a fully configured database server and yet they setup a single domain with 3 mail accounts.. that's it.. :P
263 2017-12-27 19:18:17 0|zelest|but yeah, mayhaps have the option to use different database backends, if needed.. might be a bit much to support though?
264 2017-12-27 19:20:48 0|Randolf|zelest: That's where you start getting into setting up a "driver" layer so that others can contribute support for their favourite databases in a modular fashion.
265 2017-12-27 19:35:06 0|luke-jr|cluelessperson: BDB isn't a relational database; Satoshi chose it, so nobody will have a certain answer why
266 2017-12-27 19:44:28 0|sipa|cluelessperson: the wallet loads all data in RAM anyway, the file format is pretty much irrelevant, it could be a text file
267 2017-12-27 20:13:10 0|cluelessperson|Thoughts on this structure? https://hastebin.com/raw/wenabegati
268 2017-12-27 20:27:05 0|sipa|cluelessperson: please read the gist i linked to in the segwit pr
269 2017-12-27 20:28:06 0|gmaxwell|cluelessperson: redesigning things you do not understand is a bad reflex.
270 2017-12-27 20:30:33 0|cluelessperson|gmaxwell: I feel that's incredibly insulting and unhelpful. It's a wallet file that stores keys, what do I not understand about it?
271 2017-12-27 20:30:37 0|cluelessperson|what's hard to understand about it?
272 2017-12-27 20:30:59 0|sipa|cluelessperson: that hardly the only thing it stores
273 2017-12-27 20:32:05 0|cluelessperson|sipa: what do you feel I'm missing? transaction cache, block height last seen?, hash of the wallet file so if it's modified, it knows to rescan the blockchain ?
274 2017-12-27 20:32:14 0|cluelessperson|or utxo
275 2017-12-27 20:33:13 0|sipa|all of those and more
276 2017-12-27 20:34:11 0|sipa|redeemscripts, public keys
277 2017-12-27 20:34:29 0|sipa|pre generated keys / keypool
278 2017-12-27 20:34:32 0|sipa|labels
279 2017-12-27 20:34:50 0|sipa|tinestamps, key birthdates
280 2017-12-27 20:36:07 0|phantomcircuit|not to mention most of the data is binary and storing it in json is a huge blowup
281 2017-12-27 20:37:01 0|sipa|cluelessperson: and no offense, but if you need to ask "what's so hard about it", you clearly haven't really done much effort to understand what it is doing now
282 2017-12-27 20:38:04 0|sipa|cluelessperson: that may be fine if you'd want to design something from scratch, but we're stuck with pretty demanding compatibility requirements (you can still load a 0.2.10 wallet.dat file and it will work)
283 2017-12-27 20:38:18 0|cluelessperson|sipa: I'm suggesting a framework to make life easier for users using bitcoin. Extracting and dealing with keys at this point is inevitable and currently painful. All those things you mentioned fit into this framework.
284 2017-12-27 20:38:39 0|sipa|cluelessperson: that still doesn't give a helpful upgrade scenario
285 2017-12-27 20:39:04 0|sipa|the difficulty is not in designing a storage scheme, but in how it fits into all current use cases
286 2017-12-27 20:39:10 0|cluelessperson|This is more of an example of how I want to make life easier for users, by no means would it be exactly this if I seriously suggest a change. :/
287 2017-12-27 20:39:30 0|sipa|well, please go read the gist i linked to in the segwit pr
288 2017-12-27 20:39:56 0|cluelessperson|sipa: sorry, I don't see a link from you
289 2017-12-27 20:40:03 0|sipa|it talks how things work now, and how they can move towards something that's more like what you're describing
290 2017-12-27 20:40:19 0|sipa|i'm on my phone in a train; it's linked in the segwit wallet pr
291 2017-12-27 20:40:26 0|cluelessperson|ah, I'll find it then
292 2017-12-27 20:41:12 0|sipa|also, no we're not seriously going to store wallets in JSON
293 2017-12-27 20:41:39 0|sipa|though something like what you're describing may be useful as a dump/import format
294 2017-12-27 20:44:04 0|gmaxwell|cluelessperson: sorry man, but when you batter your head against something, then don't understand it, and respond by offering a redesign, _THAT_ is insulting and disrespectful. It's sending a message that everyone else is such idiots that they couldn't manage to do it the simple way that you just tossed out. That is seldom the case, usually when someone doesn't understand something thats beca
295 2017-12-27 20:44:10 0|gmaxwell|use they haven't fully internalized the requirements, so they have no idea what its doing... and that is why attempting to redesign when you don't understand things is a bad reflex.
296 2017-12-27 20:45:47 0|cluelessperson|gmaxwell: You're right, I'm sorry. It's not really my intention to throw out your expertise. I just deal with users day in and day out that have difficulty accessing their keys, which I feel is inevitable.
297 2017-12-27 20:46:10 0|sipa|yes, there is no doubt that things can be improved a lot
298 2017-12-27 20:46:32 0|sipa|but changing things in this context is also very hard
299 2017-12-27 20:46:43 0|cluelessperson|agreed.
300 2017-12-27 20:47:21 0|gmaxwell|"difficulty accessing their keys"--
301 2017-12-27 20:47:27 0|gmaxwell|I have no freeking idea what that means.
302 2017-12-27 20:48:08 0|sipa|letting users access their keys was never a design goal
303 2017-12-27 20:48:23 0|sipa|letting them manage them at a high level however perhaps should be
304 2017-12-27 20:48:28 0|cluelessperson|gmaxwell: Currently, the only method that seems reliable for exporting private keys, is to get the bitcoin core binary, start it, and use the console to dumpwallet.
305 2017-12-27 20:48:46 0|gmaxwell|(1) there is a wallet dump which exports keys directly. (2) for HD wallet there probably should eventually be no private keys in the wallet except for master keys. (3) It is extraordinarly dangerous for users to work with keys directly, and has resulted losses of thousands of bitcoins, manually handling keys is not something we should encourage.
306 2017-12-27 20:49:15 0|cluelessperson|which often leads to misunderstanding like, "should I let it sync before I can export?" and things like that, there's a phenomenal amount of ignorance ;)
307 2017-12-27 20:49:16 0|gmaxwell|cluelessperson: yes, and that is how it has to be ultimately; because they keys don't even need to be stored in the wallet files.
308 2017-12-27 20:49:53 0|gmaxwell|some of that misunderstanding is due to the overly agressive initial sync screen, which could be clarified some.
309 2017-12-27 20:50:26 0|cluelessperson|gmaxwell: the problem is that the multiple softwares/wallets all have different methods of using/storying/importing keys. that's what's forcing users to use them directly.
310 2017-12-27 20:51:12 0|gmaxwell|They shouldn't be doing that, they should transfer funds. manually mucking with keys is supremely dangerous and for unsophicated users will reliably result in funds loss.
311 2017-12-27 20:51:41 0|gmaxwell|not to mention that keys from one program may not even be compatible with anything else.
312 2017-12-27 20:52:26 0|cluelessperson|Maybe I should write some procedure paper based on this topic.
313 2017-12-27 20:53:10 0|cluelessperson|gmaxwell: Another reason is that users sometimes go through a lot of effort to memorize seeds. They don't want to send to another wallet, they want to keep it.
314 2017-12-27 20:53:28 0|cluelessperson|that's what causes moving keys between softwares.
315 2017-12-27 20:54:28 0|gmaxwell|you cannot use different 'seeds' in different wallets. They aren't compatible and cannot reasonably be because the functionality is different.
316 2017-12-27 20:54:45 0|Bosma|Private keys have use now because they're used to claim fork funds.
317 2017-12-27 20:54:59 0|cluelessperson|Bosma: paper wallets
318 2017-12-27 20:55:03 0|sipa|Bosma: yeah &$#@!
319 2017-12-27 20:55:23 0|gmaxwell|cluelessperson: which no one should ever be using.
320 2017-12-27 20:56:01 0|gmaxwell|cluelessperson: and which are unrelated to bitcoin core in any case. (they cause a desire for _import_ which we support, not export)
321 2017-12-27 20:57:09 0|cluelessperson|gmaxwell: Another idea comes to mind. Suppose I should focus on writing up a list of reasons *why* I felt I'd want to change the wallet.dat structure. Part of it was to make it portable, modifiable, and allow users to just insert new keys at whim, from Electrum, BIP39, xpriv, xpub, WIF, mini, etc.
322 2017-12-27 20:57:33 0|gmaxwell|that cant work.
323 2017-12-27 20:57:44 0|cluelessperson|Honestly, it's not the wallet.dat that's the problem, it's that I'm asking for more features, and they're not being presented what the requested features are.
324 2017-12-27 20:59:04 0|cluelessperson|I'm confused how that can't work. Electrum does that to an extent.
325 2017-12-27 21:02:25 0|jb55|one of the first things I did was get my keys out of core, never felt comfortable having them in some arbitrary binary blob. I never recommend core wallet new people for that reason, I've seen so many lose their hd/etc. I force them to all get trezors now :P
326 2017-12-27 21:02:48 0|sipa|i agree there
327 2017-12-27 21:03:25 0|sipa|i don't think compatibility with other wallet software, or allowing inserting keys at a wh
328 2017-12-27 21:03:51 0|sipa|but there are benefits to a clearly understandable structure, which we currently really don't have
329 2017-12-27 21:04:01 0|cluelessperson|sipa: The only reason I mention electrum is because they did derivation first, so I consider them a standard.
330 2017-12-27 21:04:28 0|sipa|cluelessperson: and there's no reason to assume we'll want to be compatible - or if we do, that we can remain so
331 2017-12-27 21:05:16 0|jb55|hopefully we can crunch out a clean wallet upgrade path for hd hww's <> core soon. It's so hairy though gahh
332 2017-12-27 21:05:27 0|sipa|compatibility is nice when possible, but generally different wallets have such different ideas about what even constitutes a wallet that i don't think it's a worthwhile goal on its own
333 2017-12-27 21:05:31 0|sipa|jb55: yes!
334 2017-12-27 21:06:56 0|cluelessperson|Here's the thing
335 2017-12-27 21:07:16 0|cluelessperson|Pretty much everything uses BIP32/44 | xpriv,xpub right?
336 2017-12-27 21:07:23 0|sipa|no
337 2017-12-27 21:07:28 0|sipa|bip32 yes
338 2017-12-27 21:07:33 0|jb55|sipa no like 44
339 2017-12-27 21:07:44 0|cluelessperson|so, we could just store that and allow importing functions in general
340 2017-12-27 21:07:47 0|sipa|but electrum does not follow bip44 afaik
341 2017-12-27 21:07:56 0|sipa|cluelessperson: have you read my gist?
342 2017-12-27 21:08:05 0|sipa|(it suggests that)
343 2017-12-27 21:10:23 0|zelest|I have a /usr/local/lib/db4 (4.6.21) and I try to compile with --with-incompatible-bdb, yet ./configure fails with "libdb_cxx headers missing". By looking at the config.log, it tries to include bdb4.8/db_cxx.h, how can I specify what directory to look in?
344 2017-12-27 21:10:38 0|zelest|compile/configure*
345 2017-12-27 21:10:58 0|sipa|cluelessperson: but my gist also explains why doing so right now is very hard
346 2017-12-27 21:11:14 0|jb55|zelest: try 4.8?
347 2017-12-27 21:11:37 0|sipa|zelest: it needs at least 4.7 or 4.8
348 2017-12-27 21:11:49 0|sipa|(i forgot which of the two is the minimum)
349 2017-12-27 21:13:55 0|zelest|Ah, fair enough :)
350 2017-12-27 21:14:05 0|zelest|then I give up completely on the ports version of bdb :)
351 2017-12-27 21:58:04 0|zelest|wumpus, around?
352 2017-12-27 23:30:21 0|zelest|If I have a file I wish to change (quite a lot) and someone has already made a pull request with the same file. How should I approach it? wumpus told me to "please base it on" the pull request. Anyone care to explain what that means or how I do that? Thanks
353 2017-12-27 23:37:38 0|goatpig|zelest: pull the PR locally
354 2017-12-27 23:37:44 0|goatpig|rebase your commits on top of it
355 2017-12-27 23:40:23 0|zelest|Ah, and create a PR of that?
356 2017-12-27 23:40:37 0|goatpig|im guessing you'd be submitting that way yes
357 2017-12-27 23:40:46 0|zelest|Thanks