1 2015-03-24 00:00:16 <sipa> well you can make it the same wallet without reusing the chain
  2 2015-03-24 00:00:42 <sipa> i assume?
  3 2015-03-24 00:00:51 <familiar> I suppose that's true
  4 2015-03-24 00:01:14 <familiar> That would somewhat complicate the code but it isn't impossible
  5 2015-03-24 00:01:29 <familiar> Is it wrong to re-use the chain though ?
  6 2015-03-24 00:01:40 <sipa> it means you risk reusing addresses
  7 2015-03-24 00:01:48 <sipa> or keys, at least
  8 2015-03-24 00:02:07 <sipa> which is the whole point of using deterministic derivation instead of just a single key
  9 2015-03-24 00:02:34 <sipa> reuse of addresses hurts the privacy of bitcoin very significantly
 10 2015-03-24 00:02:38 <sipa> not just your own
 11 2015-03-24 00:02:55 <sipa> if you wouldn't care about it, maybe the people you interact with do
 12 2015-03-24 00:03:25 <familiar> ah .. the BIP32 algo would always look for the first address that doesn't contain any previous txn's right?
 13 2015-03-24 00:03:36 <sipa> yes
 14 2015-03-24 00:03:44 <sipa> using some lookahead window, typically
 15 2015-03-24 00:03:51 <sipa> though that isn't specified in bip32
 16 2015-03-24 00:03:54 <sipa> maybe it is is bip44
 17 2015-03-24 00:05:16 <familiar> but then doesn't BIP45 save me from that reuse problem? Since it uses a distinct path m/45'/0/0'x
 18 2015-03-24 00:05:45 <sipa> yes?
 19 2015-03-24 00:05:57 <sipa> it's still a separate chain of keys within the same wallet that you want
 20 2015-03-24 00:06:03 <sipa> whether you follow the standard or not :)
 21 2015-03-24 00:07:08 <familiar> I don't follow sorry
 22 2015-03-24 00:08:05 <familiar> Chain means the logic of determining new addresses ?
 23 2015-03-24 00:08:05 <sipa> i probably miss context to discuss things
 24 2015-03-24 00:08:20 <sipa> i have stopped following on wallet developments in that area after bip32
 25 2015-03-24 00:08:33 <sipa> chain = list of keys
 26 2015-03-24 00:08:41 <sipa> m/45'/0/ is a chain
 27 2015-03-24 00:09:21 <sipa> so is m/0/1/2/3/4/5/6'/7/8
 28 2015-03-24 00:12:40 <familiar> I think that answered my question.. thank you
 29 2015-03-24 07:48:17 <King_Lui> salem maleikum
 30 2015-03-24 08:07:37 <Stifflers_MOM> 1
 31 2015-03-24 08:09:08 <Stifflers_MOM>  /msg chanserv autop me
 32 2015-03-24 08:12:11 <Stifflers_MOM> Freie Netze werden von immer mehr Menschen in Eigenregie aufgebaut und gewartet. Jeder Nutzer im freifunk-Netz stellt seinen WLAN-Router für den Datentransfer der anderen Teilnehmer zur Verfügung. Im Gegenzug kann er oder sie ebenfalls Daten, wie zum Beispiel Text, Musik und Filme über das interne freifunk-Netz übertragen oder über von Teilnehmern eingerichtete Dienste im Netz Chatten, Telefonieren und gemeinsam Onlinegames
 33 2015-03-24 08:12:13 <Stifflers_MOM> spielen. Dafür nutzen wir Mesh Netzwerke.
 34 2015-03-24 08:12:15 <Stifflers_MOM> Viele stellen zudem ihren Internetzugang zur Verfügung und ermöglichen anderen den Zugang zum weltweiten Netz. Freifunk-Netze sind Selbstmach-Netze. Für den Aufbau nutzen wir die freifunk-Firmware auf unseren WLAN-Routern, eine spezielle Linuxdistribution.
 35 2015-03-24 08:12:17 <Stifflers_MOM> Lokale Communities stellen die auf eigene Bedürfnisse angepasste Software dann auf ihren Websites zur Verfügung. In Dörfern und Städten gibt es immer mehr Freifunk-Gruppen, die sich regelmässig treffen.
 36 2015-03-24 08:12:19 <Stifflers_MOM> Die freifunk-Community ist Teil einer globalen Bewegung für freie Infrastrukturen und offene Funkfrequenzen.
 37 2015-03-24 08:12:21 <Stifflers_MOM> Unsere Vision ist die Demokratisierung der Kommunikationsmedien durch freie Netzwerke. Die praktische Umsetzung dieser Idee nehmen freifunk-Communities in der ganzen Welt in Angriff.
 38 2015-03-24 08:12:24 <Stifflers_MOM> Und auch du kannst bei Freifunk mitmachen! Wie, das erfährst du hier!
 39 2015-03-24 08:25:21 <wumpus> what is all this crap
 40 2015-03-24 08:27:56 <phantomcircuit> wumpus, spam
 41 2015-03-24 08:28:12 <phantomcircuit> weird spam
 42 2015-03-24 08:28:13 <wumpus> in german? for WLAN routers?
 43 2015-03-24 08:28:17 <wumpus> right
 44 2015-03-24 08:29:29 <sipa> it's been in japanese and arabic befote
 45 2015-03-24 08:52:35 <jaromil> at least the subject was not ugly now, speaking of the free movement of wifi mesh networking in .de
 46 2015-03-24 09:06:02 <jonasschnelli> i try to understand the reconstruction of bip32 chain with a existing master seed and have some questions (i hope this is the right channel)
 47 2015-03-24 09:06:14 <sipa> sure
 48 2015-03-24 09:06:21 <jonasschnelli> what if a lost my wallet file
 49 2015-03-24 09:06:59 <jonasschnelli> (sorry, acc. enter) but still have the master seed...
 50 2015-03-24 09:07:22 <jonasschnelli> and then try to reconstruct my wallet.... how does the app know which addresses it needs to reconstruct?
 51 2015-03-24 09:07:38 <jonasschnelli> (lets assume i also lost my wtx list; gone with the wallet file)
 52 2015-03-24 09:08:08 <sipa> in case the wallet structure is known, you would use a lookahead window
 53 2015-03-24 09:08:22 <sipa> generate the first 100 keys
 54 2015-03-24 09:08:27 <sipa> start scanning for them
 55 2015-03-24 09:08:43 <sipa> if one of them gets used, extend the window to be 100 keys past the last used one
 56 2015-03-24 09:08:49 <sipa> and resume scanning with those
 57 2015-03-24 09:09:15 <jonasschnelli> so generate m / 44' / 0' / 0' / 0 / (0-100) and scan the whole blockchain for matches?
 58 2015-03-24 09:09:39 <jonasschnelli> (i assume i lost everything but not the master seed)
 59 2015-03-24 09:09:45 <sipa> but in general, i don't like the idea of brainwallets/paperwallets for more than "my wallet has a balance and i can send and receive"
 60 2015-03-24 09:10:00 <sipa> anything beyond that likely needs the actual wallet history
 61 2015-03-24 09:10:25 <sipa> for many business uses, keeping the accounting may be more important than having access to the actual funds
 62 2015-03-24 09:10:56 <sipa> so all that deterministic wallets give you is reproducability across machines
 63 2015-03-24 09:11:11 <sipa> and the fact that you only need a small amount of "secure" storage
 64 2015-03-24 09:11:23 <jonasschnelli> hmmm...
 65 2015-03-24 09:11:33 <sipa> the wallet data can just be backed up in the cloud or so
 66 2015-03-24 09:11:42 <sipa> (encrypted of course)
 67 2015-03-24 09:12:15 <jonasschnelli> Currently lots of apps have/encourage users to write down the mnemonic code from the master seed...
 68 2015-03-24 09:12:23 <sipa> yeah
 69 2015-03-24 09:12:36 <jonasschnelli> how will this help in case of a full wallet lost (all stored transactions, all used addresses)
 70 2015-03-24 09:13:02 <sipa> well you can scan for transactions if the structure is known
 71 2015-03-24 09:13:28 <sipa> but it means you lose address book, accounting, comments, refund addresses, timestamps...
 72 2015-03-24 09:13:44 <sipa> if the absolute only thing you care about is getting the money back, it suffices
 73 2015-03-24 09:14:05 <jaromil> timestamps? aren't they in the blockchain?
 74 2015-03-24 09:14:43 <jonasschnelli> so in a recover mode you would scan all blocks transactions (starting at block 0 [or lets say after the "invention" of bip32]) after a possible key for / 44' / 0' / 0' / 0 / (0-100[lookahead size])?
 75 2015-03-24 09:14:48 <sipa> block timestamps
 76 2015-03-24 09:14:53 <jaromil> ok
 77 2015-03-24 09:14:53 <sipa> not transaction times
 78 2015-03-24 09:15:13 <sipa> jonasschnelli: yes
 79 2015-03-24 09:15:26 <jonasschnelli> okay. Got it. Thanks again sipa!
 80 2015-03-24 09:16:05 <sipa> jonasschnelli: hopefully you know some birthdate of your wallet or so
 81 2015-03-24 09:16:55 <jonasschnelli> sipa, yes. This would help as an additional input for a "rebuild/scan with master seed"... But it's just time and bandwith you save.
 82 2015-03-24 09:20:54 <jaromil> 
ACTION has a vision of internet cafe services in India for "rebuilding your wallet"

 83 2015-03-24 09:24:51 <phantomcircuit> <sipa> for many business uses, keeping the accounting may be more important than having access to the actual funds
 84 2015-03-24 09:25:09 <phantomcircuit> there's no reason for the private keys to be part of that accounting though
 85 2015-03-24 09:26:00 <jaromil> sipa: good work on #5941, honestly I'm surprised that it took so long for someone to come up with an "eclipse attack" on the p2p side
 86 2015-03-24 09:27:30 <jonasschnelli> That was really quick. When was the paper release March 20. Nice!
 87 2015-03-24 09:28:49 <jonasschnelli> sipa: i'm a right that there is currently no CKDpriv((kpar, cpar), i) or CKDpub((Kpar, cpar), i) implementation in bitcoind? Just the raw nChild uint?
 88 2015-03-24 09:31:50 <jonasschnelli> sipa, Nevermind. Wrong question. I just try to find out how "0xFFFFFFFE" related to m/0/2147483647H/1
 89 2015-03-24 09:32:29 <jonasschnelli> sipa, again. Nevermind. Found it out! :-)
 90 2015-03-24 09:41:41 <sipa> jonasschnelli: note that the paper mentions they were workong with developers :)
 91 2015-03-24 09:42:37 <sipa> phantomcircuit: yup, so the benefit of deterministic key generation is being able to split the secret and less secret part
 92 2015-03-24 09:42:50 <sipa> not really the ability to reconstruct from just the secret part
 93 2015-03-24 09:50:40 <phantomcircuit> sipa, right but being able to reconstruct from just the secret part is extremely valuable for things like tamper evidence devices
 94 2015-03-24 09:50:53 <phantomcircuit> it's relatively easy to construct stuff that suicides
 95 2015-03-24 09:51:12 <phantomcircuit> but much harder if backups are difficult
 96 2015-03-24 09:52:14 <sipa> good point
 97 2015-03-24 09:52:23 <sipa> yes, not disputing the use cases of that
 98 2015-03-24 12:22:04 <lclc> if a transactions has 0 fee and the coins aren't old enought nodes wont even relay it?
 99 2015-03-24 12:26:50 <wumpus> right
100 2015-03-24 12:27:08 <wumpus> that is an anti-DoS measure
101 2015-03-24 12:39:29 <rubensayshi> hmm, why does !fSendTrickle result in trickling for TX INVs? https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L4557
102 2015-03-24 13:07:37 <lclc> wumpus: but that's only the case when relaypriority is true right?
103 2015-03-24 13:07:56 <lclc> fLimitFree seems to be false by default at least
104 2015-03-24 13:35:09 <sipa> gavinandresen: unsure about mempool syncing we can get rid of resendwallettransactions; mempool syncing will not work when double-spends are involved, and there may (or imho, should) be per-host mempool size limitations
105 2015-03-24 13:35:30 <sipa> though i agree about speculative comments
106 2015-03-24 13:36:23 <gavinandresen> sipa: mmm.  But if I relay a wallet transaction to a peer and it doesn’t add it to its mempool or relay it because double-spend or mempool size… that’s the same, yes?
107 2015-03-24 13:36:24 <sipa> something like "Be aware this code implies that ..." is fine, but not "When feature X is implemented, we may perhaps potentially definitely consider the implications of Y on Z"
108 2015-03-24 13:37:43 <gavinandresen> (same as syncing mempools and having some transactions that don’t sync because doubl-spend or size limits....)
109 2015-03-24 13:38:03 <sipa> gavinandresen: i think the largest benefit from resend is actually because it rebroadcasts to potentially new peers (that have changed since the previous broadcast)
110 2015-03-24 13:38:22 <sipa> i guess if we do mempool syncing on new peers, the effect is likely the same
111 2015-03-24 13:38:32 <sipa> yeah, maybe it's not needed anymore
112 2015-03-24 13:38:37 <gavinandresen> yes, I imagined mempool syncing would be done right after version handshake....
113 2015-03-24 13:39:18 <gavinandresen> sipa: is somebody at blockstream working on mempool syncing? Or going to soon?
114 2015-03-24 13:39:22 <sipa> not afaik
115 2015-03-24 13:39:51 <wumpus> lclc: should be true from transactions received from the network
116 2015-03-24 13:39:58 <gavinandresen> I have a half-baked idea that probably won’t work that I should run by gmaxwell to increase privacy of transaction broadcasts....
117 2015-03-24 13:42:33 <sipa> gavinandresen: regarding the whole-tx decision whether to do script validation or not: there is a trivial way to make the lowlevel signature cache simpler and faster i think, by making the cache object local to CCachingTransactionSignatureChecker, rather than global
118 2015-03-24 13:43:11 <sipa> gavinandresen: which should equally prevent against the duplicate-invalid-signature attack, and doesn't need any locking or almost 0 code changes
119 2015-03-24 13:44:14 <gavinandresen> sipa: awesome! Have you or greg been benchmarking to see where the bottleneck is?  I haven’t.....
120 2015-03-24 13:44:19 <sipa> nope
121 2015-03-24 13:44:40 <sipa> i have been working on a block coding proposal, though, based on greg's idea
122 2015-03-24 13:45:14 <gavinandresen> sipa: interesting…  using IBLTs or polynomial encoding?
123 2015-03-24 13:45:23 <sipa> nope
124 2015-03-24 13:45:33 <sipa> though those can be plugged in to optimize it even more
125 2015-03-24 13:46:01 <sipa> i need to do some math about the expected transfer sizes and complexity of reconstruction
126 2015-03-24 13:46:20 <Koelle> sipa in Bitcoin 1+1=2
127 2015-03-24 13:46:28 <sipa> Koelle: ?
128 2015-03-24 13:46:30 <gavinandresen> CPU complexity of reconstruction seems like where things could get nasty
129 2015-03-24 13:46:48 <Koelle> as i say 1+2=2
130 2015-03-24 13:47:00 <gavinandresen> (or construction)   — from my reading the bandwidth-optimal encodings are O(n^3) CPU or something
131 2015-03-24 13:47:01 <Koelle> s/= /=
132 2015-03-24 13:47:36 <sipa> gavinandresen: the basic idea is to first (very compactly) announce which transactions you're going to use, with a constant overhead of a few bytes per tx
133 2015-03-24 13:47:58 <sipa> gavinandresen: and then use standard error-correction code like reed-solomon to encode expected misses
134 2015-03-24 13:48:04 <sipa> all of which is linear
135 2015-03-24 13:48:52 <sipa> Koelle: ?
136 2015-03-24 13:49:22 <gavinandresen> sipa: so once that is done… THEN can we increase max block size? :)
137 2015-03-24 13:49:22 <Koelle> its Math
138 2015-03-24 13:49:41 <sipa> gavinandresen: not going to comment anymore
139 2015-03-24 14:26:44 <Koelle> floood
140 2015-03-24 14:27:38 <sipa> Koelle: are you going to say something meaningful?
141 2015-03-24 15:08:19 <gdm85> what is the current take of bitcoin wallet application developers on TBIP0075? I've been trying to follow the mailing list discussion but it's large.. :)
142 2015-03-24 15:26:29 <sipa> what is tbip75?
143 2015-03-24 15:26:58 <sipa> please don't use numbers for things that don't have a number yet
144 2015-03-24 15:27:16 <sipa> it just leads to confusion afterwards
145 2015-03-24 15:31:40 <justanotheruser> well they could hash their bip and use that as the number :)
146 2015-03-24 15:32:49 <gdm85> sipa: https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
147 2015-03-24 15:33:26 <gdm85> as I understand this developer proposes it, so it puts a "T" in front of BIP? I am not familiar with the process..
148 2015-03-24 15:33:32 <gdm85> s/it/he/
149 2015-03-24 15:33:37 <gmaxwell> gdm85: As a matter of poilcy I will _never_ assign a squatted number, as it seems to be the only lever I have to get people to stop doing that, so you can be sure that proposal will never get the number 75.
150 2015-03-24 15:34:59 <gmaxwell> gdm85: what I've asked people to do is call pre-numbered proposals is to call them e.g. name-subject e.g.   bip-smith-newscript.
151 2015-03-24 15:35:03 <gdm85> gmaxwell: wasn't aware this was being squatted :) but yeah, I understand. he could also not have specified a number.
152 2015-03-24 15:35:07 <gdm85> yes precisely
153 2015-03-24 15:35:59 <gmaxwell> we've had a couple instances where people freaked out when a number was assigned because they were already implenting something else  using that number. :( talk about stupid problems to deal with.
154 2015-03-24 15:41:19 <gdm85> it's being referred as TBIP0075 here (by himself): https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
155 2015-03-24 15:45:36 <gdm85> the idea is interesting, although one could argue if it needs to be implemented only for the specific bluetooth link.
156 2015-03-24 15:46:30 <gdm85> I think it could work also with NFC's NDEF packets alone.
157 2015-03-24 16:09:00 <Luke-Jr> sigh, finished a reindex and it's already "corrupt"; seems 0.10 is not able to keep a reliable chainstate :/
158 2015-03-24 16:12:13 <justanotheruser> Luke-Jr: are you stressing the node in a way that makes it so it can't?
159 2015-03-24 16:12:40 <Luke-Jr> justanotheruser: nope, just my normal desktop PC. haven't even had a crash or reboot
160 2015-03-24 16:16:29 <gmaxwell> Luke-Jr: there is a specific reindexing bug thats already fixed in 0.10-branch
161 2015-03-24 16:17:26 <Luke-Jr> hm
162 2015-03-24 16:18:04 <gmaxwell> Luke-Jr: reindexing would overwrite blocks when blocks were out of order. :(
163 2015-03-24 16:20:22 <Luke-Jr> >_<
164 2015-03-24 16:21:55 <Luke-Jr> after merging that, am I better off with just an IBD then?
165 2015-03-24 16:38:37 <ajweiss> it should deal with it ok, but there will be some wasted space/junk in the block files.  truth be told, i'd IBD
166 2015-03-24 16:48:08 <Luke-Jr> torrent says my blk0001.dat hardlink is intact at least >_<
167 2015-03-24 16:48:46 <Luke-Jr> not that 2 GB makes a big difference these days
168 2015-03-24 16:49:22 <jtimon> ping #5681
169 2015-03-24 17:16:54 <jtimon> github says 5696 needs rebase but that doesn't seem true since I just rebased it to origin/master just fine...what should I do?
170 2015-03-24 17:17:34 <sipa> is origin = bitcoin/bitcoin ?
171 2015-03-24 17:21:31 <jtimon> never mind, it does need rebase now
172 2015-03-24 17:21:50 <ajweiss> so i pulled all the banscore stuff from main/net and stuck it in a module (really just to play with peeling stuff out).  it adds some lines but shrinks main/net a little.  worth PRing?
173 2015-03-24 17:21:58 <jtimon> but yep, origin was bitcoin/bitcoin
174 2015-03-24 17:22:21 <jtimon> in case you have general advice for the next time it happens
175 2015-03-24 17:22:38 <lechuga_> responding to lastlog but is explicit mempool syncing something already agreed to be desirable?
176 2015-03-24 17:22:59 <sipa> lechuga_: needs a lot of thinking at least i thnk
177 2015-03-24 17:23:20 <lechuga_> is the motivation faster block relays
178 2015-03-24 17:23:49 <sipa> lechuga_: i think that mempool syncing + some expiration mechanism is better than what we have now
179 2015-03-24 17:24:01 <sipa> where now just somehow kinda works but without really understanding why
180 2015-03-24 17:24:08 <lechuga_> ic
181 2015-03-24 17:44:30 <dhill> issuing a mempool after version?
182 2015-03-24 17:44:52 <sipa> dhill: sure, that's the easy part
183 2015-03-24 17:45:05 <sipa> dhill: making transactions not live forever is the hard part :)
184 2015-03-24 17:45:17 <dhill> right
185 2015-03-24 17:46:11 <dhill> you'll expire a tx and receive it again on next peer connect :)
186 2015-03-24 17:46:56 <sipa> yes, currently there is this weak and hard to rely upon but in practice functioning mechanism of transaction expiring simply by virtue of nodes being restarted
187 2015-03-24 17:47:09 <sipa> if you add mempool sync, occasionally restarts don't have that effect anymore
188 2015-03-24 18:45:14 <gmaxwell> dhill: discussions around other expiration policies run into issues with if there is a strong universal expiry policy that it becomes something attractive to attack. E.g. make an intentionally very low priority payment for some zero conf thing, and then when it expires race retransmission with a malicious double spend.  Even ignoring the lack of wisdom in depending on a zero conf payment to go throug
189 2015-03-24 18:45:20 <gmaxwell> h, that kind of pattern would actively award attacking the network, which isn't great.
190 2015-03-24 18:46:40 <gmaxwell> (but maybe just an expiration policy with a randomized boundary is enough to avoid incentivizing the abusive behavior;  I don't think anyone has a clear vision of all the considerations here.)
191 2015-03-24 18:49:28 <lechuga_> how would something like this play with IsNotorious
192 2015-03-24 18:49:55 <lechuga_> or other conflicting policy
193 2015-03-24 18:50:02 <Luke-Jr> "conflicting policy"?
194 2015-03-24 18:50:17 <gmaxwell> lechuga_: I'm not sure I follow the question.
195 2015-03-24 18:50:21 <lechuga_> conflicting with respect to mirrored state across mempool nodes
196 2015-03-24 18:50:38 <gmaxwell> lechuga_: perhaps define "this"?
197 2015-03-24 18:50:45 <gmaxwell> (I'm not sure which this you're referring to)
198 2015-03-24 18:50:49 <lechuga_> explicitly synced mempool
199 2015-03-24 18:51:04 <lechuga_> whatever mechanism enforces that
200 2015-03-24 18:51:10 <gmaxwell> oh you mean for propagation purposes? I don't actually think using the mempool for that necessarily makes much sense.
201 2015-03-24 18:51:32 <gmaxwell> (and, you may note, that e.g. the relay network client doesn't expect to use the mempool for its optimization)
202 2015-03-24 18:51:56 <Luke-Jr> it's not reasonable to assume mempools are mirrored
203 2015-03-24 18:51:58 <gmaxwell> lechuga_: e.g. you'd never have a double spend in your mempool, but for block relaying optimization you'd potentially want to know about a doublespend.
204 2015-03-24 18:52:31 <lechuga_> i guess im not clear on what the definition would be of an explicitly synced mempool then
205 2015-03-24 18:52:52 <lechuga_> i interpreted it to mean ideally every node has an indentical tx set in their mempools
206 2015-03-24 18:53:21 <sipa> lechuga_: if we could do that, we would not need a blockchain
207 2015-03-24 18:54:19 <sipa> it just means active operation with the intention of reducing the differences between nodes, i guess
208 2015-03-24 18:54:23 <lechuga_> so an explicit sync in this case just means "ive told all of my peers about every mempool tx i know about and they;ve told me about all of theirs"
209 2015-03-24 18:54:34 <gmaxwell> Yes, I don't think that makes sense, the blockchain exists to synchronize nodes. Some people have talked about doing this to reduce mempool inconsistency further (e.g. sucking a peers mempool state at startup); which is probably fine except that it would break the only expiration mechenism we have now.
210 2015-03-24 18:54:55 <lechuga_> ic
211 2015-03-24 18:54:57 <sipa> like asking at startup what your peer's mempool is on statrtup
212 2015-03-24 18:55:09 <lechuga_> ok im clear now
213 2015-03-24 18:55:11 <lechuga_> ty
214 2015-03-24 18:55:57 <dhill> you'd only want to send a mempool request to a new peer if they were at your height or higher?
215 2015-03-24 18:56:38 <lechuga_> i think refering to it as a mempool sync is what threw me
216 2015-03-24 18:56:53 <lechuga_> its really a mutual complete advertisement
217 2015-03-24 18:56:55 <lechuga_> (maybe)
218 2015-03-24 18:57:42 <sipa> dhill: right
219 2015-03-24 18:59:40 <denisx> I disclosed the stratumcode exploit: https://bitcointalk.org/index.php?topic=1001603
220 2015-03-24 19:00:18 <helo> some kind of parameter-driven expiration policy to put the node operator "at the wheel" seems like a not-bad idea
221 2015-03-24 19:01:54 <gmaxwell> helo: operators at the wheel seems to be almost completely not working.
222 2015-03-24 19:02:44 <helo> the operators are at the wheel, there just is no wheel so they're blind as to their expiration policy
223 2015-03-24 19:03:31 <gmaxwell> I'm not opposed to more knobs (we already have some) but they've also been a complete failure in terms of usefully empowering users.
224 2015-03-24 19:03:59 <lechuga_> presumably you'd also want sensible defaults
225 2015-03-24 19:04:05 <helo> most users wouldn't know what choices are better or worse for their interests, so defaults are left untouched
226 2015-03-24 19:04:35 <helo> some discussion and rationale for a concrete mechanism would help those that may know/care
227 2015-03-24 19:09:49 <cfields> sipa: i have the wallet encryption replacement (drops openssl) nearly review-ready. What would you think about me taking your aes class as part of that independent of your fortuna work? It exercises+tests the aes code pretty well.
228 2015-03-24 19:10:39 <sipa> cfields: go ahead
229 2015-03-24 19:10:59 <sipa> cfields: i expect that significant refactors will be needed for fortuna
230 2015-03-24 19:11:12 <sipa> but the crypto part is independently useful
231 2015-03-24 19:12:17 <cfields> agreed, thanks
232 2015-03-24 19:33:10 <dgenr8> sipa: you don't like expiring from mempool based on locktime, and as a more aggressive fallback, on receive time?
233 2015-03-24 19:38:44 <gmaxwell> locktime?!?
234 2015-03-24 19:46:26 <sipa> dgenr8: receive time doesn't work, as it will increase across retransmits
235 2015-03-24 19:46:35 <sipa> not sure what you mean by locktime
236 2015-03-24 19:57:01 <helo> do any class transactions need to persist after a node reboot?
237 2015-03-24 20:03:25 <helo> it is clearly important to keep low fee transactions around in most mempools long enough to prevent cheap network abuse
238 2015-03-24 20:20:01 <Luke-Jr> helo: or some way to avoid the network abuse other than that..
239 2015-03-24 20:20:36 <Luke-Jr> in theory, it may be possible for non-miners to merely flag UTXOs they've seen spent, and not keep a mempool at all more than a minute or so long
240 2015-03-24 20:25:49 <helo> is the utxo set not too slow to do lookups on, compared to mempool? i.e. mempool acting as a cache of utxo activity
241 2015-03-24 20:28:31 <familiar> Question related to UI of a multisig transaction. I am trying to design an Electrum plugin for multisig, with the main objective being "noob" usability without losing much in security
242 2015-03-24 20:29:01 <familiar> In my model there is a buyer, an arbiter and a vendor. The buyer is putting his money into multisig ("escrow") and at a later point releasing the funds to the vendor
243 2015-03-24 20:29:12 <familiar> The arbiter is there to resolve any disputes that might occur
244 2015-03-24 20:30:18 <shesek> familiar, the main thing you'll have to resolve is how the peers communicate with each-other
245 2015-03-24 20:30:31 <familiar> Suppose now that you are one of the three parties, and you receive a raw transaction to sign. This transaction moves funds from the multisig to an arbitrary output address. How would you be able to determine if this address belongs to the arbiter or the vendor (in this example you are the buyer)
246 2015-03-24 20:30:49 <shesek> you'll need to start by collecting public keys from all the participants, and ideally also have the involved parties co-sign a contract
247 2015-03-24 20:31:14 <familiar> shesek: Correct, the public keys will be available in some verified location, or communicated directly
248 2015-03-24 20:31:18 <shesek> the contract could specify the addresses each party wants to receive his funds at, once they're out of the multisig
249 2015-03-24 20:31:24 <familiar> What's a "contract" in this context?
250 2015-03-24 20:31:59 <shesek> later, when they want to co-sign a transaction and spend it, they'll need to collect the signatures, create the finalized transaction, and broadcast it
251 2015-03-24 20:32:21 <shesek> familiar, it could be anything, really. an agreement between the parties to the transaction
252 2015-03-24 20:32:52 <familiar> Is there a standard for such a cryptographic contract, or are you suggesting that they use the pubkeys corresponding to their anticipated output addresses for the redeem script?
253 2015-03-24 20:33:00 <shesek> it probably should contain contact information, Bitcoin addresses, PGP keys, description of the item/service being provided, shipping addresses when relevant, and all other relevant terms
254 2015-03-24 20:34:16 <shesek> nothing standard, really. OpenBazaar are using Ricardian contracts and Bitrated uses its own JSON-based custom format
255 2015-03-24 20:34:37 <shesek> you can check out the Bitrated v1 source code to see how an implementation for that might look like
256 2015-03-24 20:34:42 <familiar> I see
257 2015-03-24 20:34:56 <familiar> And it's not tied to the 3xxx address or the funding transaction in any way?
258 2015-03-24 20:35:18 <familiar> (in either implementation)
259 2015-03-24 20:35:18 <shesek> it uses the server and a websocket to enable communication between the parties, all of which is encrypted end-to-end
260 2015-03-24 20:35:46 <shesek> and unique URLs with information stored in their hash to allow users to exchange data
261 2015-03-24 20:36:02 <shesek> well, it could include (or be signed by) the multi-signature public keys
262 2015-03-24 20:36:15 <familiar> Are you related to Bitrated in any way?
263 2015-03-24 20:36:16 <shesek> from which you can recover the p2sh address, and find any unspent outputs
264 2015-03-24 20:36:23 <shesek> yes, I'm the founder
265 2015-03-24 20:36:26 <familiar> got it
266 2015-03-24 20:36:40 <familiar> That's very cool. I can see you spent time thinking this through
267 2015-03-24 20:36:48 <familiar> (proof of work)
268 2015-03-24 20:37:08 <shesek> if you're interested in what OpenBazaar are using, you can read more at https://gist.github.com/drwasho/a5380544c170bdbbbad8 and https://github.com/OpenBazaar/OpenBazaar/wiki/Contracts-anda-Listings
269 2015-03-24 20:38:02 <shesek> it has some redundancies that I dislike, but Bitrated is probably going to switch to something similar
270 2015-03-24 20:38:19 <familiar> Is this likely to become a BIP at some point ?
271 2015-03-24 20:39:08 <shesek> I think that's outside the scope of Bitcoin itself
272 2015-03-24 20:39:48 <shesek> a standardized contract format is useful even without cryptocurrencies
273 2015-03-24 20:40:36 <familiar> I suppose. Signing it with the same sigs as the 3xx script seems like a good idea. Anything funky that might happen there I should look out for?
274 2015-03-24 20:40:45 <familiar> same *pubkeys - that is
275 2015-03-24 20:41:03 <belcher> you get a different p2sh address depending on the order you put the pubkeys in
276 2015-03-24 20:41:13 <belcher> so come up with an ordering mechanism and stick with it
277 2015-03-24 20:41:28 <belcher> shesek how does bitrated deal with that? order alphabetically maybe?
278 2015-03-24 20:42:15 <familiar> lexicographic works for me
279 2015-03-24 20:42:18 <familiar> as specified in BIP45
280 2015-03-24 20:44:33 <familiar> belcher: yeah exactly, alphabetically
281 2015-03-24 20:44:45 <belcher> didnt know about that bip
282 2015-03-24 20:45:01 <belcher> sounds good, are you coding anything cool familiar ?
283 2015-03-24 20:45:14 <familiar> Just an Electrum plugin
284 2015-03-24 20:45:30 <familiar> I'm a little pissed with the implementation of multisig in Electrum 2.0
285 2015-03-24 20:45:34 <familiar> it's too much of a hassle
286 2015-03-24 20:45:45 <familiar> (haha ThomasV just left when I joined)
287 2015-03-24 20:46:13 <belcher> in what way is it a hassle ?
288 2015-03-24 20:46:17 <belcher> wondering
289 2015-03-24 20:47:16 <familiar> every pairing of customer,arbiter,vendor needs to have their own "wallet" which is a .dat file with a bunch of json in it. Electrum gets this file as input when it starts up, and only uses that file for manipulating accounts and addresses (in case you are unfamiliar with electrum)
290 2015-03-24 20:47:38 <familiar> So handling multiple tuples of (C,A,V) means multiple instances of electrum, multiple DAT files, big mess
291 2015-03-24 20:49:41 <belcher> oh yes, true
292 2015-03-24 20:50:00 <belcher> yeah its not really suited to a customer finding a vendor+arbitrator and immediately making a purchase
293 2015-03-24 20:50:30 <belcher> or a vendor working through many customer's accounts to retrieve payment
294 2015-03-24 20:50:54 <belcher> best of luck, let me know if you need a tester or anything
295 2015-03-24 20:51:31 <dgenr8> gmaxwell: some offset after locktime.  surely you thought I was proposing something ridiculous though ;D
296 2015-03-24 20:52:10 <dgenr8> sipa: working across a much later retransmit would be a pretty tough goal.
297 2015-03-24 20:54:07 <familiar> Thanks belcher
298 2015-03-24 20:58:24 <dgenr8> is there any way mempool expiration doesn't mean saying "after expiration, try paying miners, or make a new transaction"
299 2015-03-24 20:58:28 <dgenr8> ?
300 2015-03-24 20:59:26 <helo> probably not
301 2015-03-24 20:59:51 <helo> i think it is in the network's best interest for the sender to not know precisely when they can retransmit
302 2015-03-24 21:00:04 <sipa> well that would require network nodes to keep a pertual list of expired transactions ids they shouldn't accept anymore
303 2015-03-24 21:00:22 <sipa> no?
304 2015-03-24 21:02:55 <gavinandresen> sipa: could probably do a bloom filter instead of a list, and don’t relay stuff in the bloom filter. Or two bloom filters, staggered in time, periodically swap and empty.  Randomized per node, with a false positive low enough not to impact relaying
305 2015-03-24 21:03:40 <sipa> gavinandresen: or just have some memory limit on the mempool, and more or less arbitrarily delete stuff :)
306 2015-03-24 21:03:50 <gavinandresen> or that, yeah.....
307 2015-03-24 21:04:20 <sipa> i don't think we need any assurances regarding mempool transactions
308 2015-03-24 21:04:23 <gavinandresen> (where “arbitrary” is “be more likely to keep the high fee or high priority stuff”)
309 2015-03-24 21:04:26 <dgenr8> you can't remember forever, but you'd have to remember for a significant time after expire time.
310 2015-03-24 21:04:27 <helo> it's probably good not to encourage the "fee gaming" that well defined retransmission times would permit
311 2015-03-24 21:04:41 <sipa> the problem we're trying to avoid is transactions living forever
312 2015-03-24 21:04:57 <sipa> (and i guess the related but not identical problem of unbounded mempool size)
313 2015-03-24 21:05:14 <dgenr8> oh i though mempool size was the primary discussion
314 2015-03-24 21:05:38 <dgenr8> if we could make txes die, we could make addresses die too
315 2015-03-24 21:05:56 <sipa> hehe
316 2015-03-24 21:08:22 <dgenr8> could aiming toward mandatory locktime ever work?
317 2015-03-24 21:08:36 <sipa> what does that mean?
318 2015-03-24 21:08:46 <dgenr8> eventually require locktime on all txes
319 2015-03-24 21:08:59 <sipa> that's a trivial softfork, but what does it gain?
320 2015-03-24 21:09:11 <sipa> i could just set it ages in the past
321 2015-03-24 21:09:12 <dgenr8> expiring on that is easy, because it's in the tx
322 2015-03-24 21:09:32 <dgenr8> expiring 144 blocks AFTER that rather (or whatever #)
323 2015-03-24 21:10:01 <sipa> you can make that into a policy rule, but not into a consensus rule
324 2015-03-24 21:10:58 <dgenr8> why not?
325 2015-03-24 21:11:17 <Luke-Jr> tx expiry is a policy thing anyway
326 2015-03-24 21:11:26 <sipa> dgenr8: breaks fungibility around the expiration period
327 2015-03-24 21:11:53 <sipa> you can't depend on the output of a transaction close to being expired (even when it's already in the chain)
328 2015-03-24 21:12:12 <sipa> as a non-malicious reorg can push it past its validity, along with all its dependencies
329 2015-03-24 21:12:29 <dgenr8> couldn't i author with locktime = currentheight - 50 to avoid that?
330 2015-03-24 21:12:31 <sipa> it's the same reason why coinbase outputs have a maturity (though 101 blocks is probably way overkill)
331 2015-03-24 21:12:52 <sipa> dgenr8: now it gets mined at currentheight - 50 + 144, and you have the same problem
332 2015-03-24 21:14:10 <dgenr8> there are a lot of chances to confirm before that
333 2015-03-24 21:14:21 <sipa> yes
334 2015-03-24 21:14:31 <sipa> so?
335 2015-03-24 21:14:57 <helo> seems like overkill to make a policy change to do what happens naturally
336 2015-03-24 21:15:22 <helo> forgetting "randomly" would work
337 2015-03-24 21:15:26 <sipa> dgenr8: the problem is that if it should happen that such a transaction is mined closed to its expiration point, wallets need a lot of extra complexity in avoiding its outputs, as they are less 'certain' to remain in place
338 2015-03-24 21:16:03 <dgenr8> ok i'll ponder that
339 2015-03-24 21:16:16 <sipa> i agree: the mempool is and should stay policy
340 2015-03-24 21:17:00 <sipa> trying to encode mempool validity rules into the consensus rules may lock us into some suboptimal practice, or gameable result
341 2015-03-24 21:23:11 <helo> all i can think of is that ideally you don't forget a transaction that will likely be mined, to avoid having to receive and validate it again
342 2015-03-24 21:23:36 <gmaxwell> dgenr8: no worries, some offset after locktime is also ridiculous.
343 2015-03-24 21:24:03 <sipa> i like the idea that ultimately the receiver is responsible for getting the transaction confirmed
344 2015-03-24 21:24:18 <sipa> and not the network
345 2015-03-24 21:24:54 <sipa> especially if the mempool size becomes controlled by resource limitations, it's hard to predict what the actual behaviour of the network will become
346 2015-03-24 21:28:46 <dgenr8> some checks say "not valid after"... i wonder how well that actually works
347 2015-03-24 21:29:04 <dgenr8> gmaxwell: why?
348 2015-03-24 21:35:48 <helo> i think i like luke's idea of using not-mempool to prevent network abuse. it seems incorrect to prevent mempool bloat by filling it with bloaty low-fee possibly not-ever-confirming transactions.
349 2015-03-24 21:37:49 <helo> so mempool is just used to cache transactions that are probably going to be in an upcoming block for some time in the order of the block's confirmation time
350 2015-03-24 21:48:06 <dgenr8> sipa: the network still has to deliver it to the receiver
351 2015-03-24 21:49:03 <helo> dgenr8: no, the sender and receiver are presumably already in direct communication using some other mechanism
352 2015-03-24 21:49:16 <helo> the tx can be sent to the receiver via that
353 2015-03-24 21:50:53 <helo> but the network is what the receiver will use to try to get the tx mined, so the problem still exists regardless of whose responsibility it is
354 2015-03-24 21:51:48 <helo> i suppose miners could all publish IPs that transactions can be submitted directly to
355 2015-03-24 21:52:20 <helo> with mostly just blocks being relayed by miners on the public network
356 2015-03-24 21:55:49 <dgenr8> "the bitcoin network" is frequently spoken of as a thing you send txes to, and a thing that confirms them
357 2015-03-24 21:56:06 <dgenr8> today, it is both those things.  other realities are mentioned but don't exist, yet anyway
358 2015-03-24 21:59:50 <gmaxwell> dgenr8: they do exist, there are alternative transport networks.
359 2015-03-24 22:00:11 <gmaxwell> (e.g. the blockchain over freenet and matt's relaynetwork protocol)
360 2015-03-24 22:15:00 <sipa> dgenr8: i would say the p2p net currently performs 4 different functions (1) block propagation (2) transactions to miners (3) transactions from sender to receiver (with the pp as alternative) (4) historical block fetching (with bittorrent as alternative)
361 2015-03-24 22:15:13 <sipa> (1) has matt's relay network as alternative
362 2015-03-24 22:22:32 <dgenr8> (1), and the distinction between (2) and (3), are white-box descriptions. i agree (4) is another function.
363 2015-03-24 22:22:35 <dgenr8> so txes are black-box I/O; blocks are output-only
364 2015-03-24 22:25:05 <dgenr8> interesting... if txes expired on locktime, an address containing CHECKLOCKTIMEVERIFY actually couldn't be re-used after that tx's expiration
365 2015-03-24 22:26:36 <sipa> dgenr8: i consider 2 and 3 to be very distinct; 2 is 1-to-many but can be slow; 3 is 1-to-1 but must be fast
366 2015-03-24 22:26:59 <sipa> and i think it has been a very big mistake to use the p2p network for 3
367 2015-03-24 22:27:49 <dgenr8> maybe, but even if i use pp, i want to see it in the network
368 2015-03-24 22:27:51 <sipa> (1) has latency requirements
369 2015-03-24 22:28:03 <sipa> i don't
370 2015-03-24 22:28:18 <sipa> that's a totally unnecessary privacy leak
371 2015-03-24 22:28:33 <dgenr8> you don't? not even a little?
372 2015-03-24 22:28:54 <sipa> the receiver can broadcast the transaction when he agrees with the payment
373 2015-03-24 22:48:42 <dgenr8> s/that tx's expiration/the expiration implied by the script/
374 2015-03-24 22:49:17 <sipa> cltv cannot imply expiration, by design
375 2015-03-24 22:49:30 <sipa> for exactly the reason i explained already
376 2015-03-24 22:51:24 <sipa> oh, you mean combined with your locktime-based expiration
377 2015-03-24 22:52:30 <sipa> and 'address reuse' is not really the right term; the problem is key reuse really, or anything part of a script that can be used as identity
378 2015-03-24 22:53:17 <sipa> and a script with cltv may not be reusable, but you can just change the tikestamp in thenscript, and you have the same privacy problem of linkable acriprs
379 2015-03-24 22:53:22 <sipa> scripts
380 2015-03-24 22:56:48 <sipa> timestamp
381 2015-03-24 22:56:52 <sipa> in the script
382 2015-03-24 22:58:29 <dgenr8> oh right, cltv does not restrict locktime-cltvtime gap.  it could be reused and that gap would just be bigger next time
383 2015-03-24 23:01:32 <sipa> cltv just constrains the locktime value
384 2015-03-24 23:01:41 <dgenr8> in one direction
385 2015-03-24 23:01:44 <sipa> it doesn't even affect tx validity directly
386 2015-03-24 23:02:02 <dgenr8> right ... i was going off on the hypothetical as you say
387 2015-03-24 23:02:26 <sipa> well, yes, but even if it wasn't, the effect on actual validity would still be one-directional as that is how locktime iself works
388 2015-03-24 23:03:15 <gmaxwell> the only reason cltv is one sided is so that you don't get into weird mutual exclusions when combining multiple locktimes.
389 2015-03-24 23:06:04 <dgenr8> i guess what i was envisioning was a script (not a UTXO) with an explicit expiration time...
390 2015-03-24 23:07:21 <gmaxwell> (or at least get fewer weird mutual-exclusions)
391 2015-03-24 23:08:22 <sipa> dgenr8: avoiding that is sort of an explicit design goal
392 2015-03-24 23:11:40 <dgenr8> right... "pay whenever" is needed.  but maybe optionally, and it could be visible in the address.
393 2015-03-24 23:15:34 <sipa> dgenr8: as i said, it breaks fungibility of the output coins of the transaction spending it
394 2015-03-24 23:15:53 <sipa> where it is not optional or visible
395 2015-03-24 23:17:21 <sipa> well, breaks is an exaggeration, but it does reduce it
396 2015-03-24 23:17:38 <dgenr8> transaction spending what? you couldn't even pay to an expired address
397 2015-03-24 23:21:26 <dgenr8> 1000 bits to 1HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349094 please
398 2015-03-24 23:23:05 <dgenr8> and it would actually be possible to prevent re-use up to the expire time, if it weren't too far off
399 2015-03-24 23:37:30 <Luke-Jr> dgenr8: then blcok 349094 comes after you pay that, and it hasn't confirmed. now what?
400 2015-03-24 23:38:07 <dgenr8> time for a new address I guess
401 2015-03-24 23:43:23 <Luke-Jr> dgenr8: too late, you already sent it to the first address
402 2015-03-24 23:43:37 <Luke-Jr> I don't want to have to send it again. I sent it the first time.
403 2015-03-24 23:52:22 <dgenr8> you shouldn't have left your browser open for 6 hours before clicking pay