1 2017-11-23 07:31:52	0|fanquake|wumpus I'll have a look into adding configure checks for 4.8+
  2 2017-11-23 07:43:45	0|wumpus|fanquake: thanks! I looked around a bit and checking the type and version of the c++ compiler is harder than one'd expect, it's pretty much entirely unsupported
  3 2017-11-23 07:47:41	0|wumpus|fanquake: might be most straightforward to just add a "check you compiler version, only gcc 4.8 and higher is supported" message when AX_CXX_COMPILE_STDCXX  fails
  4 2017-11-23 07:47:49	0|wumpus|(and also add the minimum clang version then)
  5 2017-11-23 07:48:36	0|wumpus|as that macro will already fail on gcc 4.7 apparently
  6 2017-11-23 07:48:54	0|wumpus|and pass on 4.8
  7 2017-11-23 07:50:24	0|fanquake|wumpus yep, I was having a bit of a look as well. Didn't seem that straight forward. Especially since Clang also defines __GNUC__ etc
  8 2017-11-23 07:50:33	0|fanquake|No double cfields would have some black magic to get it done..
  9 2017-11-23 07:50:53	0|fanquake|wumpus I think you suggestion is good though. I'll put together a PR.
 10 2017-11-23 07:52:18	0|wumpus|yeah... what they suggest you really want to check is certain features, not the version number of the compiler, because different compilers have different version number schemes. But checking every single c++11 feature is going to be tiring
 11 2017-11-23 07:52:46	0|wumpus|what we realy want to check is "c++11 support at the level of gcc 4.8"
 12 2017-11-23 07:54:16	0|fanquake|wumpus Pretty certain GCC 4.8.1 is feature complete for c++11. So I think warning if AX_CXX_COMPILE_STDCXX fails should be enough?
 13 2017-11-23 07:54:40	0|fanquake|https://gcc.gnu.org/gcc-4.8/cxx0x_status.html
 14 2017-11-23 07:55:10	0|sipa|we could just try to compile something with a thread_local variable
 15 2017-11-23 07:56:15	0|wumpus|fanquake: yes, I think so... so we now require "full c++11" which is what that macro checks for
 16 2017-11-23 07:56:33	0|wumpus|so adding a better message should be enough
 17 2017-11-23 07:59:21	0|wumpus|sipa: yes, that would be another option
 18 2017-11-23 10:18:36	0|promag|jonasschnelli: ping
 19 2017-11-23 12:17:40	0|cluelessperson|I will be putting together some aggregated CSV data regarding block times, fees, transactions, etc.  Let me know if you want a link
 20 2017-11-23 12:18:14	0|promag|+1
 21 2017-11-23 12:30:28	0|promag|sipa: should there be support for P2WPKH in signmessage?
 22 2017-11-23 12:30:46	0|promag|verifymessage as well
 23 2017-11-23 12:42:19	0|promag|sipa: nevermind, already noted in #11403 description.
 24 2017-11-23 12:42:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
 25 2017-11-23 15:42:56	0|wumpus|should we cancel today's meeting because of thanksgiving?
 26 2017-11-23 15:45:34	0|luke-jr|I won't be able to make it, at leat
 27 2017-11-23 15:45:37	0|luke-jr|least*
 28 2017-11-23 15:50:56	0|wumpus|that's probably true for most people from the US
 29 2017-11-23 16:00:15	0|instagibbs|still may be a critical mass, though I will not be around
 30 2017-11-23 16:02:30	0|cluelessperson|wumpus: if there is a meeting, may I be present?
 31 2017-11-23 16:03:09	0|wumpus|cluelessperson: there's no need to ask that
 32 2017-11-23 16:04:27	0|wumpus|the meeting is here every week 19:00 UTC, everyone is welcome
 33 2017-11-23 16:14:42	0|cluelessperson|sweet, sorry, I've been hanging in channel, but I've been avoiding speaking here as I feel I lack skill sets to be of much help
 34 2017-11-23 16:16:02	0|wumpus|every week thursday*
 35 2017-11-23 16:17:24	0|luke-jr|if you don't have something helpful to say, don't say it; if you do, say it XD
 36 2017-11-23 16:26:07	0|cluelessperson|luke-jr: but my name is accurate!
 37 2017-11-23 17:33:18	0|mlz|no meeting today though?
 38 2017-11-23 17:33:29	0|sipa|i may be able to attend
 39 2017-11-23 17:34:16	0|mlz|Happy Thanksgiving to all Core devs! Thank you for your hard work and dedication!  :)
 40 2017-11-23 17:34:40	0|Eliel|how much memory does the UTXO set require per txout currently and what's the theoretical minimum it can be pushed down to?
 41 2017-11-23 17:40:20	0|Eliel|according to statoshi info, the current serialized UTXO set has ~55500000 transactions and that takes 2.9GB of space. So, that comes out to something like 53 bytes per utxo
 42 2017-11-23 17:40:42	0|Eliel|I suppose I'll go with that.
 43 2017-11-23 18:04:10	0|wumpus|mlz: thanks!
 44 2017-11-23 18:16:51	0|wumpus|Eliel: it also needs to be in an efficient format to make updates, otherwise you end up rewriting the whole thing for every block
 45 2017-11-23 18:18:07	0|Eliel|wumpus: would that be more than 53 bytes per txout?
 46 2017-11-23 18:18:38	0|wumpus|I mean you can probably save some space by just concatenating the whole thing then putting it through a compressor with a large block size, but except as a snapshot it'd not be useful
 47 2017-11-23 18:19:31	0|wumpus|I don't know.
 48 2017-11-23 18:20:13	0|wumpus|it will still be of the same order anyhow
 49 2017-11-23 18:20:34	0|Eliel|I'm trying to estimate the amount amount of RAM required on full nodes per user for LN users and non-LN users, so I guess the accuracy of the number is not a big issue. As long as it's not off by an order of magnitude :)
 50 2017-11-23 18:38:53	0|jonasschnelli|Oh. It's thanks giving... I would be around for the meeting.
 51 2017-11-23 18:43:33	0|wxss_|clear
 52 2017-11-23 18:47:38	0|meshcollider|I'm flying to Sydney in half an hour or so so I'll only be here for the first part of the meeting if it's on
 53 2017-11-23 19:00:33	0|achow101|Meeting?
 54 2017-11-23 19:01:53	0|Provoostenator|Suggested topic: onboarding
 55 2017-11-23 19:02:14	0|sipa|present
 56 2017-11-23 19:02:22	0|jonasschnelli|here
 57 2017-11-23 19:02:44	0|lightningbot|Meeting started Thu Nov 23 19:02:43 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 58 2017-11-23 19:02:44	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 59 2017-11-23 19:02:44	0|wumpus|#startmeeting
 60 2017-11-23 19:03:06	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
 61 2017-11-23 19:04:11	0|wumpus|Provoostenator: onboarding?
 62 2017-11-23 19:04:16	0|wumpus|#topic high priority for review
 63 2017-11-23 19:04:24	0|jonasschnelli|Should we discuss https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2 (sipas wallet design)?
 64 2017-11-23 19:04:26	0|wumpus|#link https://github.com/bitcoin/bitcoin/projects/8
 65 2017-11-23 19:04:31	0|jonasschnelli|ack
 66 2017-11-23 19:04:32	0|Provoostenator|I'd like to propose adding a project Onboarding to this list: https://github.com/bitcoin/bitcoin/projects
 67 2017-11-23 19:04:43	0|BlueMatt|wumpus: lol uhhhhhh its a holiday in .us
 68 2017-11-23 19:04:59	0|wumpus|Provoostenator: I don't understand what you mean with onboarding
 69 2017-11-23 19:05:10	0|jonasschnelli|m2
 70 2017-11-23 19:05:10	0|Provoostenator|That project would contain the first PR of any new contributor.
 71 2017-11-23 19:05:10	0|sipa|wumpus: bringing new people on board, i assume
 72 2017-11-23 19:05:20	0|wumpus|BlueMatt: yes, I asked whether to cancel the meeting earlier today
 73 2017-11-23 19:05:30	0|sipa|we
 74 2017-11-23 19:05:42	0|wumpus|BlueMatt: but only luke-jr was for it
 75 2017-11-23 19:05:47	0|sipa|we're clearly at lower attendance, so let's avoid committing to anything
 76 2017-11-23 19:06:00	0|sipa|doesn't mean things can't be discussed
 77 2017-11-23 19:06:02	0|wumpus|I'm fine with cancelling the meeting
 78 2017-11-23 19:06:14	0|BlueMatt|wumpus: heh, well everyone who would have suggested cancelling was already gone for vacation :p
 79 2017-11-23 19:06:23	0|wumpus|ok
 80 2017-11-23 19:06:31	0|jonasschnelli|Lets keep the meeting running...
 81 2017-11-23 19:06:31	0|wumpus|meeting is cancelled today
 82 2017-11-23 19:06:33	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-23-19.02.log.html
 83 2017-11-23 19:06:33	0|lightningbot|Meeting ended Thu Nov 23 19:06:32 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 84 2017-11-23 19:06:33	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-23-19.02.html
 85 2017-11-23 19:06:33	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-23-19.02.txt
 86 2017-11-23 19:06:33	0|wumpus|#endmeeting
 87 2017-11-23 19:06:37	0|jonasschnelli|;-)
 88 2017-11-23 19:06:37	0|promag|nice
 89 2017-11-23 19:06:40	0|achow101|we could still talk about things though
 90 2017-11-23 19:06:46	0|jonasschnelli|Sure.
 91 2017-11-23 19:06:54	0|promag|topic suggestion, network conf etc
 92 2017-11-23 19:07:04	0|jonasschnelli|Provoostenator: what would be the benefit behind that (first PR) project ?
 93 2017-11-23 19:07:11	0|Provoostenator|New PR's always get a lot of attention, but after a while they lose attention. That's fine for experienced devs, but I think it discourages new contribuors.
 94 2017-11-23 19:07:25	0|promag|o/
 95 2017-11-23 19:07:40	0|wumpus|Provoostenator: I think it's okay to go into this room and shout at people to review your PR
 96 2017-11-23 19:07:42	0|jonasschnelli|Provoostenator: Yes. One needs endurance. :)
 97 2017-11-23 19:07:45	0|Provoostenator|Once they get their first PR in, they're probably much more likely to keep contributing and be more assertive / patient.
 98 2017-11-23 19:08:14	0|jonasschnelli|If it looses attention, then it's probably not priority or the dev did not shout loud enough
 99 2017-11-23 19:08:29	0|jonasschnelli|The main bottleneck is still serious reviews
100 2017-11-23 19:08:34	0|kanzure|hi.
101 2017-11-23 19:08:35	0|achow101|jonasschnelli: sometimes people don't know that they should shout
102 2017-11-23 19:08:43	0|wumpus|I mean it's sometimes sad how PRs go ignored, but it's kind of how open source works, you need to bring attention to your PRs somehow
103 2017-11-23 19:08:48	0|kanzure|i missed the meeting :(
104 2017-11-23 19:08:49	0|Provoostenator|Yes, that's why this Project would only apply to the first PR. After that they can be encouraged to shout more.
105 2017-11-23 19:09:09	0|sipa|or people aren't aware that some things take a long time - and this doesn't mean they're not going to happen
106 2017-11-23 19:09:14	0|wumpus|e.g. if it fixes a issue, then reply to people posting issues to test your patch
107 2017-11-23 19:09:16	0|achow101|kanzure: we decided during the meeting that we wouldn't have a meeting :)
108 2017-11-23 19:09:21	0|jonasschnelli|sipa: indeed
109 2017-11-23 19:09:30	0|jonasschnelli|I think we should maybe add a beginners guide...
110 2017-11-23 19:09:37	0|jonasschnelli|Some people expect merges in 1-2 days.
111 2017-11-23 19:09:42	0|wumpus|add it to CONTRIBUTING.md
112 2017-11-23 19:09:47	0|jonasschnelli|yeah
113 2017-11-23 19:10:16	0|Provoostenator|Yeah, I've seen PR's by very experienced people open for over a year, so indeed peoples should have realistic expectations.
114 2017-11-23 19:10:19	0|jonasschnelli|Adding new PRs to the project would be another thing maintainers have to care about
115 2017-11-23 19:10:30	0|promag|there is also the case that a review sits there for a long time
116 2017-11-23 19:10:38	0|wumpus|bitcoin isn't really a good project for first time open source contributors in that regard, some projects just merge everything effectively instantly, but we cannot have a policy like that, not for first contributors ither
117 2017-11-23 19:10:45	0|jonasschnelli|Provoostenator: recently a 2yr old PR of mine got merged...
118 2017-11-23 19:11:03	0|sipa|my first PR took half a year, and that was in 2011 :)
119 2017-11-23 19:11:05	0|wumpus|promag: oh yes, indeed, some PRs get lots of review then the author pretty much just ignores it
120 2017-11-23 19:11:19	0|wumpus|promag: and they get closed after half a year or longer
121 2017-11-23 19:11:26	0|Provoostenator|@wumpus good point that it's not a good first open source project. Although the quality of reviews is really great for learning.
122 2017-11-23 19:11:28	0|jonasschnelli|Provoostenator: I think you could add a part in CONTRIBUTING.md
123 2017-11-23 19:11:40	0|jonasschnelli|that would be helpful for new contributors
124 2017-11-23 19:11:41	0|promag|right, it's also a bit weird to submit a PR, have reviews, and then it's ignored by the author
125 2017-11-23 19:12:05	0|BlueMatt|CBlockStore is still WIP from 2012 :p
126 2017-11-23 19:12:11	0|wumpus|authors can also get more attention by helping review other patches
127 2017-11-23 19:12:27	0|Provoostenator|I think contributing.md already says it takes a long time and you shoudl go on IRC.
128 2017-11-23 19:12:39	0|promag|true, some authors ignore other PR's, but that's more acceptable IMO
129 2017-11-23 19:12:48	0|wumpus|in any case of a PR really fixes a bug or issue, it won't usually take that long before it's merged unless something is wrong and not being fixed
130 2017-11-23 19:12:52	0|achow101|unfortunately people don't really read the documentation that explains what they should do
131 2017-11-23 19:13:08	0|Provoostenator|Yeah, so maybe something we could add to that doc is to encourage people to find a painful issue.
132 2017-11-23 19:13:17	0|wumpus|fix issues that affect peopel
133 2017-11-23 19:13:20	0|wumpus|yep
134 2017-11-23 19:13:42	0|Provoostenator|E.g. https://github.com/bitcoin/bitcoin/labels/good%20first%20issue
135 2017-11-23 19:13:44	0|achow101|easiest way to find issues is to read bitcointalk and wait for people to do stupid things
136 2017-11-23 19:13:48	0|wumpus|we mention that in the CONTRIBUTING a bit afaik, that a refactor or style change is a bad idea for first contributors
137 2017-11-23 19:13:55	0|Provoostenator|Though in that case we should make sure that that label is correctly applied.
138 2017-11-23 19:14:01	0|wumpus|maybe that could be extendded
139 2017-11-23 19:14:26	0|wumpus|Provoostenator: if you have suggestions on issues that should be labeled just highlight me or fanquake here
140 2017-11-23 19:14:45	0|promag|Provoostenator: there is also around 200 TODO in the code
141 2017-11-23 19:14:51	0|achow101|if we're actually going to use "good first issue" for this, we should probably remove the release schedule from that tag
142 2017-11-23 19:14:55	0|Provoostenator|I'm still not sure which issues are both easy enough for a first time contributor AND important enough to get attention in review.
143 2017-11-23 19:15:07	0|wumpus|achow101: yeah...
144 2017-11-23 19:15:11	0|achow101|it's funny and all, but has confused a few people too
145 2017-11-23 19:15:18	0|wumpus|achow101: makes it easy to find it though
146 2017-11-23 19:15:29	0|wumpus|achow101: really?
147 2017-11-23 19:15:32	0|achow101|make a release schedule tag
148 2017-11-23 19:16:17	0|wumpus|I think it's quite useful that the release schedule appears as one of the first issues people see
149 2017-11-23 19:16:30	0|Provoostenator|Has Google Summer of Code ever done Bitcoin Core projects? https://developers.google.com/open-source/gsoc/
150 2017-11-23 19:16:32	0|wumpus|can't really think of a way that would confuse anyone
151 2017-11-23 19:16:49	0|achow101|wumpus: it was mostly confusion as to why that was there
152 2017-11-23 19:16:51	0|Provoostenator|I participated in that in 2008 and it was a great experience. I haven't followed the program since though.
153 2017-11-23 19:17:45	0|Provoostenator|And they require a mentor from the project. I'm open to volunteer as a mentor.
154 2017-11-23 19:17:45	0|wumpus|we've never done that AFAIK
155 2017-11-23 19:18:16	0|wumpus|if anyone has a proposal for a project that would be a good fit for it we could try, but I'm not sure
156 2017-11-23 19:18:28	0|achow101|redo the wallet
157 2017-11-23 19:18:34	0|sipa|achow101: lol
158 2017-11-23 19:18:36	0|achow101|;)
159 2017-11-23 19:18:37	0|promag|ah
160 2017-11-23 19:18:39	0|jonasschnelli|heh...
161 2017-11-23 19:18:53	0|jonasschnelli|that's actually the topic i'd like to talk about
162 2017-11-23 19:18:55	0|jonasschnelli|(serious)
163 2017-11-23 19:18:58	0|aj|(integrated qt blockchain explorer?)
164 2017-11-23 19:19:44	0|Provoostenator|I don't know if we'd need to propose a project, or whether the student proposes a project (in coordination with a mentor).
165 2017-11-23 19:19:47	0|Provoostenator|I'll read up on it.
166 2017-11-23 19:19:52	0|jonasschnelli|sipa: your design documents states that there are a lot of changes that have to be made to the wallet,.. and...
167 2017-11-23 19:20:12	0|jonasschnelli|since we have multiwallet, would it not be simpler to add a 2nd wallet implementation that could be selective used for new wallets?
168 2017-11-23 19:20:14	0|wumpus|here, a PR by first-time contributor that gets a lot of review instantly: https://github.com/bitcoin/bitcoin/pull/11747
169 2017-11-23 19:20:18	0|sipa|jonasschnelli: i'm very happy to talk about that
170 2017-11-23 19:20:30	0|sipa|jonasschnelli: i really don't think so
171 2017-11-23 19:20:40	0|sipa|i've considered making a second wallet too, but it
172 2017-11-23 19:20:48	0|sipa|'s a pointless exercise i think
173 2017-11-23 19:20:56	0|wumpus|that was discussed so many times over the years
174 2017-11-23 19:21:00	0|achow101|jonasschnelli: I think it would be better to just make a new wallet format entirely and make it completely backwards incompatible
175 2017-11-23 19:21:01	0|Provoostenator|@wumpus new tickets always get tons of attention. It's the stale ones that worry me.
176 2017-11-23 19:21:10	0|sipa|achow101: indeed
177 2017-11-23 19:21:16	0|sipa|achow101: seen my writeup? :)
178 2017-11-23 19:21:20	0|achow101|sipa: yeah
179 2017-11-23 19:21:21	0|Provoostenator|And a new contributor might just pick the wrong topic (like making RBF a default :-)
180 2017-11-23 19:21:31	0|promag|sipa: >  pointless exercise i think - why?
181 2017-11-23 19:21:38	0|wumpus|Provoostenator: I don't think it's about newness in this case - the person explained clearly what the issue was, then fixed it, with a straightforward patch
182 2017-11-23 19:21:46	0|sipa|promag: those who don't know history are doomed to repeat it
183 2017-11-23 19:21:52	0|jonasschnelli|achow101, sipa: but wouldn't this end up in have a large amount of code handling the back. compatibilizt?
184 2017-11-23 19:22:08	0|wumpus|Provoostenator: it's also about communication and doing something people care about :)
185 2017-11-23 19:22:19	0|promag|sipa: and those that know history?
186 2017-11-23 19:22:26	0|jonasschnelli|I don't mean rewrite the wallet, I mean copy the wallet souces, remove accounts, remove pools, remove all the upgrade migrations, add new SW stuff
187 2017-11-23 19:22:43	0|jonasschnelli|same same but different
188 2017-11-23 19:22:49	0|sipa|promag: will have much more impact working on existing code, rather than starting over and hoping it will attract review attention
189 2017-11-23 19:22:50	0|wumpus|yeah...
190 2017-11-23 19:23:11	0|jonasschnelli|that's a point
191 2017-11-23 19:23:20	0|wumpus|jonasschnelli: well accounts should be removed out from the current source, not a copy
192 2017-11-23 19:23:26	0|sipa|ack
193 2017-11-23 19:23:29	0|wumpus|jonasschnelli: same for some of those other things
194 2017-11-23 19:23:52	0|jonasschnelli|I just fear the migration at statup thing...
195 2017-11-23 19:24:06	0|jonasschnelli|also,... that we keep BDB4.8 until core 0.25
196 2017-11-23 19:24:28	0|sipa|heh, swapping out the storage format seems orthogonal
197 2017-11-23 19:24:45	0|wumpus|changing the storage format to another database is pretty easy
198 2017-11-23 19:24:46	0|achow101|jonasschnelli: does it need to migrate at startup?
199 2017-11-23 19:24:58	0|wumpus|I changed it locally to leveldb a while ago
200 2017-11-23 19:25:02	0|sipa|jonasschnelli: for the storage format, it think it should be done independently from everything else
201 2017-11-23 19:25:25	0|sipa|so that it is a straight translation from one db to another, and none of the key/values inside change meaning
202 2017-11-23 19:25:34	0|sipa|which means upgrade and downgrade are trivial
203 2017-11-23 19:25:40	0|wumpus|(because I didn't want to port berkeleydb to that environment)
204 2017-11-23 19:25:45	0|wumpus|exactly sipa
205 2017-11-23 19:25:57	0|jonasschnelli|Yes. Right
206 2017-11-23 19:26:30	0|sipa|_independently_ we should think about a new semantic layer (see my writeup, for part of that), which will be an incompatible upgrade at some point i expect
207 2017-11-23 19:26:47	0|sipa|but it doesn't need to happen at the same time as the storage layer change
208 2017-11-23 19:27:10	0|jonasschnelli|sipa: you mean the record type schemantics?
209 2017-11-23 19:27:17	0|sipa|yes
210 2017-11-23 19:27:30	0|achow101|sipa: it seems like a storage layer change would be the easiest way to guarantee incompatibility
211 2017-11-23 19:27:44	0|wumpus|my biggest annoyance about the current wallet is that it reads everything into memory, it's a database ffs
212 2017-11-23 19:27:48	0|sipa|achow101: version numbers work pretty well :)
213 2017-11-23 19:28:02	0|jonasschnelli|sipa: you wrote "Conversion of old wallet to new ones will probably be the trickiest part. It will involve a one-time operation at startup"....
214 2017-11-23 19:28:09	0|achow101|sipa: but then you have two incompatible upgrades, versus one
215 2017-11-23 19:28:09	0|sipa|jonasschnelli: yes
216 2017-11-23 19:28:12	0|wumpus|there's no need to have all transactions and crap going back years in memory
217 2017-11-23 19:28:21	0|sipa|achow101: storage layer wouldn't be incompatible
218 2017-11-23 19:29:10	0|achow101|why would they be compatible? Older software wouldn't be able to read a new storage format
219 2017-11-23 19:29:16	0|jonasschnelli|I gust questioning the endless backward compatibility. If we don't do us a favor and set a point (version X) where the wallet crated with version X will no longer be backware comp.
220 2017-11-23 19:29:24	0|sipa|sure, but both upgrade and downgrade would be trivial
221 2017-11-23 19:30:08	0|sipa|both things can happen in the same release, and that would certainly be more convenient
222 2017-11-23 19:30:14	0|achow101|right, but then you need something that can downgrade it. if you just downgrade the software, it would be incompatible
223 2017-11-23 19:30:14	0|wumpus|jonasschnelli: backwards compatibility is extremely important, though it'd be fine with me if that's a one-time upgrade at some point
224 2017-11-23 19:30:25	0|sipa|but i don't think discussions about changing the storage format should get in the way of semantic changes
225 2017-11-23 19:30:26	0|wumpus|jonasschnelli: but people with old wallets shouldn't be stuck!
226 2017-11-23 19:30:29	0|sipa|and the other way around
227 2017-11-23 19:30:43	0|wumpus|but downgrading seems completely unimportant to me
228 2017-11-23 19:30:49	0|jonasschnelli|wumpus: Yes. This is why I though keeping the legcy stuff but not mixing the code.
229 2017-11-23 19:31:21	0|achow101|ooh we could make CWallet, CDB, CWalletDB, etc. actually make sense then!
230 2017-11-23 19:31:28	0|sipa|hehe
231 2017-11-23 19:31:34	0|Provoostenator|There's also the possibility of importing old wallet from backups rather than old database files. Obviously not a good experience at all.
232 2017-11-23 19:32:00	0|wumpus|achow101: some of the classes need renaming, that's orthogonal :)
233 2017-11-23 19:32:19	0|jonasschnelli|achow101: and there are still some layer violations...
234 2017-11-23 19:32:28	0|sipa|Provoostenator: ?
235 2017-11-23 19:32:36	0|sipa|backups are database files
236 2017-11-23 19:32:46	0|Provoostenator|Oh, it's not using the dump format?
237 2017-11-23 19:32:56	0|sipa|the dump format is just for keys
238 2017-11-23 19:32:58	0|wumpus|no, not if you use walletbackup
239 2017-11-23 19:33:07	0|achow101|Provoostenator: no, it just copies the wallet.dat file to somewhere lese
240 2017-11-23 19:33:12	0|wumpus|dumpwallet/importwallet is separate
241 2017-11-23 19:33:50	0|Provoostenator|I see. Having a backup format that's not a database file would be useful then?
242 2017-11-23 19:34:12	0|sipa|it's complicated
243 2017-11-23 19:34:21	0|wumpus|what do you want to backup?
244 2017-11-23 19:34:28	0|sipa|we have two axes really... secret or not, and mutable or not
245 2017-11-23 19:34:28	0|wumpus|if it's just the keys, dumpwallet is what you want
246 2017-11-23 19:34:29	0|Provoostenator|Keys and metadata.
247 2017-11-23 19:34:42	0|wumpus|if you also want transactions and transaction metadata it's kind of difficult
248 2017-11-23 19:34:55	0|sipa|for example address labels really require a dump after every new address created
249 2017-11-23 19:35:13	0|sipa|stored transactions (especially unconfirmed ones) need a dump after every transaction
250 2017-11-23 19:35:45	0|sipa|but with HD wallets, you don't really need backups at all to prevent monetary loss
251 2017-11-23 19:35:56	0|Provoostenator|I guess I'd want two backups: 1) the HD seed, done once 2) everything else, done every now and then
252 2017-11-23 19:35:57	0|sipa|and which of those is more important depends on the use case
253 2017-11-23 19:36:15	0|sipa|for businesses, losing labels/transactions may be far more harmful than losing some money
254 2017-11-23 19:36:36	0|wumpus|the hd seed is in dumpwallet, for (2) a backupwallet makes sense
255 2017-11-23 19:36:50	0|wumpus|if you just want to backup all data why not use the database format itself
256 2017-11-23 19:36:53	0|Provoostenator|Yes, and businesses need a paper trail for audits, ideally one that doesn't contain a private key.
257 2017-11-23 19:37:05	0|sipa|so perhaps there should be a way to separate the two
258 2017-11-23 19:37:17	0|Provoostenator|Because a database format is too specific.
259 2017-11-23 19:37:20	0|jonasschnelli|sipa: hardware wallets?
260 2017-11-23 19:37:43	0|wumpus|Provoostenator: too specific for what? the metadata format is also completely specific to this wallet
261 2017-11-23 19:37:52	0|Provoostenator|There's no bookkeeper / accountant in the world that can handle a .dat file, but they all know CSV or some other more text-like standard.
262 2017-11-23 19:38:00	0|jonasschnelli|I think long term we should not expect that private keys are on the same machine then bitcoin core runs (at least not with the current one process design)
263 2017-11-23 19:38:19	0|wumpus|Provoostenator: the GUI can do a csv export of transactions
264 2017-11-23 19:38:31	0|wumpus|Provoostenator: if that's what you want
265 2017-11-23 19:38:48	0|wumpus|also you can trivially implement that with a listtransactions then convert the JSON to CSV
266 2017-11-23 19:38:59	0|wumpus|no need for that to be the client's storage format
267 2017-11-23 19:39:54	0|wumpus|too many people are trying to solve problems by changing the program's internal storage format to be an external interface
268 2017-11-23 19:39:57	0|Provoostenator|Ah I didn't know that feature. That's a good step and probably the most important metadata.
269 2017-11-23 19:39:57	0|wumpus|that's IMO wrong
270 2017-11-23 19:40:18	0|wumpus|if you want to export something, export it somehow, export exactly the data you need for some reason
271 2017-11-23 19:40:36	0|wumpus|doesn't need to map to any internal data storage separation
272 2017-11-23 19:40:53	0|Provoostenator|There's also the issue of long term storage.
273 2017-11-23 19:40:55	0|wumpus|do you care how mysql stores its files? (besides it being efficient)
274 2017-11-23 19:41:15	0|Provoostenator|In 50 years a txt dump will be readable, I doubt anyone can still parse the DB format.
275 2017-11-23 19:41:30	0|wumpus|Provoostenator: that's where the dump format is for!
276 2017-11-23 19:41:55	0|Provoostenator|@wumpus true
277 2017-11-23 19:42:22	0|wumpus|it contains the private keys and the HD seed
278 2017-11-23 19:42:27	0|meshcollider|And if you go and review #11667 then the dump format can include the scripts too ;)
279 2017-11-23 19:42:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/11667 | Add scripts to dumpwallet RPC by MeshCollider · Pull Request #11667 · bitcoin/bitcoin · GitHub
280 2017-11-23 19:42:36	0|wumpus|meshcollider: yes!
281 2017-11-23 19:42:49	0|Provoostenator|@gribble added to my list
282 2017-11-23 19:42:59	0|wumpus|we have a surprising lot already covered with the current functionality
283 2017-11-23 19:43:17	0|sipa|i wish we didn't have to continue the "bag-of-keys-and-script" approach in dumps, but i don't think there is a way around it now
284 2017-11-23 19:44:03	0|wumpus|how do you mean? how would a dump work if it doesn't contain keys and scripts?
285 2017-11-23 19:44:12	0|sipa|wumpus: read my writeup
286 2017-11-23 19:44:45	0|Provoostenator|@sipa apart from your (useful) writeup, is there any other good documentation on how the wallet database and in memory storage currently works?
287 2017-11-23 19:44:47	0|wumpus|at least for compatiblity with other software it's probably useful if it contains all that data
288 2017-11-23 19:45:10	0|sipa|Provoostenator: https://github.com/bitcoin/bitcoin/tree/master ;)
289 2017-11-23 19:45:12	0|Provoostenator|And how that's seperated between the RPC and GUI, if at all.
290 2017-11-23 19:45:31	0|sipa|Provoostenator: there is no separation, they act on the same data structures
291 2017-11-23 19:45:33	0|jonasschnelli|only the code can tell you
292 2017-11-23 19:45:41	0|Provoostenator|@sipa I thought so. I'll figure it out eventually, but probably not before you've finished and merged the improvements.
293 2017-11-23 19:46:16	0|Provoostenator|Is the idea to have the GUI communicate with the RPC and not have direct access to wallet.dat files?
294 2017-11-23 19:46:37	0|sipa|i don't believe the RPC interface is the right approach
295 2017-11-23 19:46:40	0|Provoostenator|Or is the GUI not supposed to be completely seperate?
296 2017-11-23 19:46:47	0|wumpus|what do you hope to accomplish with that?
297 2017-11-23 19:47:00	0|wumpus|besides satisfying some degree of 'code neatness'
298 2017-11-23 19:47:04	0|sipa|ryanofsky is working on separating the gui from the daemon, but through a specialized interface
299 2017-11-23 19:47:11	0|sipa|rather than through RPC
300 2017-11-23 19:47:29	0|Provoostenator|For one thing, running a GUI wallet on a different machine.
301 2017-11-23 19:47:52	0|wumpus|the RPC is not for remote communication
302 2017-11-23 19:47:54	0|dejarp|sounds like there needs to be an open standard for wallet files
303 2017-11-23 19:47:56	0|wumpus|:-)
304 2017-11-23 19:48:00	0|jonasschnelli|Provoostenator: I think an viable approach here is communicating over the p2p with SPV and BIP150/151
305 2017-11-23 19:48:10	0|Provoostenator|ACtually to be more precise, I'd like to keep the blockchain on a seperate machine
306 2017-11-23 19:48:10	0|sipa|Provoostenator: running a GUI *wallet* on a different machine (from the node)? or running a *GUI* on the a different machine (from the wallet)
307 2017-11-23 19:48:25	0|sipa|Provoostenator: lightweight mode is the way to go there
308 2017-11-23 19:48:43	0|sipa|Provoostenator: run several lightweight node+wallet instances, have them connect to a trusted full node
309 2017-11-23 19:48:45	0|Provoostenator|@sipa the first is good enough.
310 2017-11-23 19:48:47	0|jonasschnelli|Provoostenator: please review https://github.com/bitcoin/bitcoin/pull/10794 (its a stepping stone for GUI sep.)
311 2017-11-23 19:49:14	0|sipa|jonasschnelli: no it isn't?
312 2017-11-23 19:49:22	0|jonasschnelli|sipa: why not?
313 2017-11-23 19:49:27	0|Provoostenator|@jonasschnelli added to list. Good to understand the context.
314 2017-11-23 19:49:38	0|Provoostenator|(actually that was already on my review list :-)
315 2017-11-23 19:50:14	0|sipa|jonasschnelli: GUI separation is about sepating the wallet from the UI
316 2017-11-23 19:50:21	0|sipa|jonasschnelli: that PR is about separating the wallet from the node
317 2017-11-23 19:50:35	0|jonasschnelli|sipa: I though we are talking about bothj
318 2017-11-23 19:50:46	0|Provoostenator|Do I understand correctly that it still needs to download blocks?
319 2017-11-23 19:50:47	0|jonasschnelli|GUI from the wallet is a different things...
320 2017-11-23 19:50:51	0|sipa|jonasschnelli: yes, but they're entirely orthogonal
321 2017-11-23 19:51:05	0|Provoostenator|I mean, I'd like to be able to tell a node: here's the public keys for my wallet, go watch them, I'll call you if I need anything.
322 2017-11-23 19:51:15	0|Provoostenator|(a very trusted node obviously)
323 2017-11-23 19:51:19	0|sipa|jonasschnelli: you're saying that 10794 is a step towards GUI separation... no it isn't, it has nothing to do with it
324 2017-11-23 19:51:30	0|sipa|it's a step towards separating the wallet from the validation
325 2017-11-23 19:51:44	0|meshcollider|Provoostenator: isn't that exactly what SPV does with bloom filters
326 2017-11-23 19:51:45	0|wumpus|Provoostenator: FWIW that's how electrum works
327 2017-11-23 19:51:49	0|Provoostenator|And this would also make it easier to connect third party wallets to a full node.
328 2017-11-23 19:51:58	0|wumpus|Provoostenator: and all other light clients, yeah
329 2017-11-23 19:52:02	0|jonasschnelli|sipa: I think it is a step towards Provoostenator usecase "run the wallet on a different machine".
330 2017-11-23 19:52:13	0|sipa|Provoostenator: the P2P protocol already supports that fine
331 2017-11-23 19:52:31	0|Provoostenator|Bloom filters seem overkill if you trust the node (and encryption and such are fixed)
332 2017-11-23 19:52:44	0|jonasschnelli|Provoostenator: yes. But the code is there and works. :)
333 2017-11-23 19:53:12	0|wumpus|yes, bloom filters work right now
334 2017-11-23 19:53:21	0|wumpus|there's been so much discussion of doing other things
335 2017-11-23 19:53:22	0|wumpus|for years
336 2017-11-23 19:53:37	0|jonasschnelli|Provoostenator: and it would also allow one to scarify privacy and connect to a random peer in case his trusted peer is unavailable
337 2017-11-23 19:53:54	0|wumpus|if you want the just-send-pubkeys approach, look at the electrum protocol
338 2017-11-23 19:54:01	0|Provoostenator|Working code and random-peer-fallback is certainly a benefit.
339 2017-11-23 19:54:53	0|wumpus|run your own trusted electrum server, the client-to-server protocol is encrypted, so you're covered there
340 2017-11-23 19:55:23	0|Provoostenator|@wumpus doesn't the electrum server need a huge database on top of the blockchain storage?
341 2017-11-23 19:55:26	0|wumpus|no need to reinvent everything in the ecosystem just to put the 'core' label on it
342 2017-11-23 19:55:34	0|wumpus|Provoostenator: yes, that's what you need for *general* querying by pubkey
343 2017-11-23 19:56:05	0|wumpus|Provoostenator: if your wallet keeps its own state and tracks the blockchain, then you don't need that, that's more like SPV clients
344 2017-11-23 19:56:15	0|wumpus|Provoostenator: it's a compromise
345 2017-11-23 19:56:25	0|Provoostenator|Watch-only addresses are another route, right?
346 2017-11-23 19:56:44	0|Provoostenator|So you'd give your trusted node a set of addresses to watch moving forward, and then you use bloom filters to get info later.
347 2017-11-23 19:57:15	0|Provoostenator|So then the only new feature is watch-only addresses, if I understand correctly (no idea how hard that is).
348 2017-11-23 19:58:07	0|wumpus|watch-only addresses have been supported for ages, for example the joinmarket wallet uses them
349 2017-11-23 20:00:05	0|sipa|though you query them over RPC, not via P2P-Bloom
350 2017-11-23 20:00:11	0|wumpus|importaddress was first added in 0.10.0
351 2017-11-23 20:00:13	0|jtimon|oops, missed the meeting...
352 2017-11-23 20:00:20	0|wumpus|yes... they're completely separate
353 2017-11-23 20:00:25	0|wumpus|jtimon: there was no meeting, thanksgiving
354 2017-11-23 20:00:34	0|jtimon|oh, ok
355 2017-11-23 20:04:30	0|Provoostenator|I need to read up on what bloom filter functionality is in Core.
356 2017-11-23 20:05:34	0|wumpus|Provoostenator: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
357 2017-11-23 20:05:35	0|sipa|BIP37
358 2017-11-23 20:06:46	0|bitcoin-git|[13bitcoin] 15ldm5180 opened pull request #11760: [crypto] Refactor HMAC_SHA to eliminate code duplication (06master...06generic-hmac_sha) 02https://github.com/bitcoin/bitcoin/pull/11760
359 2017-11-23 20:09:16	0|Varunram|Hey, I'm new here but thanks for the attention to new devs, it'll help a lot!
360 2017-11-23 20:10:48	0|Varunram|I'd like to pitch in regarding GSoC, applications open january 4, if core is interested. You guys will be required to propose a project (or at least a list of possible projects) and applicants will have to choose from them. First time orgs get only 1-2 slots though
361 2017-11-23 20:12:07	0|Varunram|Doesn't matter for a big project like Core, but still, my 2 sats :)
362 2017-11-23 20:14:11	0|wumpus|Varunram: thanks for the info - but yes we'll have to think a bit about possible projects then,maybe a topic for next meeting
363 2017-11-23 20:21:31	0|Provoostenator|wumpus: so IIUC: SPV uses more bandwidth than the just-send-pubkeys approach, but doesn't require running an electrum server?
364 2017-11-23 20:22:05	0|Provoostenator|jonasschnelli: and IIUC your goal with #10794 is to pave the way to run a Core wallet in SPV mode?
365 2017-11-23 20:22:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
366 2017-11-23 20:24:53	0|jonasschnelli|Provoostenator: SPV (especially full block without client side filtering) takes much more bandwith...
367 2017-11-23 20:25:13	0|Provoostenator|I should have more specific: to use bloom filters?
368 2017-11-23 20:25:19	0|jonasschnelli|Electrum does not preserve your privacy
369 2017-11-23 20:25:26	0|jonasschnelli|Bloom filter also not
370 2017-11-23 20:25:30	0|jonasschnelli|*filters
371 2017-11-23 20:25:35	0|Provoostenator|Well, it does if it's my own machine :-)
372 2017-11-23 20:25:52	0|jonasschnelli|Yes.. and if the channel is encrypted and authenticated.
373 2017-11-23 20:26:03	0|jonasschnelli|BF would be okay if BIP150/151
374 2017-11-23 20:26:11	0|Provoostenator|I'm trying to think about the use case where I have my own full node in some place, but I want to make transactions on my computer / phone / wherever.
375 2017-11-23 20:26:19	0|Provoostenator|And understanding the various trade-offs.
376 2017-11-23 20:26:24	0|wumpus|electrum uses TLS by default, FWIW
377 2017-11-23 20:26:33	0|jonasschnelli|Provoostenator: I see two solutions for that...
378 2017-11-23 20:26:54	0|Provoostenator|(assuming BIP150/151 for the sake of argument)
379 2017-11-23 20:27:02	0|jonasschnelli|a) you use BIP150 (or other enc/auth) via p2p and use SPV BF on your phone/remove client
380 2017-11-23 20:27:06	0|wumpus|as long as you use it with your own server it's ok, and it already exists
381 2017-11-23 20:27:23	0|jonasschnelli|b) you add a script to your bitcoin core machine that would server over TLS (an RPC proxy)
382 2017-11-23 20:27:36	0|jonasschnelli|b2) while your remote phone is just an "extended" RPC client
383 2017-11-23 20:27:52	0|jonasschnelli|(which would also have the private keys)
384 2017-11-23 20:28:02	0|Provoostenator|An additional contraint is that I would trust the node for giving me correct data, but not for holding private keys. I'm not sure if that's a reasonable contraint.
385 2017-11-23 20:28:27	0|jonasschnelli|Yes. The probably simplest approach would be SPV BF over auth/enc
386 2017-11-23 20:28:51	0|jonasschnelli|10794 follows also another goal..
387 2017-11-23 20:28:59	0|jonasschnelli|What if you don't have a remote node?
388 2017-11-23 20:29:28	0|jonasschnelli|10794 (and future work) does allow you to use the wallet while your node is still bootstraping
389 2017-11-23 20:29:52	0|jonasschnelli|My primary goal is to work against the current wallet trend... which is..
390 2017-11-23 20:30:04	0|Provoostenator|@jonasschnelli b2 might be acceptable with an ecrypted wallet, but a seems better
391 2017-11-23 20:30:06	0|jonasschnelli|centralized validation, and even remote key holding
392 2017-11-23 20:30:41	0|jonasschnelli|The current bitcoin wallets do loose one of the primary elements Bitcoin can defeat "Trusted third parties are security holes".
393 2017-11-23 20:30:50	0|Provoostenator|I'm thinking e.g. a full node at home, where if someone physcailly breaks in I'd know about that and just not use it.
394 2017-11-23 20:30:58	0|jonasschnelli|I'd like to see more users using Bitcoin Core as a wallet
395 2017-11-23 20:31:40	0|Provoostenator|@jonasschnelli me too, but I think a more realistic scenario is more people running Bitcoin Core nodes and connecting their favorite wallet to it.
396 2017-11-23 20:31:52	0|jonasschnelli|But right now,... the burden is just to hight
397 2017-11-23 20:32:04	0|jonasschnelli|Provoostenator: both is possible....
398 2017-11-23 20:32:19	0|Provoostenator|Although with things like #11720 it might be possible, certainly with bloom filters.
399 2017-11-23 20:32:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/11720 | iOS Deployment Target for RPC · Issue #11720 · bitcoin/bitcoin · GitHub
400 2017-11-23 20:32:25	0|jonasschnelli|BIP150/151 would work towards trustworthy direct connections
401 2017-11-23 20:32:36	0|jonasschnelli|Provoostenator: Sure!
402 2017-11-23 20:33:09	0|Provoostenator|Right, these are all useful ingredients. I'm mostly trying to wrap my head around how they all fit together.
403 2017-11-23 20:34:35	0|jonasschnelli|With the current RPC calls it would also be possible to write a (iOS) client that would speak over RPC (via a proxy/apache script via TLS)... the client would hold the keys
404 2017-11-23 20:34:46	0|jonasschnelli|and use fundrawtransaction and watch-onlies
405 2017-11-23 20:36:45	0|Provoostenator|Something tells me more people will use it if it "just works" and everything happens on the phone.
406 2017-11-23 20:37:57	0|Provoostenator|Another benefit of using the Core code base is that you don't have to re-invent the wheel for things like coin selection (especially if it gets dramatic improvements in the future).
407 2017-11-23 20:38:37	0|jonasschnelli|The "just works" approach is very important and a reason why I try to kick BIP150/151 forward even with the fact that it's already sort of possible with stunnel, VPN, TOR
408 2017-11-23 20:40:32	0|Provoostenator|jonasschnelli: I was quite surprised when I learned encryption wasn't already a thing. I liked your talk: https://www.youtube.com/watch?v=6VZrT9IOq30
409 2017-11-23 20:43:10	0|wumpus|TIL there's a program called "tig" that is a ncurses (terminal) git UI, I really like it
410 2017-11-23 20:44:58	0|jonasschnelli|looks nice
411 2017-11-23 20:46:30	0|wumpus|yes I'm surprised I hadn't heard about it before
412 2017-11-23 20:48:36	0|Provoostenator|Speaking of tools: any favorite IRC clients for OSX? And a good way to setup email notifications if someone mentions you when you're offline? I'm trying to set that up through the Slack bridge now.
413 2017-11-23 20:53:25	0|sipa|Provoostenator: i use ssh + screen + irssi
414 2017-11-23 20:53:26	0|wumpus|dunno about mail notifications, but I kind of like quassel, it has a separate frontend and backend, so from whatever device you log in your backlog is there, including highlights if someone mentioned you
415 2017-11-23 20:54:06	0|jonasschnelli|Provoostenator: I use Textual 7 (macOS) with a ZNC bouncer
416 2017-11-23 20:54:23	0|jonasschnelli|Provoostenator: I use a ZNC mod that sends me a Telegram on PM
417 2017-11-23 20:54:36	0|wumpus|there's also a pyquassel to connect programmatically, it's possible to watch for messages and set up things like mail notification or other scripting
418 2017-11-23 20:54:37	0|jonasschnelli|(the mod has various push channels)
419 2017-11-23 20:55:14	0|jonasschnelli|Provoostenator: ZNC is you IRC swiss army knife... also can log for you, etc.
420 2017-11-23 20:55:18	0|wumpus|but yeah you can do the same with irssi - there's even an irssi based frontend for quassel if you want to combine them :-)
421 2017-11-23 20:59:07	0|Provoostenator|Thanks, I'll take a look at both approaches.
422 2017-11-23 21:12:11	0|wumpus|github's commit notifier is broken again
423 2017-11-23 21:17:53	0|jonasschnelli|wumpus: the twitter bridge worked... only IRC?
424 2017-11-23 21:19:20	0|wumpus|jonasschnelli: seems so!
425 2017-11-23 22:21:56	0|phantomcircuit|wumpus, i like znc more than quassel
426 2017-11-23 22:22:23	0|wumpus|ok, I prefer quassel
427 2017-11-23 22:24:01	0|sipa|real programmers use telnet, and speak RFC2812 natively
428 2017-11-23 22:25:44	0|wumpus|hah
429 2017-11-23 22:26:30	0|phantomcircuit|sipa, gl replying to pings in time from freenode
430 2017-11-23 22:27:49	0|telnetuser|@phantomcircuit no problem, you'll see!
431 2017-11-23 22:30:24	0|wumpus|phantomcircuit: no more idlers
432 2017-11-23 22:31:26	0|phantomcircuit|lol you are using telnet
433 2017-11-23 22:31:51	0|sipa|damn, how do i type a CTCP version reply? :(
434 2017-11-23 22:35:37	0|phantomcircuit|sipa, gotcha
435 2017-11-23 22:35:45	0|phantomcircuit|you have to be able to send 0x01
436 2017-11-23 22:36:12	0|sipa|yes, i found that out
437 2017-11-23 22:36:19	0|sipa|but don't know how to do that in telnet
438 2017-11-23 22:36:23	0|sipa|offtopic i guess :)
439 2017-11-23 22:37:17	0|wumpus|through xclip maybe
440 2017-11-23 22:39:01	0|wumpus|or ctrl-A if it works
441 2017-11-23 23:02:41	0|phantomcircuit|sipa, fail