< GitHub117>
bitcoin/master 40c87b6 Ethan Heilman: Increase test coverage for addrman and addrinfo...
< GitHub117>
bitcoin/master 326ffed Wladimir J. van der Laan: Merge #7212: Adds unittests for CAddrMan and CAddrinfo, removes source of non-determinism....
< GitHub146>
[bitcoin] laanwj closed pull request #7212: Adds unittests for CAddrMan and CAddrinfo, removes source of non-determinism. (master...unittest) https://github.com/bitcoin/bitcoin/pull/7212
< GitHub152>
[bitcoin] dcousens opened pull request #7436: AcceptToMempool: extract various policy functions [WIP] (master...expolicy) https://github.com/bitcoin/bitcoin/pull/7436
< sdaftuar>
wumpus: i don't think 6842 needs to be backported to 12 -- it's an extremely small effect
< sdaftuar>
limitfreerelay is still essentially respected for limiting the bandwidth used by free transactions
< sdaftuar>
i believe the current behavior is not clearly a bug, as i think it just causes bytes to be allowed now at the expense of bytes allowed in the future. the proposed change might make the code more intuitive though, so fine if we want to merge it into master, but no need to include in 0.12 in my opinion
< bad_duck>
is there a bitcoin-core related chan for non dev questions? I saw that there is a slack but I don't want to use it
< choice>
Hello!
< choice>
Im trying to figure out, how LN prevents miners from opening channels, spending money and then closing the channels without the spending goin to the blockchain.
< choice>
Anybody here who understands that part of LN?
< aj>
you don't count a channel as open until the anchor transaction has been confirmed multiple times
< choice>
aj: well.. i was thinking about the closing of the channel.
< aj>
once the channel is open, trying to close it with anything other than the current/correct balances means that the other party can steal all the funds
< choice>
even after the closing transaction is in the blockchain? i dont think so.
< aj>
yes, even after that
< aj>
the anchor transaction has a multisig output, so you can only spend it with a closing transaction signed by both parties
< choice>
that cannot be
< choice>
closing the channel is possible for one party alone.
< choice>
otherwise the other party could freeze your coins.
< aj>
each party gets a slightly different closing transaction, that's pre-signed by the other party. it has the rule that, if counter-signed and published, then the funds belonging to the person doing the publishing are locked for a short period (2 days, eg), to give the other party time to claim fraud. if there was fraud, anytime in that 2 day period, the other party can steal all the funds from the chann
< aj>
el. if there wasn't fraud, the two days expires and whoever posted the closing transaction can claim their funds
< choice>
aj: ah! there is a lock period!
< choice>
that was the missing piece of the puzzle i was looking for.
< aj>
choice: yeah, that's why lightning wants OP_CSV, for that exact lock
< choice>
is there a description of OP_CSV somewhere? Did some googling but nothing came up.
< OxADADA>
re: Clarifying Communications: How does #bitcoin-core-dev IRC discussion differ from #bitcoin discussion?
< btcdrak>
OxADADA: #bitcoin is a general bitcoin discussion channel, #bitcoin-dev is a general bitcoin development discussion channel. This channel is specifically regarding Bitcoin Core
< btcdrak>
If you have any other questions let's take it to #bitcoin
< wumpus>
sdaftuar: ok, thanks! I'll remove the 0.12 milestone. I saw it and I thought shit, we forgot this
< OxADADA>
btcdrak: thats what i figured.
< OxADADA>
btcdrak: so protocol dev vs core client dev
< wumpus>
yes, #bitcoin-core-dev is only about development of the software
< wumpus>
sdaftuar: the talk about attackers made me a bit worried :)
< what_now>
ello, sometimes I get a time out on rpc calls to bitcoind. I am using 0.11.2. I have a big wallet file(big keypool). The slowdown occurrs upon all commands(example wallet decryption too) not just sending out funds.
< jonasschnelli>
Yes... It's a know problem. How many transactions (est.)?
< jonasschnelli>
what_now: IIRC there are some tiny improvements in 0.12. Mind trying rc2?
< what_now>
In the hundreds
< jonasschnelli>
Na. That should work.
< what_now>
Can't risk it, production environment
< jonasschnelli>
CPU? Disk (spinning)?
< what_now>
All ok (not exceeding 30% usage)
< jonasschnelli>
okay... strange...
< jonasschnelli>
how large (in MB) is your wallet.dat?
< what_now>
very
< what_now>
sec
< what_now>
about 1MB
< jonasschnelli>
should not take long!
< jonasschnelli>
Your not on an embedded system (RiP) or so?
< what_now>
I know its very strange and its not isolated either
< jonasschnelli>
Can you compile bitcoin by yourself?
< what_now>
Its a decent configuration i5, 4GB ram ssd
< what_now>
yes
< jonasschnelli>
You could run it with a time profiler and check where you loose time.
< what_now>
But not on this machine, I could do it on a similar spec machine
< what_now>
valgrind?
< jonasschnelli>
If you are on linux,... valgrind would probably do it.
< jonasschnelli>
I often use OSX time profiler (Instruments)
< what_now>
Yes ubuntu 12.04
< jonasschnelli>
Not very familiar with linux time profilers... but valgrind could be a solution.
< jonasschnelli>
Or add some printf with GetMircoTime() and do your own dump long bench.
< what_now>
Alright, its gonna eat up my weekend but oh well.
< jonasschnelli>
hehe... :)
< jonasschnelli>
Yes. Bitcoin Cores wallet def. needs a better backend and a performance boost
< what_now>
Such is the world of bitcoins, no borders no weekdays :)
< jonasschnelli>
exactly. ;-)
< what_now>
Yeah I am honestly waiting for major changes regarding the wallet. Adding HD functionality would be great too
< what_now>
Keeping up wallet.dat files and backing up and keeping counts of keypool size is such a nuissance
< what_now>
At the same time I respect the values of decentralization and accountability so don't wanna give up my full nodes either
< what_now>
I'm gonna pick up c++ and start getting more involved into bitcoin, although currently my knowledge of c++ is limited to the qt framework.
< jonasschnelli>
what_now: i have two HD PRs open. Needs review!
< what_now>
There's also so much to keep up with regarding this project, so many bips so many discussions feels like its gonna take forever to get to a decent level. At the same time.. I can't leave you guys alone and have only 5-10 people know wtf is going on with everything :)
< what_now>
Great
< what_now>
Can you give a link?I'd like to help out with testing and whatever since I'm gonna compile it anyway this weekend
< gmaxwell>
wumpus: this is annyoing, I can't seem to update #7099 because I deleted the branch in my repository.
< GitHub56>
[bitcoin] gmaxwell opened pull request #7438: Do not absolutely protect local peers; decide group ties based on time. (0.12...dont_protect_local) https://github.com/bitcoin/bitcoin/pull/7438
< GitHub77>
[bitcoin] gmaxwell opened pull request #7439: Add whitelistforcerelay to control forced relaying. [#7099 redux] (master...control_relay_force) https://github.com/bitcoin/bitcoin/pull/7439
< GitHub27>
[bitcoin] gmaxwell closed pull request #7099: Add whitelistforcerelay setting [PR changed to no longer default to off.] (master...control_relay_force) https://github.com/bitcoin/bitcoin/pull/7099
< btcdrak>
gmaxwell: git reflog is your friend
< gmaxwell>
btcdrak: git reflog can't help with github.
< Dizzle>
gmaxwell: restore button gone from the PR? Usually shows up in the deletion activity line.
< Dizzle>
or at least I thought it did
< gmaxwell>
Dizzle: I removed the parent repository and readded it.
< Dizzle>
ahhh, yea, seems like you did the only thing you could :|