< achow101>
michagogo: interesting. My script (the on that is in contrib/) doesn't work. But yours does. Now I need to find what the difference is, because mine does a whole lot more stuff
< luke-jr>
sigs pushed for rc2
< achow101>
michagogo: I got it to work with my script (had to make a few tweaks). Thanks for making the vm image. Maybe part of the issue I have with setting up lxc on my computer is that I use Ubuntu 16.04 instead of 14.04
< jonasschnelli>
I guess CoinControls default should result in the exact same transaction like if it was not thrown into the CreateTransaction logic
< wumpus>
youd' have to be really sure of that
< wumpus>
also there's the possibility that the user disabled coincontrol and the settings are no longer at default
< wumpus>
be careful
< jonasschnelli>
hm...
< jonasschnelli>
I'd like to use it for the confirmation target (instead of miss-using the default)
< Victorsueca>
In theory the logic should be the same except maybe for some edge cases
< jonasschnelli>
Instead of adding a parameter to CreateTransaction
< wumpus>
I don't think passing in a defaults-only coincontrol structure if no coin control is desired is a bad idea per ce, it would simplify some checks
< wumpus>
Victorsueca: "in theory" is not good enough for these kind of changes
< jonasschnelli>
The problem is, CoinControl has bad test coverage. Mostly GUI only
< Victorsueca>
wumpus: yeah, either is "maybe" for the edge cases
< wumpus>
yes, that has to change
< Victorsueca>
this would have to go through some extensive checks to be sure the logic is the same
< wumpus>
requiring a coincontrol object would at least unify the coin control and non-coin control code paths for a bit
< wumpus>
good idea to use it for the confirmation target. THat would change meaning of the the structure from "coin control" to "sending preferences" but that's OK
< wumpus>
that's more general, I've always thought it was a bit strange to have an argument for what is basically a specific UI feature
< jonasschnelli>
Yes. We could rename it soon.
< jonasschnelli>
We aleady use it over RPC for fundraw
< wumpus>
well no need to rename it immediately, just add a comment to the documentation or so
< wumpus>
e.g. at the top of the class
< wumpus>
right, it's alredy used for other things
< jonasschnelli>
Currently, if you play with the smartfee-slider and use RPC or console (send*) it will affect your RPC/consoles send* confirmation target. :)
< wumpus>
yes changing the default in the background is really ugly
< wumpus>
that always bothered me, all the side effects and uncontained input in the wallet logic
< Victorsueca>
it's also ugly how it uses different fee systems for the GUI and the RPC
< jonasschnelli>
Yeah. We need to untangle the "CoinControls" layer violation. It should always respect the WalletModel
< Victorsueca>
lots of people have made mistakes believing the GUI setting would affect the RPC backend (which is logic to think)
< jonasschnelli>
Oh. So users may use the GUI to set the RPC parameters? So it's a features instead a bug?!
< tulip>
Lightsword: testnet seems to be at least mostly working today. some of the testnet explorers are jammed, but blockr.io and blocktrail.com are keeping up.
< Victorsueca>
jonasschnelli: AFAIK the GUI slider doesn't affect the RPC, and that's exactly the problem, some people tries it and ends sending a transaction with the RPC fee setting
< wumpus>
nonono the GUI should *not* affect the RPC
< wumpus>
that's completely clueless
< wumpus>
e.g. third-party software using the RPC should not be affected by what the user happens to be currently doing in the GUI
< wumpus>
of course this is different from clearly global scope changes like the 'settings' dialog
< wumpus>
which should affect the whole process
< wumpus>
but per-send options should definitely not affect RPC
< Victorsueca>
wumpus: yeah, but maybe we should add a warning message to avoid confusion, some people actually tries to use the GUI to set the RPC fee
< luke-jr>
wumpus: the slider isn't clearly per-send
< wumpus>
it should be.
< luke-jr>
wumpus: it's outside the entry-container, and remains set after you send
< luke-jr>
this suggests to me that it's global
< luke-jr>
even though I know it isn't
< jonasschnelli>
It's per send.. but the value will be stored and persisted in QSettings
< luke-jr>
jonasschnelli: how is that per send? :P
< wumpus>
it can be a convenience to remember the setting
< jonasschnelli>
With per-send I mean that its value should not be spread global and effect the CWallet structure and RPC
< wumpus>
but if that puts people on wrong footing, it should probably just reset every time
< jonasschnelli>
It's per-send in the software-design but persisted between multiple sends. :)
< luke-jr>
Maybe a "set as default" button
< wumpus>
but that default still shouldn't affect RPC
< jonasschnelli>
I think it could be useful to keep the confirmation target between sends
< jonasschnelli>
Yes. The default is GUI only
< luke-jr>
wumpus: why?
< wumpus>
there isn't even such a a setting in RPC, and QSettings should never affect core settings anyway
< jonasschnelli>
Indeed
< wumpus>
because RPC should be as stateless aspossible
< luke-jr>
it's a command-line option from the user's perspective
< jonasschnelli>
We could think of adding a conf-target feature to fundraw
< wumpus>
and certainly not 'inhereit' from the GUI
< wumpus>
this creates even more confusing differences between running bitcoind and running the GUI
< * jonasschnelli>
needs to fo afk
< luke-jr>
"Set as GUI default" :P
< wumpus>
yes
< luke-jr>
inb4 users ask what a GUI is <.<
< wumpus>
the people that use RPC will know
< Victorsueca>
think of it as a browser storing your login email for a web page, the web page only receives the email once per-login, even tho the browser can remember it and prefill the field the next time you visit the web page
< wumpus>
people that only use the GUI don't need to know the distinction
< wumpus>
but anyhow for the interface to be well-defined it needs to be entirely transparent which parameters affect RPC calls, there can't be any 'magic' side-input depending on whether a GUI is running
< wumpus>
remember the goal is to decouple the GUI, not couple it further
< Victorsueca>
what about putting a RPC-specific fee setting on the GUI? Maybe on Settings > Options...
< wumpus>
no, let people set RPC settings through RPC
< wumpus>
or preferably, pass necessary all input to the call itself so the message is self-contained
< wumpus>
but yes, in the settings dialog there could be settings that affect both GUI and RPC, there are some like 'dbcache' which necessarily need to affect everything
< wumpus>
there it is not confusing
< wumpus>
those settings will have associated command line arguments, and should also be able to be changed through RPC if possible to change them during runtime
< wumpus>
settings that affect RPC usage, but can't be set either through command line arguments or through RPC, but only through the GUI should be avoided at all costs
< wumpus>
hey, coincontrol.h needs to be in src/wallet
< jl2012>
is there any RPC command to clear the mempool or clear a txid from mempool?
< jl2012>
for regtest
< wumpus>
I don't think so
< jl2012>
any reason not to have this? I think it's useful for testing
< wumpus>
feel free to add it
< jl2012>
ok, i'll try
< wumpus>
though I'm not sure how useful it is for RPC testing, removing transactions manually seems a thing to exercise in mempool unit tests
< wumpus>
but if you have a specific test inmind that would improve, sure
< jl2012>
e.g. I submitted a tx, then I malleate the tx and resubmit, and want to see if the new version would be accepted
< michagogo>
Victorsueca: you can download it at https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq
< michagogo>
There's an .ova there, and a video showing the process of making it
< Victorsueca>
wumpus: it's probably getting lots of reviews because everybody loves a well deployed hard-forks, so well deployed that it's even a soft-fork!
< michagogo>
About one hour, from the first boot all the way through shutting it down to export
< Victorsueca>
I guess nobody thought some years back that a block size increase could be implemented as a soft-fork
< michagogo>
Including all the trial-and-error and pauses while I looked stuff up outside the VM
< michagogo>
Victorsueca: "some years back" nobody was thinking about the block size and the need to increase it yet
< jl2012>
i think the main argument for BIP16 was the output is not anyone-can-spend until it is actually spent. But the difference is very limited
< Victorsueca>
michagogo: want me to torrent the .ova up? I could seed it for a while until it spreads
< michagogo>
Ah, if you've got a seedbox I can make one
< michagogo>
One sec
< Victorsueca>
no need, i'll do everything
< Victorsueca>
I will send you the magnet link when it's done
< luke-jr>
jl2012: the main argument was the implementation didn't touch the script interpreter
< luke-jr>
jl2012: which was at the time considered by some to be essentially beyond anyone's competency to modify
< luke-jr>
in hindsight, that argument seems ridiculous to me. it may have seemed ridiculous to me at the time, I forget.
< wumpus>
it wasn't ridiculous at the time
< wumpus>
no one was competent to change that code at the time, least of all Gavin :)
< luke-jr>
well, I was the one changing it with BIP 17 ;)
< * luke-jr>
ponders if he went back and re-reviewed BIP 17's code, if he'd find any bugs
< wumpus>
and we still need to be extremely careful with changes to the script interpreter
< wumpus>
but there are a few more people clueful in that regard now
< Victorsueca>
michagogo: I prefer to create my own if you don't care
< Victorsueca>
michagogo: I can use that one tho if you want
< michagogo>
Victorsueca: how come?
< luke-jr>
glancing at the 1 page of consensus-critical code for BIP 17, I think I'm pretty certain it wouldn't cause consensus failure at least :P
< Victorsueca>
michagogo: currently downloading from 1drv
< Victorsueca>
michagogo: i'll start seeding it as soon as it's done
< michagogo>
molz: did you manage to get it from onedrive in the end?
< tulip>
> now that max script size is set on stone, fixing it would be a hard-fork
< tulip>
Victorsueca: not exactly. it can be done as a soft fork quite easily, same as segwit :)
< luke-jr>
segwit2 can just change the magic bytes! :P
< luke-jr>
actually, I guess that'd require retaining the old commitment too. hmm
< tulip>
when you think about it, there's actually very little which can't be done with a soft fork. it just depends how far you're willing to go with it. the limit is changing the proof of work, and even that is mutable to a certain extent if you'd like to.
< luke-jr>
tulip: go too far and it becomes a soft-hardfork
< tulip>
luke-jr: you should implement mohs scale for soft forks, otherwise you're going to increasing make less and less sense.
< Victorsueca>
and if you ever needed to make a hard-fork for whatever reason it could be well deployed if the hashrate majority merge-mines it while nuking the old chain
< aj>
tulip: does that mean a bilateral hard-fork might be said to be diamond tipped?
< michagogo>
Victorsueca: nuking the old chain how?
< michagogo>
Merged mining implies continuing to mine this chain
< Victorsueca>
michagogo: you merge-mine both the old and the new chain
< Victorsueca>
and you nuke it by soft-forking it to 0 MB blocks
< luke-jr>
Victorsueca: 100B
< Victorsueca>
luke-jr: your BIP still has a high potential to hard-fork in a bad way if people chooses to build and distribute software that bypasses the Hardfork deployment bitfields, ignores the fact that there are unknown rules activated out there and keeps mining on that chain
< luke-jr>
Victorsueca: nothing can prevent incompetent people from writing bad software, nor is it intended to
< Victorsueca>
AFAIK the only ways to make a safe hard-fork are either tricking old nodes to think everything is ok and make it a soft-fork (segwit) or soft-fork the old chain in a way that makes it unusable AKA nuking it
< Victorsueca>
2 ways*
< Victorsueca>
would be really appreciated by everybody if someone knew another way to make it reasonable safe to ensure the old chain will die
< aj>
Victorsueca: you can let old nodes continue to see all the transactions but maybe not understand everything about them (soft-fork), you can let old nodes see none of the transactions (nuke the chain, evil/soft-hard-fork), or you can let old nodes see some but not all of the transactions (sidechains, layer two networks) ...
< Victorsueca>
ahh right
< Victorsueca>
3 ways then, sidechains would be the third way
< wumpus>
please move this to #bitcoin
< wumpus>
it is not related to current bitcoin core development
< Victorsueca>
wumpus: thanks, will keep that in mind for the next time, I think we're done now
< wumpus>
this channel is for discussing code changes
< Victorsueca>
so, what is libconsensus exactly for?
< Victorsueca>
is it like a way to detach consensus rules from the main software?
< wumpus>
a) so that third-party applications can make use of the consensus code b) to cordon off consensus code from the rest of the software
< wumpus>
I understand, but I don't think we should be passing the CoinControlDialog's coincontrol instance in case coincontrol is disables. My code makes sure it gets a fresh instance with default values and just the confirmations overridden
< wumpus>
which is exactly what we want if coin control is only to be used to pass that parameter
< jonasschnelli>
Okay. Yes. Your right. Let me change it
< jonasschnelli>
I also revert the slider direction inversion.
< Victorsueca>
username is bitcoin and password is mdtj4g5w5bppajnpmt2ow2dx
< Victorsueca>
I password protected it so google doesn't bother me with malware removal warnings
< michagogo>
Victorsueca: what's wrong with the other one?
< michagogo>
Also, I'm not at my computer now
< michagogo>
Don't know when I'll be able to get it
< michagogo>
(And why not just a magnet link?)
< Victorsueca>
michagogo: I make my torrents in a way they go sooper-fast :P
< Victorsueca>
I tried it, but the way I do it magnet links are too long for any clipboard
< Victorsueca>
also no need to hurry, take your time until you get to your computer
< Victorsueca>
:)
< wumpus>
github is so slow here...
< jonasschnelli>
wumpus: yes. extra-slow at my end as well
< morcos>
jonasschnelli: wumpus: i understand the logic of why the GUI fee estimation PR just changes 25 -> 2, but I don't want to risk that we end up with a GUI defaulting to 2. I worry that a separate PR to change the overall default from 2 -> 6 will get bikeshedded to death.
< morcos>
And without that I think we're creating a worse user experience. Essentially even more people will be paying too much in fee. 25 is a better choice than 2 IMO.
< jonasschnelli>
I think 6 would be resonable... but we would need to change RPC and GUI
< jonasschnelli>
I don't expect to much bikeshedding
< jonasschnelli>
Hmm... rc2 does not run on OSX 10.7
< michagogo>
Victorsueca: hm, what is it that you do?
< michagogo>
I would have thought a torrent is a torrent…
< Victorsueca>
michagogo: not sure, I just touched a lot of settings to a option that sounded right to me and then it my torrent files started downloading things faster wherever I run them
< michagogo>
Victorsueca: which settings?
< Victorsueca>
michagogo: the ones when creating a new torrent file
< michagogo>
I'm asking, what settings did you use!
< michagogo>
use?*
< Victorsueca>
not sure if any of them made actually some effect or it's just my connection
< sipa>
i'm just responding to Victorsueca that the idea of not disconnecting if they do offer the right setvices isn't meaningful... we know that beforehand
< GitHub86>
bitcoin/master 72ca7d9 Matt Corallo: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock
< Victorsueca>
yeah, I understand, if we know the IP to connect to it is because some node told us, and when it did it also told us the available services
< GitHub86>
bitcoin/master 3cf496d Wladimir J. van der Laan: Merge #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock...
< Victorsueca>
which are stored in the addrdb
< sipa>
Victorsueca: exactly
< GitHub170>
[bitcoin] laanwj closed pull request #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock (master...cmpctblock) https://github.com/bitcoin/bitcoin/pull/8968
< wumpus>
although the services in the addrdb could be wrong, e.g. the peer may have changed services in the mean time
< instagibbs_>
err when do we store them in the addrdb
< * instagibbs_>
looking at code
< sipa>
right, but if the services in addrdb are wrong, we treat it as we accidentally connected to the wrong peer
< BlueMatt>
wumpus: wait, when did we decide 8968 was for 0.13.1?
< BlueMatt>
I thoguht we said no in milan?
< wumpus>
oh it isn't?
< wumpus>
removing tag
< Victorsueca>
lel
< BlueMatt>
yes, I think it is uneccessary for 0.13.1
< sipa>
BlueMatt: i can't actually remember having a good reasoning why it isn't necessary... but ibagree with the assessment that without clear sign of problems it's just ugly
< BlueMatt>
sipa: you're the one who pointed out that cs_main should always be the top lock
< BlueMatt>
so adding a cs_main should be just fine
< wumpus>
yes, at most you'll be holding it unnecessarily
< sipa>
ah
< sipa>
well, "should" :)
< * sipa>
breakfast
< Victorsueca>
don't know why but "cs_main" and "lock" in the same sentence sounds to me like you're going to fuck the databases and hard-fork something :P
< Victorsueca>
and I don't know coding at all
< wumpus>
please...
< sipa>
Victorsueca: then perhaps you shouldn't comment in this channel
< Victorsueca>
sorry, hope not to have jinxed you :S
< BlueMatt>
so, thus far, rc2 is final - doc changes?
< sipa>
want me to test whether "cs_main is always the topmost lock" is true?
< BlueMatt>
sipa: please do
< BlueMatt>
last block: propagated entire fibre network within 4ms of the speed of light between my servers
< BlueMatt>
ok, thats a lie, 10
< BlueMatt>
but whatever, thats pretty good
< sipa>
your technology sucks. you could get the block a full 3000 km further in the same time!
< BlueMatt>
not in glass!
< BlueMatt>
(closer to 1750km)
< sipa>
better get working on that vacuum-tube-fiber
< Victorsueca>
someone said github was slow before?
< Victorsueca>
I think I found why
< Victorsueca>
someone has been DDoSing Dyn nameservers at US east coast
< Victorsueca>
basically _half_ internet is down
< rabidus_>
Victorsueca: github down for me, also netflix
< rabidus_>
that's all i've found
< Victorsueca>
yeah, it's mostly huge and important services
< BlueMatt>
sipa: yea, west coast seems mostly fine, as in apac
< jtimon>
alright, setting manual DNS to one in the spanish list here did the trick: http://public-dns.info/
< rabidus_>
it think i'm going with big brother dns
< rabidus_>
good old 8.8.8.8
< jtimon>
oh, I tried 8.8.8.8, 8.8.4.4 first but it didn't worked because I forgot the coma, stupid me
< jtimon>
this kind of thing wouldn't happen if all domains were in a blockchain
< * jtimon>
hides
< * sipa>
forks jtimon
< instagibbs_>
stupid pill q: for inbound connections, how does the nServicesExpected vs offered check pass? It looks to me that expected services is only set for outgoing?
< instagibbs_>
this line "if (pfrom->nServicesExpected & ~pfrom->nServices)"
< sipa>
that check is always false if nServicesExpected is 0
< instagibbs_>
I was thinking xor... lol. sorry.
< instagibbs_>
Confused myself into thinking logic was "any difference in bits" vs "any expected but missing services"
< BlueMatt>
for those who are missing the cdn entry, though that one might very well be geoip, so have fun on the HKG one
< rabidus_>
or 8.8.8.8,8.8.4.4
< BlueMatt>
github isnt resolving on 8.8.8.8 for me atm
< rabidus_>
wtf, it is for me
< BlueMatt>
8.8.8.8 isnt just one server :p
< rabidus_>
or then my main dns started working
< rabidus_>
oh, yeah :P
< BlueMatt>
cfields_: ok, #8969 is ready for review since the cs_main fix was merged :)
< btcdrak>
There are also level3 DNS servers at 4.2.2.1, 4.2.2.2
< BlueMatt>
those dont work from all networks
< BlueMatt>
(also, level3 hates it when you publish those - they're supposed to be for l3 customers)
< * btcdrak>
shrugs
< jeremyrubin>
Annoyingly, Dyn ddos also seems to break travis.
< jeremyrubin>
Because travis doesn't have a pinned ip or something for github, so they can't find any of the repos
< midnightmagic>
:-/ What the hell. Why would my GnuPG key require a matching email in order to show as verified in github.
< midnightmagic>
"Sign this message acknowledging you authorize this github user to own your commits."
< GitHub149>
[bitcoin] instagibbs opened pull request #8992: Enable pubkey lookup for p2sh-p2wpkh in validateaddress (master...validatep2pkh) https://github.com/bitcoin/bitcoin/pull/8992
< GitHub91>
[bitcoin] paveljanik opened pull request #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut (master...20161021_fix_GetTransaction_comment) https://github.com/bitcoin/bitcoin/pull/8993