1 2015-09-01 00:59:25 <jangorecki> Hi, short question, if tx was included in block which turns into stale block, will it be included in valid chain with the same txid hash?
  2 2015-09-01 01:01:03 <kadoban> jangorecki: It can be, and yes a transaction has a hash that doesn't change based on what block it's in (or not in) (but beware of maleability, which IIUC is still possible)
  3 2015-09-01 01:02:02 <jangorecki> kadoban thx
  4 2015-09-01 01:12:39 <Nikalin> any multibit developers here?
  5 2015-09-01 01:15:39 <pigeons> mutibit should use gitian ;P they must have been using a prvite repo for the binaries they put on their website and wouldnt say where the source for that was
  6 2015-09-01 08:11:21 <wumpus> cfields: I've run the rpc-tests.sh w/ wine quite a few times locally now, and can't reproduce the problem that happens in travis
  7 2015-09-01 08:13:30 <wumpus> at one point it had problems creating the HTTP server, but I've run it about 10 times since and no issues at all, the code I'm running is exactly as in the pull request, e.g. rpctimeout is at the default of 30 - starting to think that the wine version used in travis is simply broken
  8 2015-09-01 08:40:21 <jonasschnelli> wumpus: I'm going to build #5677 over gitian and try to run it (rpc tests) continuously in a windows vm.
  9 2015-09-01 08:40:33 <jonasschnelli> will take some hours till i can report
 10 2015-09-01 08:40:39 <wumpus> actual-windows?
 11 2015-09-01 08:41:16 <wumpus> yes, I think that'd be helpful. We've spent too much energy trying to get the tests to run on travis' apparantly old and broken wine version, and too little on windows itself
 12 2015-09-01 08:41:33 <jonasschnelli> wumpus: Right... let's see how this behaves on "real windows"
 13 2015-09-01 08:41:41 <jonasschnelli> Maybe it will lead to the travis issue
 14 2015-09-01 08:41:58 <wumpus> at least it will lead to real issues in bitcoind and not to emulation issues
 15 2015-09-01 08:42:07 <jonasschnelli> Right
 16 2015-09-01 08:42:35 <jonasschnelli> maybe i can also setup the new rpc httpd on a node and stress test it over night and see what we get
 17 2015-09-01 09:23:15 <jonasschnelli> wumpus: here are the gitian builds if you need them as well: https://builds.jonasschnelli.ch/pulls/5677/
 18 2015-09-01 09:23:47 <wumpus> thanks!
 19 2015-09-01 09:27:01 <wumpus> that reminds me that I need to merge #6548
 20 2015-09-01 09:47:50 <wumpus> talking about windows, this is weird: https://github.com/bitcoin/bitcoin/issues/6606
 21 2015-09-01 09:50:51 <gmaxwell> antivirus?
 22 2015-09-01 09:50:54 <wumpus> leveldb corruption is common on computers with hardware problems, but he's experiencing it everywhere
 23 2015-09-01 09:51:07 <wumpus> could be
 24 2015-09-01 09:51:40 <gmaxwell> I'm really unhappy with leveldb corruption on windows, it seems to be 100% reproducably corruptable with unclean shutdown.
 25 2015-09-01 09:51:57 <wumpus> he's not talking about unclean shutdown though
 26 2015-09-01 09:52:17 <gmaxwell> Yes, I see that here.
 27 2015-09-01 09:52:46 <wumpus> maybe the paranoid checks enabled in #4177 are too paranoid
 28 2015-09-01 09:53:02 <gmaxwell> oh also the fact that it's getting to 1 year behind strongly suggests AV if it's consistently getting that far.
 29 2015-09-01 09:53:10 <wumpus> although that was already in 0.10 and he says the problems started with 0.11
 30 2015-09-01 09:53:52 <gmaxwell> The paranoid checks are certantly exposing more issues (e.g. our reports of corruption went up a lot with 0.10) but we were also getting clear signs of undetected corruption pretty often before that (e.g. rejecting valid blocks as invalid)
 31 2015-09-01 09:54:02 <wumpus> but it may apply to e.g. short writes due to unclean shutdown
 32 2015-09-01 09:54:36 <wumpus> (although officially it doesn't anymore with recent leveldb versions I've never looked at the details)
 33 2015-09-01 09:54:38 <gmaxwell> so I would wager that it was always getting corrupted, and the checks have made it more sensitive. OTOH, I do think the case of truncated writes it can usually recover but with our current settings it cannot.
 34 2015-09-01 09:54:55 <gmaxwell> (I think)
 35 2015-09-01 09:55:14 <wumpus> well we fixed a truncated writes recovery issue already once, but you know how it is with these kinds of issues...
 36 2015-09-01 09:55:31 <gmaxwell> oh the latest comment is informative.
 37 2015-09-01 09:55:55 <gmaxwell> sounds like the issue we got when switching to leveldb at all-- that it stopped working on some kinds of network drive (I'd assumed ones where mmap didn't work).
 38 2015-09-01 09:55:58 <wumpus> there may be *more* truncated write issues waiting jus below the surface
 39 2015-09-01 09:57:27 <warren> gmaxwell: looks like the opposite in that comment
 40 2015-09-01 09:58:12 <gmaxwell> warren: I just meant that it was filesystem type sensitive.
 41 2015-09-01 09:58:53 <wumpus> yes, certain network file systems it'll certainly fail, but that happens instantly, not after syncing half the chain
 42 2015-09-01 09:59:20 <wumpus> (well I suppose *that* may happen too, just I haven't seen it before...)
 43 2015-09-01 09:59:40 <gmaxwell> oh interesting point.
 44 2015-09-01 09:59:58 <gmaxwell> antivirus on the VM host! :)
 45 2015-09-01 10:00:43 <wumpus> ... ouch ...
 46 2015-09-01 10:00:45 <gmaxwell> probably obfscuating the databases would be good just so I can stop assuming every random corruption on windows is AV. :)
 47 2015-09-01 10:00:59 <gmaxwell> As it has been AV ... really really often.
 48 2015-09-01 10:02:10 <wumpus> yes, I like the idea of obfuscating the database. /me waits for corruption issues caused by the obfuscation tho :(
 49 2015-09-01 10:02:27 <gmaxwell> Your mourning was rejected by my firewall, can you try HTTPS instead of FTP?
 50 2015-09-01 10:03:32 <wumpus> good for you! though I'm sure some of it seeped through and flipped some bits here and there and will cause nondescript problems at some nondescript point in the future
 51 2015-09-01 10:05:56 <gmaxwell> Were you active when the checksumed version handshake happened? dropped off a couple percent of the network because of some brand of nat devices that were rewriting the RPC1981 client address in the handshake and breaking the checksum.
 52 2015-09-01 10:06:31 <midnightmagic> AV is *extremely* high source of on-disk corruption. It is *not possible* to play nice with nearly all popular AV.
 53 2015-09-01 10:06:50 <midnightmagic> *any
 54 2015-09-01 10:08:37 <midnightmagic> At least. Not with heavy-use database structures that use hook-able filesystem calls.
 55 2015-09-01 10:32:42 <Eliel> Well, at least the error message about corruption could suggest disabling AV for the database directory.
 56 2015-09-01 10:32:58 <wumpus> gmaxwell: yes, I remember that vaguely.
 57 2015-09-01 10:40:44 <midnightmagic> As of two years ago, it was not possible to disable realtime AV for single directories.
 58 2015-09-01 10:40:56 <wumpus> let alone be rolled out in production hardware ...
 59 2015-09-01 10:41:17 <wumpus> I'm sure the idea is patented too :')
 60 2015-09-01 10:41:29 <midnightmagic> In all cases my former employer was aware of, disabling checks for single directories was for the periodic checks, not for the realtime stuff.
 61 2015-09-01 10:41:41 <wumpus> of course
 62 2015-09-01 10:41:53 <wumpus> why would it apply to everything That'd be too easy.
 63 2015-09-01 10:42:17 <wumpus> at most there's some undocumented hidden setting somewhere
 64 2015-09-01 10:43:09 <wumpus> anti-virus auto-immune disease
 65 2015-09-01 10:43:11 <midnightmagic> In all cases they were aware of, the only solution to prevent on-disk corruption, reliably, was completely disabling realtime AV and just letting the fallback periodic checks offer limited protection.
 66 2015-09-01 10:43:57 <wumpus> probably the computer was at least two times as fast for anything involving I/O workloads too. win-win
 67 2015-09-01 10:44:28 <midnightmagic> (This, for Windows only of course.) This was compounded by the fact that Windows doesn't have real file locking, etc etc ad nauseum, don't know why people are giving Windows a pass these days oh no Apple's the juggernaut feel sorry for the old enemy..?
 68 2015-09-01 10:44:59 <midnightmagic> yeah pretty much.
 69 2015-09-01 10:45:02 <jcorgan> http://www.forbes.com/sites/thomasbrewster/2015/08/26/netflix-and-death-of-anti-virus/
 70 2015-09-01 10:45:07 <wumpus> enemies that reliably kill themselves don't need any kind of fighting midnightmagic :)
 71 2015-09-01 10:45:15 <midnightmagic> :-)
 72 2015-09-01 10:52:45 <wumpus> is there an issue about obfuscating the database?
 73 2015-09-01 10:54:05 <wumpus> (couldn't find it at least in a quick search)
 74 2015-09-01 10:54:56 <wumpus> #4069 comes closest
 75 2015-09-01 11:51:43 <jonasschnelli> wumpus: for the window rpc test loop, ... would it be sufficient to just loop the wallet.py test with -tracerpc? Or do you need specific testing?
 76 2015-09-01 12:00:02 <wumpus> well for an initial test it'd be interesting to see what rpctests.sh does
 77 2015-09-01 12:00:14 <wumpus> before looping of any kind
 78 2015-09-01 12:00:39 <wumpus> looping is interesting to find transient issues, but our first priority is *does this work on windows* :)
 79 2015-09-01 12:07:00 <jonasschnelli> wumpus: but i assume i can't run rpctest.sh on windows?
 80 2015-09-01 12:07:31 <wumpus> why not?
 81 2015-09-01 12:07:49 <jonasschnelli> wumpus: /bin/bash?
 82 2015-09-01 12:08:21 <wumpus> msys?
 83 2015-09-01 12:08:37 <jonasschnelli> i have to admit i'm not familiar with windows.. :)
 84 2015-09-01 12:08:47 <jonasschnelli> let me install this
 85 2015-09-01 12:10:11 <jonasschnelli> True
 86 2015-09-01 12:50:32 <jonasschnelli> wumpus: rest.py reports error on MinGW
 87 2015-09-01 12:51:08 <jonasschnelli> looks like that the GetUTXO command over rest in .bin mode response an empty string
 88 2015-09-01 12:53:20 <jonasschnelli> testing on osx now...
 89 2015-09-01 13:05:57 <wumpus> strange
 90 2015-09-01 13:07:33 <wumpus> maybe python version issue?
 91 2015-09-01 13:07:53 <wumpus> I'd at least expect it's something on the script side
 92 2015-09-01 13:07:58 <jonasschnelli> wumpus: yeah... somehow python does not send the binary request...
 93 2015-09-01 13:08:03 <jonasschnelli> just commented out that part for now
 94 2015-09-01 13:08:22 <jonasschnelli> seems to be unrelated to the libevent PR
 95 2015-09-01 13:08:57 <jonasschnelli> httpbasics.py fails
 96 2015-09-01 13:11:29 <wumpus> what version of python did you install?
 97 2015-09-01 13:11:45 <wumpus> also: please test the before-libevent version as well, for a comparison :)
 98 2015-09-01 13:12:27 <jonasschnelli> Yeah. I should..
 99 2015-09-01 13:12:41 <jonasschnelli> httpbasics.py was my fault (used wrong test)
100 2015-09-01 13:12:52 <jonasschnelli> Using Python2.7
101 2015-09-01 13:18:48 <wumpus> ok python2.7 is good
102 2015-09-01 13:30:47 <jonasschnelli> wumpus: all test ran successfully... had to disable rest/getutxo bin request (python issue) and fully disabled p2p-fullbocktest.py because of a missing dependency (gonna look at this)
103 2015-09-01 13:39:16 <wumpus> jonasschnelli: that's great to hear, thanks for testing
104 2015-09-01 13:39:49 <jonasschnelli> looping the rpc-test.sh now and see if something happens... i'll also keep an eye on the CPU/MEM stats
105 2015-09-01 14:07:16 <dhill> the signing of that letter with an IRC handle versus your real name just cheapens it, imo.
106 2015-09-01 15:07:15 <wumpus> people can sign with what they feel comfortable with, it's more important that it's signed by a large number of developers than what name they use. And for the people that use aliases in git it makes sense to do the same here.
107 2015-09-01 17:22:58 <gmaxwell> gavinandresen: This is really embarassing, https://www.reddit.com/r/Bitcoin/comments/3j81bb/gavin_andresen_networks_close_to_capacity_get/   The best technical understanding in the community is that the bitcoin system generally needs a backlog in order for the built in incentives to work correctly.  You are making a false and trivialized 'networks' comparison, which to the best of my knoweldge is uns
108 2015-09-01 17:23:04 <gmaxwell> upported by the science.  We do not say that markets become 'congested and unreliable' when there are unmatched orderes on the orderbook.
109 2015-09-01 17:23:59 <gmaxwell> I am aware of no party showing the bitcoin system fundimentally misbehaves under congestion, in a sandbox or otherwise, in spite of some remarkable funded attacks as of recently trying to to exactly so...
110 2015-09-01 17:25:56 <gmaxwell> Moreover, to the extent that some parts of the system expirence problems under severe enough 'congestion', those parts _must_ be fixed because anyone can create unbounded traffic at any time with nothing other than a while loop.
111 2015-09-01 17:26:24 <gmaxwell> And, of course, kicking up some blocksize limits does not decrease congestion, it backs off one of the congestion management tools we have.
112 2015-09-01 17:26:51 <CodeShark> are we still confusing economics with scalability?
113 2015-09-01 17:28:08 <CodeShark> block space is inherently a scarce resource...that's what fees are for :p
114 2015-09-01 17:29:04 <CodeShark> if mempool congestion was really such a huge concern perhaps it deserved more attention in the last few years :)
115 2015-09-01 17:30:08 <CodeShark> I don't think Bitcoin will grow at a steady rate - its adoption curve will be heavily punctuated
116 2015-09-01 17:31:02 <gmaxwell> okay fine.
117 2015-09-01 17:31:04 <gmaxwell> https://bitcoinmagazine.com/21809/open-letter-bitcoin-community-developers/
118 2015-09-01 17:31:31 <CodeShark> at one of these inflection points we'll surpass the intrinsic processing capacity of the network and will have to be more selective in what we propagate and include in blocks
119 2015-09-01 17:35:09 <gmaxwell> CodeShark: So you mean being increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices?
120 2015-09-01 17:37:16 <CodeShark> we've already gone over this analysis, gmaxwell - underlying all this seems to be a significant difference of opinion about what Bitcoin is best used for
121 2015-09-01 17:38:09 <CodeShark> and exacerbating everything is the fact that the incentives structures in Bitcoin are no longer properly aligned
122 2015-09-01 17:38:25 <CodeShark> and get even more out of whack as we increase block sizes
123 2015-09-01 17:39:31 <CodeShark> so there's also an issue of priorities
124 2015-09-01 17:40:14 <CodeShark> some think we should rush to grow block size to stave off some real or imagined calamity...while others think it would be wiser to first address the incentive structures, then see how we increase throughput
125 2015-09-01 18:08:16 <btcdrak> cfields: wumpus: Seems there's a faster container system for travis now, http://docs.travis-ci.com/user/migrating-from-legacy/
126 2015-09-01 18:09:37 <developper> Hi Guys, I have fairly new in bitcoin development, I have just installed tesnet3 bitcoin daemon to develop webapps. So Is it suitable to create web application? I tried some libraries for development but they have no doc so I have decided to create my own library(api). Can you suggest something about it?
127 2015-09-01 18:10:26 <Luke-Jr> developper: what kind of webapp?
128 2015-09-01 18:10:43 <developper> like wallet apps
129 2015-09-01 18:11:34 <CodeShark> if you want to communicate at the p2p layer, I recommend starting here: https://en.bitcoin.it/wiki/Protocol_documentation
130 2015-09-01 18:11:43 <Luke-Jr> developper: #bitcoin for this discussion please
131 2015-09-01 18:12:14 <developper> But this channel about bitcoin development ?
132 2015-09-01 18:12:23 <CodeShark> if you want to communicate via HTTP, #bitcoin :)
133 2015-09-01 18:13:24 <CodeShark> this channel is not for the development of specific bitcoin apps - it's about core bitcoin dev (core infrastructure and reference protocol implementation)
134 2015-09-01 18:13:28 <Luke-Jr> developper: development of Bitcoin, not development of applications /using/ Bitcoin
135 2015-09-01 18:13:29 <developper> But it has RPC communication
136 2015-09-01 18:13:48 <developper> Hah , thanks for clarification.
137 2015-09-01 19:24:41 <mahdi> hey everybody, so I was keep playing with the bitcoin code-base and finally managed to get two blocks mined via bitcoind
138 2015-09-01 19:24:49 <mahdi> but looking at the log files each block has assigned to a random wallet
139 2015-09-01 19:25:07 <mahdi> and my default account shows 0.0 balance
140 2015-09-01 19:25:40 <mahdi> so is that something expected? or do I have to change something in order to assign these two blocks to an account?
141 2015-09-01 19:26:37 <wumpus> are you looking at immature balance?
142 2015-09-01 19:26:40 <sturles> The coins won't mature until 100 confirmations.
143 2015-09-01 19:26:47 <sturles> or 120..
144 2015-09-01 19:26:59 <sturles> mahdi: Check listtransactions.
145 2015-09-01 19:27:04 <mahdi> ah, okay
146 2015-09-01 19:27:27 <mahdi> so basically I have to have ~120 clients on the network
147 2015-09-01 19:27:37 <mahdi> to confirm the block? is that right?
148 2015-09-01 19:28:01 <mahdi> sturles, wati a second ...
149 2015-09-01 19:28:03 <wumpus> no, you don't, and #bitcoin please
150 2015-09-01 19:28:22 <mahdi> wumpus, i thought it might be dev related ...
151 2015-09-01 19:28:33 <wumpus> no, it's just a basic question about mining
152 2015-09-01 19:29:45 <mahdi> okay, I will continue in #bitcoin, cheers everybody
153 2015-09-01 19:30:01 <mahdi> BTW, sturles, listtransactions was helpful, thanks ;)
154 2015-09-01 20:35:43 <BlueMatt> wumpus: whats your view on NODE_BLOOM? At what point is it reasonable to merge it?
155 2015-09-01 20:36:00 <BlueMatt> ehh, should probably merge https://github.com/bitcoin/bips/pull/183 first?
156 2015-09-01 20:37:31 <wumpus> BlueMatt: BIP should go first
157 2015-09-01 20:38:39 <wumpus> apart from that I don't see a reason to delay it
158 2015-09-01 20:43:49 <kanzure> is that something you would not prefer to be the case?
159 2015-09-01 20:44:03 <wumpus> I don't even understand why it's the case
160 2015-09-01 20:44:16 <wumpus> just if I don't do it, nothing there ever gets merged :)
161 2015-09-01 20:45:08 <wumpus> guess I could add some people to the team
162 2015-09-01 20:46:50 <wumpus> the process is easy a) does the author want it to be merged b) is the BIP number 'official' c) has it been discussed on the mailing list d) does it adhere to the format
163 2015-09-01 20:50:04 <BlueMatt> wumpus: hmm, I think pull 183 (NODE_BLOOM) qualifies :p
164 2015-09-01 20:50:24 <wumpus> there's still an unhandled comment
165 2015-09-01 20:50:37 <wumpus> think you should at least reply to it...
166 2015-09-01 21:29:17 <wumpus> BlueMatt: still there?
167 2015-09-01 21:32:03 <BlueMatt> wumpus: ok, I fixed one comment, addressed the other
168 2015-09-01 21:38:33 <wumpus> ok. merged
169 2015-09-01 21:40:59 <kanzure> OP_CHECKFEE soft-fork proposal (obv. helps with offline signing setups) https://bitcointalk.org/index.php?topic=343234.0
170 2015-09-01 21:46:00 <Luke-Jr> IMO the BIP editor (gmaxwell) really ought to be the one merging to the bips repo
171 2015-09-01 21:46:02 <BlueMatt> wumpus: thanks
172 2015-09-01 21:48:36 <BlueMatt> wumpus: whats the reasonable waiting time to merge NODE_BLOOM, then?
173 2015-09-01 22:40:52 <wumpus> Luke-Jr: that's an unrealistic expectation
174 2015-09-01 22:40:56 <wumpus> BlueMatt: dunno