1 2014-12-21 00:45:25 <kanzure> jonasschnelli: i'm just nitpicking here, but your branch has extra stray whitespace
  2 2014-12-21 00:46:44 <gmaxwell> if you adjust your git settings you can make git diff colorized and it will show addition of stray whitespace.
  3 2014-12-21 00:50:16 <kanzure> // remove signature if we used the signing only for the fee calculation
  4 2014-12-21 01:30:25 <kanzure> "for example, when specifying the the path of the dependency" doc/build* somewhere
  5 2014-12-21 03:12:35 <kanzure> so i am adding watchonly support to jonasschnelli's fundrawtransaction branch
  6 2014-12-21 03:12:39 <kanzure> so far transactions are looking correct
  7 2014-12-21 03:13:10 <kanzure> with the exception of fees. apparently CreateTransaction uses SignSignature to calculate fees?
  8 2014-12-21 03:14:17 <phantomcircuit> kanzure, you need to sign the transaction to get the ultimate length of the transaction for calculating the fees
  9 2014-12-21 03:14:34 <phantomcircuit> that probably should be replaced with an estimation function but well that's more complex
 10 2014-12-21 03:14:51 <phantomcircuit> (potentially more complex, it should actually end up being simpler...)
 11 2014-12-21 03:15:07 <kanzure> right.. so.. i think that technically this "should" probably still sign, because CreateTransaction is probably used to create signed transactions anyway
 12 2014-12-21 03:15:45 <kanzure> so i should not disable SignSignature when a watchonly input is present, but i should definitely skip attempting to sign a watchonly, and i should attempt to make fee calculation still happen?
 13 2014-12-21 03:16:20 <phantomcircuit> kanzure, maybe you get to change the fee estimation code to estimate the length of the signatures :/
 14 2014-12-21 03:17:10 <kanzure> my primary concern is about making the behavior of CreateTransaction more convoluted
 15 2014-12-21 03:17:32 <kanzure> as a secondary concern the transaction fee can be calculated another way (the user calling "fundrawtransaction" can just create another output with the amount he thinks is okay, and then deletes that output before signing)
 16 2014-12-21 03:18:21 <kanzure> er, i mean, i am attempting to not make CreateTransaction more convoluted ("when watchonly is enabled, no signatures happen" would definitely violate principle of least surprise)
 17 2014-12-21 03:21:15 <phantomcircuit> kanzure, right which is why im suggesting you change the fee code (in  separate pr) to estimate the signature lengths
 18 2014-12-21 03:25:47 <kanzure> i wonder if fundrawtransaction should also fund fees on an otherwise fully-funded transaction
 19 2014-12-21 03:35:14 <Luke-Jr> kanzure: that's a good idea
 20 2014-12-21 03:37:05 <phantomcircuit> sipa, any opinion on changing the fee estimation stuff around signature lengths?
 21 2014-12-21 03:37:16 <phantomcircuit> afaict there isn't a strong reason for actually signing
 22 2014-12-21 03:37:26 <phantomcircuit> you'll just be off by a few bytes
 23 2014-12-21 03:40:40 <Luke-Jr> phantomcircuit: I am not sipa, but I doubt anyone would object to estimating the signature sizes there.
 24 2014-12-21 03:44:32 <BlueMatt> spend hours tweaking things to get memory usage <3gb for travis.....they launch a new intrastructure w/ 4gb memory available....http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/
 25 2014-12-21 03:50:03 <phantomcircuit> http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/
 26 2014-12-21 03:50:15 <phantomcircuit> grumble grumble unclocikable links grumble
 27 2014-12-21 04:07:08 <kanzure> GetMinimumFee is returning 199 on my 199 BTC watchonly transaction :|
 28 2014-12-21 04:07:22 <Luke-Jr> 199 BTC or 199 amount?
 29 2014-12-21 04:07:41 <kanzure> nFeeNeeded is 199
 30 2014-12-21 04:07:50 <kanzure> nFeeRet gets set to nFeeNeeded
 31 2014-12-21 04:16:47 <kanzure> hmm it's because nFeeNeeded = minTxFee.GetFee(nTxBytes)
 32 2014-12-21 04:18:30 <kanzure> ah nevermind. i suppose things are working as anticipated (and the fee was 119 satoshi, not 199 BTC nor 199 satoshi).
 33 2014-12-21 04:18:31 <Luke-Jr> kanzure: are you sure it's wrong?
 34 2014-12-21 04:18:41 <Luke-Jr> ;)
 35 2014-12-21 04:19:06 <gmaxwell> kanzure: yea, createtransaction shouldn't do that, thats moronic. :P
 36 2014-12-21 04:20:04 <kanzure> also what's the naming convention on CreateTransaction params? enableWatchOnly, allowWatchOnly, useWatchOnly, alsoUseWatchOnly...?
 37 2014-12-21 04:20:14 <gmaxwell> though it's a little tricky for watching, since you don't actually know the scriptpubkey details. :(
 38 2014-12-21 04:20:59 <kanzure> "useWatchOnly" is ambiguous (even if watchonly is a known feature...)
 39 2014-12-21 04:21:03 <gmaxwell> What it should just be doing is looking wat the pubkey and from that deciding the maximum size of the signature and using that. Unfortunately for a watching you can only make a guess.
 40 2014-12-21 04:21:13 <gmaxwell> kanzure: includewatching
 41 2014-12-21 04:21:14 <gmaxwell> ?
 42 2014-12-21 04:21:42 <kanzure> includeWatching to match other naming mistakes, and you have a deal
 43 2014-12-21 05:18:42 <phantomcircuit> gmaxwell, the maximum size is only going to be off by what... 1 byte per signature from the average?
 44 2014-12-21 05:18:51 <phantomcircuit> actually maybe less?
 45 2014-12-21 05:19:38 <gmaxwell> phantomcircuit: the probablity of small sizes falls off exponentially... in theory you could have an 8 byte signature, but thats very very unlikely.
 46 2014-12-21 05:20:11 <gmaxwell> e.g. 1/256 are at least one byte shorter, 1/65536 are at least two bytes shorter, etc.
 47 2014-12-21 05:21:08 <phantomcircuit> so using the maximum size on average wont be an expensive decision, but might at random cost something
 48 2014-12-21 05:21:14 <phantomcircuit> seems reasonable
 49 2014-12-21 05:22:18 <phantomcircuit> i feel like this has been discussed before...
 50 2014-12-21 05:24:06 <gmaxwell> it's very unlikely to be an overestimate by more than a couple bytes.
 51 2014-12-21 05:24:24 <gmaxwell> but this isn't so easy for eaching wallets as you don't know if the pubkey is compressed / what the redeemscript is.
 52 2014-12-21 05:24:32 <gmaxwell> er watching*
 53 2014-12-21 05:25:15 <phantomcircuit> are there watch only things which aren't just pubkeyhash ?
 54 2014-12-21 05:25:42 <gmaxwell> IIRC you can watch any address you like.
 55 2014-12-21 05:25:50 <gmaxwell> probably the thing to do is just assume that all 1* are compressed, and its your own problem if you use it with an uncompressed key (why?!) ... multisig is harder.
 56 2014-12-21 05:26:15 <gmaxwell> assuming everyhing is 20 of 20 would be super wasteful, but assuming that things are 2 of 3 would result in big problems for 20 of 20.
 57 2014-12-21 05:27:21 <kanzure> gmaxwell: any hints on how i can trick fundrawtransaction into preferring non-watchonlys when they are available? that seems like a reasonable default that i should attempt to implement?
 58 2014-12-21 05:27:21 <phantomcircuit> hmm
 59 2014-12-21 05:27:49 <gmaxwell> run without watchings, and if you're successful stop.
 60 2014-12-21 05:27:54 <phantomcircuit> i guess for now maybe just explode if someone tries to estimate fees in a transaction with watch only multisig
 61 2014-12-21 05:28:18 <gmaxwell> phantomcircuit: I guess we should have a way for watching to import a redeemscript. :-/ then those would be fine.
 62 2014-12-21 05:28:19 <kanzure> gmaxwell: is there any sort of performance penalty to running the whole function twice that i should be worrying about?
 63 2014-12-21 05:28:42 <gmaxwell> kanzure: esp if the signing is out of the inner loop it will be so much faster that it won't matter.
 64 2014-12-21 05:28:43 <phantomcircuit> lol that sounds like real work
 65 2014-12-21 05:29:09 <gmaxwell> kanzure: I expect that most times it will work without watching OR you'll have no non-watching at all, in which case the first attempt is fast.
 66 2014-12-21 05:29:09 <phantomcircuit> where's sipa...
 67 2014-12-21 05:29:11 <phantomcircuit> :)
 68 2014-12-21 05:29:25 <kanzure> ah good point
 69 2014-12-21 05:30:07 <gmaxwell> kanzure: right now coin selection can be kinda slow but virtually all that is from cases where it iterates over signing many times. (which is about the dumbest thing ever.)
 70 2014-12-21 05:30:47 <phantomcircuit> well... it can also be slow in specific worst case utxo sets
 71 2014-12-21 05:30:48 <kanzure> maybe it was a good idea at the time..... </optimism>
 72 2014-12-21 05:31:08 <kanzure> ideally you can blame user error on entering into local minima on utxo sets :)
 73 2014-12-21 05:32:56 <kanzure> gmaxwell: should the retry be in rpcrawtransaction.cpp's fundrawtransaction, or in CWallet::FundTransaction in wallet.cpp?
 74 2014-12-21 05:34:07 <gmaxwell> kanzure: it was just a good idea when you regarded signing as a mysterious black box.
 75 2014-12-21 05:34:57 <gmaxwell> But it's not so mysterious, the signature encodes two 256 big numbers, the encoding method has explicit lengths and will omit leading zeros. sooo.
 76 2014-12-21 07:17:13 <kanzure> is there any reason that importaddress may not work during tests in qa/rpc-tests/  ?
 77 2014-12-21 07:37:31 <kanzure> nevermind
 78 2014-12-21 07:41:07 <kanzure> i am getting an "Insufficient funds" error from CreateTransaction when i have a watchonly-funded transaction
 79 2014-12-21 07:41:29 <kanzure> probably it's complaining about insufficient funds to make a good fee?
 80 2014-12-21 07:41:55 <kanzure> (watchonlys are all used up in my output amount)
 81 2014-12-21 07:46:04 <kanzure> maybe i should add a flag to CreateTransaction for allow-zero-transaction-fees-when-includeWatching?
 82 2014-12-21 07:46:38 <SoCo_cpp> I thought the point of watchonly was that you couldn't make transactions with it.
 83 2014-12-21 07:46:50 <kanzure> this is for fundrawtransaction
 84 2014-12-21 07:47:02 <kanzure> anyone can create a transaction but only someone with the right key can sign
 85 2014-12-21 07:47:18 <kanzure> or rather, only a certain signature is valid
 86 2014-12-21 09:32:15 <jeremias> how safe it is to kill bitcoind, which hangs up when you try to close it?
 87 2014-12-21 09:34:31 <iwilcox> Hangs for how long?  It can take a while to shut down.
 88 2014-12-21 09:40:10 <jeremias> I think now it has been 20 minutes
 89 2014-12-21 09:40:52 <iwilcox> Is it still logging?
 90 2014-12-21 09:42:15 <gmaxwell> jeremias: what version are you running?
 91 2014-12-21 09:42:29 <jeremias> in the log it says Shutdown: done
 92 2014-12-21 09:42:42 <jeremias> 0.9.3
 93 2014-12-21 09:42:43 <gmaxwell> uh, then it should actually be shutdown.
 94 2014-12-21 09:42:58 <gmaxwell> you sure you're looking at the right host? :)
 95 2014-12-21 09:43:08 <gmaxwell> or testnet vs non-testnet?
 96 2014-12-21 09:43:26 <jeremias> non-testnet
 97 2014-12-21 09:52:01 <jeremias> well, I killed the process and started it again, no problems
 98 2014-12-21 11:51:22 <moleccc> can a good soul send me some testnet coins to 18oFZ3pi5veZyWbQnmZ945ewBTvUTUxjmL, I want to play with bitsquare
 99 2014-12-21 11:51:30 <moleccc> oops
100 2014-12-21 11:51:32 <moleccc> mqR5GLouDY653npDSgpzauJ1zrFkMjQctb
101 2014-12-21 12:22:00 <paveljanik> anyone with a Retina Mac here? Can you please try adding some watch only address and take a screenshot of Rescanning... window? The progress bar here has some weird "shadows"... http://tmp.janik.cz/Bitcoin/Rescanning_progressbar.png
102 2014-12-21 12:26:07 <paveljanik> moleccc, go search "bitcoin testnet faucet"
103 2014-12-21 12:27:28 <fanquake> paveljanik does the progress bar only look like that on 10.10?
104 2014-12-21 12:28:50 <paveljanik> unfortunately I do not have a possibility to test right now on other systems, sorry
105 2014-12-21 12:29:44 <moleccc> paveljanik thanks, good idea
106 2014-12-21 12:30:58 <fanquake> paveljanik just curious, saw jonasschnelli also had that progress bar, but I’ve seen nothing like it when building from master
107 2014-12-21 14:01:07 <GMP> hi, how the hell " Discourage fee sniping with nLockTime #2340 " https://github.com/bitcoin/bitcoin/pull/2340 got merged into master without ON/OFF switch???
108 2014-12-21 14:04:49 <paveljanik> I'd like implement a RPC method to remove watch-only addresses. Got it working already, but I am searching for a good name for it - is removeaddress ok (as opposite to importaddress)?
109 2014-12-21 14:10:40 <paveljanik> or should I add an additional argument to importaddress (importaddress "address" ( "label" rescan remove)?)
110 2014-12-21 14:10:42 <wumpus> from what it looks like the only place in the API where anything is deleted is 'addnode remove', which uses the remove word
111 2014-12-21 14:10:45 <paveljanik> looks strange
112 2014-12-21 14:10:58 <wumpus> could you remove one of the send* methods to make place for it? :-)
113 2014-12-21 14:11:04 <wumpus> no, just kidding, just add a RPC method
114 2014-12-21 14:11:40 <wumpus> it's good to have simple commands with a simple function, not zillion of optional booleans and subcommands
115 2014-12-21 14:12:01 <paveljanik> watchonly {add|remove} ... would be nice...
116 2014-12-21 14:12:14 <paveljanik> but I do not want to change the ...
117 2014-12-21 14:12:26 <wumpus> wallet.watchonly.remove / wallet.watchonly.add
118 2014-12-21 14:13:09 <paveljanik> namespacing in the preparation of wallet removal? ;-)
119 2014-12-21 14:13:12 <wumpus> yes, don't change the ...
120 2014-12-21 14:13:19 <wumpus> we have to respect the ...
121 2014-12-21 14:13:22 <wumpus> :D
122 2014-12-21 14:13:38 <paveljanik> ok, it will be removeaddress
123 2014-12-21 14:13:41 <paveljanik> Thank you.
124 2014-12-21 14:13:44 <wumpus> yes
125 2014-12-21 14:14:15 <petertodd> GMP: "discourage fee sniping" produces valid transactions; services that reject them are broken and are being fixed, rapidly
126 2014-12-21 14:14:48 <paveljanik> wasn't gmp disabled a few days ago, BTW? ;-)
127 2014-12-21 14:14:57 <paveljanik> sorry
128 2014-12-21 14:14:58 <wumpus> I don't think he means gmp gmp
129 2014-12-21 14:16:00 <wumpus> petertodd: who was rejecting them?
130 2014-12-21 14:16:04 <petertodd> wumpus: coinbase
131 2014-12-21 14:16:24 <petertodd> wumpus: which is annoying because I told them about this about a year ago...
132 2014-12-21 14:16:27 <wumpus> interesting
133 2014-12-21 14:16:31 <GMP> petertodd: my typical bitcoin-qt usage scenario was:  boot offline, send some tx,..... update blockchain. revealing my block height compromising my identity and everyone around me
134 2014-12-21 14:16:52 <petertodd> GMP: that's fine - the discourage fee sniping patch still produces valid transactions in that case
135 2014-12-21 14:17:23 <petertodd> GMP: now if you mean block height as metadata, that's another issue, but highly niche
136 2014-12-21 14:17:42 <petertodd> GMP: if it's a sufficient problem for you, I'd suggest you make a pull-req for a cmd-line switch
137 2014-12-21 14:17:52 <wumpus> block height as metadata is interesting
138 2014-12-21 14:18:03 <wumpus> there won't be that many nodes with your exact block height
139 2014-12-21 14:18:08 <petertodd> wumpus: I did point it out months ago... hell, maybe nearly a year ago
140 2014-12-21 14:18:37 <wumpus> reasons like that is that I was afraid to merge it
141 2014-12-21 14:18:38 <petertodd> that's why the pull-req delibrately picks weird nLockTime's some of the time
142 2014-12-21 14:18:55 <petertodd> 1/10th probability of anywhere in the last 100 blocks
143 2014-12-21 14:18:57 <wumpus> is why*
144 2014-12-21 14:20:16 <petertodd> wumpus: note my NACK here on my own pull-req: https://github.com/bitcoin/bitcoin/pull/2340#issuecomment-35689059
145 2014-12-21 14:20:40 <wumpus> you don't directly reveal your current block height to other users, but they can make conclusions based on what you request
146 2014-12-21 14:21:02 <wumpus> oh you do but only on new connections
147 2014-12-21 14:21:26 <wumpus> petertodd: so, revert?
148 2014-12-21 14:21:42 <petertodd> wumpus: well note further down my ACK on my own pull-req :)
149 2014-12-21 14:22:04 <btcdrak> haha wumpus he's trolling :roll: ACKs later on https://github.com/bitcoin/bitcoin/pull/2340#issuecomment-35703677
150 2014-12-21 14:22:18 <petertodd> wumpus: it's a change with some positives, and some potential negatives - hopefully the randomization made the positives outweigh the negatives
151 2014-12-21 14:22:31 <petertodd> btcdrak: yeah, gmaxwell kept bugging me about it :)
152 2014-12-21 14:22:39 <wumpus> I've never seen the point of it in the first place, but gmaxwell sipa jgarzik and otherw wanted it so
153 2014-12-21 14:22:51 <petertodd> keep in mind we already leak a lot of information in a variety of other ways
154 2014-12-21 14:22:54 <wumpus> so I was suckered into merging it
155 2014-12-21 14:23:25 <wumpus> petertodd: in transactions?
156 2014-12-21 14:24:13 <petertodd> wumpus: yeah, you implicitly leak when they were created 90% of the time just by where they come from, and you leak that they come from bitcoin core by a whole variety of bitcoin core specific tendencies
157 2014-12-21 14:24:29 <petertodd> s/where they/when they are published/
158 2014-12-21 14:24:42 <wumpus> I mean there is discussion of separating the broadcasting of transactions from the node functionality, but that makes no sense anymore when all kinds of metadata links them to your node anyway
159 2014-12-21 14:25:45 <petertodd> well the attack would be for someone to sybil your node to get you on a block height different from others - that's already dangerous from a privacy perspective
160 2014-12-21 14:25:59 <wumpus> but what if you're already behind, ie catching up
161 2014-12-21 14:26:37 <wumpus> do we use our true synced block height, or the headers-only height?
162 2014-12-21 14:26:44 <petertodd> sure, but that's pretty rare, is covered by the fact that other nodes produce nLockTime's that look like what you're doing too
163 2014-12-21 14:26:50 <petertodd> s/nodes/wallets/
164 2014-12-21 14:27:14 <petertodd> with the randomization 1/10 transactions look like they're up to 100 blocks back - that number can easily be increased
165 2014-12-21 14:27:49 <wumpus> why not always randomize?
166 2014-12-21 14:27:56 <azeteki> is there a design document/protocol for updating the bitcoin.org developers' guide to track pull reqs? i'm assuming that it tracks latest release rather than master, so there's a fair amount of time to deal with that
167 2014-12-21 14:28:08 <petertodd> wumpus: well, if you always randomize the underlying purpose of the PR is defeated
168 2014-12-21 14:28:56 <harding> azeteki: I help maintain the docs, and I'm in the process of updating it for 0.10.
169 2014-12-21 14:29:08 <wumpus> petertodd: if you always randomize that much, sure
170 2014-12-21 14:29:35 <petertodd> wumpus: question is are > 10% of wallet's out of sync? I kinda doubt it
171 2014-12-21 14:29:43 <wumpus> petertodd: but what if you'd always nudge it just a few blocks randomly
172 2014-12-21 14:29:51 <harding> azeteki: I don't mind mentioning new features that have been merged in master, but I'm hesitant to mention stuff that hasn't been merged unless its a major change (such as BIP62).
173 2014-12-21 14:30:08 <petertodd> wumpus: well, to work well you really want every transaction with an nLockTime such that even a 1-block reorg doesn't work
174 2014-12-21 14:30:20 <wumpus> petertodd: we generally recommend not sending transactions with a non-synced wallet
175 2014-12-21 14:30:25 <petertodd> wumpus: there you go
176 2014-12-21 14:30:34 <wumpus> petertodd: as the fee estimation will be off, as well as priority computation
177 2014-12-21 14:30:50 <petertodd> yup, and fee estimation itself is a big privacy issue
178 2014-12-21 14:30:51 <harding> azeteki: as for docs about the docs, we have the README.md in bitcoin/bitcoin.org and the style guide and todo list on the bitcoin/bitcoin.org GitHub wiki.
179 2014-12-21 14:31:03 <wumpus> petertodd: so maybe we just need a bigger warning...
180 2014-12-21 14:31:08 <petertodd> wumpus: I'll bet you we'll see a paper or two before long on fingerprinting nodes via fee estimates...
181 2014-12-21 14:31:37 <wumpus> petertodd: wouldn't you need to be put on a fork for that?
182 2014-12-21 14:31:48 <petertodd> wumpus: no, fee estimates are based on mempool data, not blockchain data
183 2014-12-21 14:31:57 <wumpus> petertodd: right
184 2014-12-21 14:32:05 <sipa> wumpus:, petertodd: my reasoning is indeed that bitcoin core'as transactions are already distingushable, so in that case we better start with good practices, and hope that other wallets copy them
185 2014-12-21 14:32:15 <btcdrak> ^
186 2014-12-21 14:32:20 <azeteki> harding: thank you
187 2014-12-21 14:32:37 <petertodd> sipa: and frankly we're not sure yet what good practices actually are - the only stuff I have any confidence in is things like DarkWallet where you have a uniform user group doing coinjoin mixing
188 2014-12-21 14:32:42 <wumpus> sipa: well, the problem above was not that the transactions are recognizable as being from bitcoin core
189 2014-12-21 14:32:59 <sipa> ah
190 2014-12-21 14:33:00 <harding> azeteki: there's also a docs mailing list linked from one of the first paragraphs of the docs if you have any questions and I'm not here. :-)
191 2014-12-21 14:33:05 <wumpus> sipa: just that you're leaking your current height, which may be identifying if you're not up to date
192 2014-12-21 14:33:16 <sipa> hmm
193 2014-12-21 14:33:50 <petertodd> though current height can identity you in other ways, for instance via dust
194 2014-12-21 14:33:53 <wumpus> sipa: there was talk about separating transaction submission logic from the node functionality, but that makes little sense if you can correlate the transactions to a node anyhow
195 2014-12-21 14:34:33 <azeteki> harding: mainly what i'm wondering about is the process for submitting a pull request to bitcoin core. i.e. it seems like a sensible/nice thing to do is to prepare a change to the docs if the pull req is accepted and submit that some time before the release hits. just to avoid the dev guide falling out of date and offloading the task to someone else
196 2014-12-21 14:35:23 <azeteki> does that make sense or am I waffling? :)
197 2014-12-21 14:35:28 <wumpus> petertodd: via dust/
198 2014-12-21 14:35:41 <petertodd> wumpus: ?
199 2014-12-21 14:35:53 <wumpus> petertodd: that was supposed to be a question
200 2014-12-21 14:36:16 <petertodd> wumpus: ah, as in, if you're behind, you won't even know some dust exists, and thus won't spend it
201 2014-12-21 14:36:19 <harding> azeteki: yeah, that'd be great.  Best thing to do might be to add it to the todo list and say "document core pull #1234, adds such-and-such feature, @azeteki will document here when merged in core".  Then when it gets merged, you write the docs.
202 2014-12-21 14:36:31 <wumpus> petertodd: well you may always decide not to spend it
203 2014-12-21 14:36:52 <petertodd> wumpus: just like you may not always decide to have nLockTime set to the current height :)
204 2014-12-21 14:37:17 <petertodd> wumpus: anyway, I suspect we just don't know for sure, and we'll find out as the academics start publishing papers on this - can always turn this off later
205 2014-12-21 14:37:22 <wumpus> petertodd: I was thinking about setting it to the headers-only height, but that's even easier to spoof and thus used for marking
206 2014-12-21 14:37:32 <azeteki> harding: thanks
207 2014-12-21 14:37:42 <petertodd> wumpus: is headers-only height based on block headers processed?
208 2014-12-21 14:37:49 <harding> azeteki: thank you for thinking about keep the docs updated!
209 2014-12-21 14:37:50 <sipa> yes
210 2014-12-21 14:37:51 <wumpus> petertodd: yes
211 2014-12-21 14:37:59 <petertodd> wumpus: right - that's pretty damn expensive to spoof...
212 2014-12-21 14:38:05 <azeteki> harding: well I use the docs a lot so it just makes sense. :P
213 2014-12-21 14:38:21 <wumpus> petertodd: at least you can't spoof it back in time, just a bit forward
214 2014-12-21 14:39:05 <harding> azeteki: yeah.  I think you'll like the not-yet-PR'd new format for the RPCs.  Might help find interesting new things for your ncurses app. :-)
215 2014-12-21 14:39:06 <petertodd> my thinking on this was node fingerprinting attacks were likely to be the least interesting - much more interesting was distinguishing different wallets from another, but again, there's so many ways that you can do that
216 2014-12-21 14:39:23 <wumpus> so: it will be closer to the real height than your current sync height when you're behind, no matter what
217 2014-12-21 14:39:51 <petertodd> wumpus: ok, so change it to headers height then - expensive to spoof forward, and as close as possible to tip is best
218 2014-12-21 14:40:05 <wumpus> petertodd: I don't care so much about distinguishing the software, just about disinguishing senders
219 2014-12-21 14:40:25 <petertodd> wumpus: athough there is the issue of reliable tx propagation - I already do 10 blocks back to avoid causing bad propagation for now
220 2014-12-21 14:40:48 <petertodd> mempool acceptance is based on real height
221 2014-12-21 14:41:23 <wumpus> petertodd: 10 blocks back should be safe enough
222 2014-12-21 14:41:44 <wumpus> if most peers are more than 10 blocks out of sync with the headers-first height, something is seriously wrong
223 2014-12-21 14:41:49 <petertodd> wumpus: yes... but remember that's meant to be a temporary thing until better propagation is implemented
224 2014-12-21 14:42:12 <petertodd> wumpus: again, for the entire thing to be worth while, you want nLockTime set so the tx can only be mined in the next block as much as possible
225 2014-12-21 14:42:31 <petertodd> wumpus: having said that, maybe accepting txs to the mempool based on header height is ok?
226 2014-12-21 14:43:08 <wumpus> petertodd: maybe
227 2014-12-21 14:43:57 <wumpus> although we try to enforce 'if it is in the mempool means it can be mined' invariant strongly
228 2014-12-21 14:44:53 <petertodd> wumpus: yeah, and we should (see https://github.com/bitcoin/bitcoin/pull/5521)
229 2014-12-21 14:50:59 <petertodd> unrelated: so I was discussing CHECKLOCKTIMEVERIFY with greenaddress, and that the timeout goes in the redeemScript and is an absolute timeout, rather than a delta timeout, is problematic
230 2014-12-21 14:51:53 <sipa> so you'dwant to be able to use p2sh, but with the locktime req outside of the hashed script?
231 2014-12-21 14:52:11 <petertodd> strongly considering writing up a spec for a CHECK_TXOUT_HEIGHT_VERIFY opcode so we could instead do: IF <pub1> CHECKSIGVERIFY ELSE CHECK_TXOUT_HEIGHT_VERIFY <delta-timeout> ADD CHECKLOCKTIMEVERIFY DROP ENDIF <pub2> CHECKSIG
232 2014-12-21 14:52:37 <petertodd> which would be redeemed in the timeout case with scriptSig: <sig> <txout height>
233 2014-12-21 14:52:43 <petertodd> sipa: yup
234 2014-12-21 14:53:21 <petertodd> CHECK_TXOUT_HEIGHT_VERIFY then would check the item on the stack against the txout height, failing the script if they aren't equal
235 2014-12-21 14:53:45 <petertodd> (obviously we might want to actually make that into a CHECK_TXOUT_DATA_VERIFY opcode so multiple such things can be put onto the stack)
236 2014-12-21 15:03:17 <petertodd> sipa: oh, actually that's kinda mistaken: even if you used a scriptPubKey the problem is still there, as you can't get senders to update old addresses (w/ a hypothetical "give sender whole scriptPubKey" address type)
237 2014-12-21 16:56:06 <n0n0_> hi
238 2014-12-21 16:56:30 <n0n0_> i recently found this on the wiki: https://en.bitcoin.it/wiki/User:Justmoon/IMTUO
239 2014-12-21 16:56:35 <n0n0_> it sounds like a great idea
240 2014-12-21 16:56:41 <n0n0_> is anyone working on this or similar things?
241 2014-12-21 16:56:51 <n0n0_> also, couldn't this be implemented as a soft fork eventually?
242 2014-12-21 16:58:39 <wumpus> yes, a form of commit-to-utxo is expected to land eventually
243 2014-12-21 16:59:06 <wumpus> though I don't think anyone is actively working on that right now
244 2014-12-21 17:02:43 <sipa> utxo or stxo
245 2014-12-21 17:08:58 <wumpus> stxo?
246 2014-12-21 17:32:56 <xabbix> What do the leveldb chainstate files contain? Is their structure documented anywhere?
247 2014-12-21 17:34:32 <wumpus> txdb.cpp
248 2014-12-21 17:35:00 <xabbix> I'll have a look, thank you
249 2014-12-21 17:46:47 <wumpus> just be warned that the databases are not an official interface, so we don't take any care in keeping them compatible from version to version
250 2014-12-21 18:04:46 <kanzure> anyone up for some pre-pull-request code review real quick? https://github.com/kanzure/bitcoin/commit/034b8544c60fda58cbf0d1787e50efe42d4fa676
251 2014-12-21 18:33:54 <kanzure> fundrawtransaction + watchonly https://github.com/bitcoin/bitcoin/pull/5524
252 2014-12-21 18:36:33 <brand0> nice work with the tests kanzure
253 2014-12-21 18:36:44 <kanzure> i think i am missing like 100% of the edge cases
254 2014-12-21 18:37:14 <brand0> maybe, sorry I can't provide more input
255 2014-12-21 23:20:13 <average> http://thehackernews.com/2014/12/ICANN-Hacked.html
256 2014-12-21 23:20:24 <average> cool stuff.. I guess we'll enjoy the fireworks for NYE..
257 2014-12-21 23:20:38 <average> a lot of these things are going on lately..
258 2014-12-21 23:21:13 <average> I can never tell if it's just me looking at more security news, or if it's really more security vulnerabilities coming up
259 2014-12-21 23:21:16 <average> anyway..
260 2014-12-21 23:23:09 <owowo> man that'S iNSAne!
261 2014-12-21 23:27:32 <average> owowo: what's so insane ?
262 2014-12-21 23:27:41 <average> oh, the 3-letter substring
263 2014-12-21 23:28:07 <user7779078> average: things seem hot lately, you aren't alone in that thought
264 2014-12-21 23:29:01 <average> user7779078: ah, interesting
265 2014-12-21 23:29:25 <average> nice to get confirmation