< achow101>
At least it's certainly another reason to stop using Intel CPUs...
< TD-Linux>
I don't think there are any obvious mitigations that bitcoin core can do that it doesn't already (like keeping unencrypted keys in memory for short times)
< promag>
macos not affected?
< achow101>
promag: it's a hardware bug, all OSes affected
< promag>
sorry, there is "os x" reference there
< TD-Linux>
apple has been silent so far. but you can assume that it's affected and not patched.
< promag>
right
< achow101>
"There are patches against Meltdown for Linux ( KPTI (formerly KAISER)), Windows, and OS X."
< phantomcircuit>
TD-Linux, only thing to do is detect the failure and exit
< phantomcircuit>
but even that is basically useless
< TD-Linux>
all of the large VM providers are already patched, so I don't think there is any useful action to take.
< echeveria>
TD-Linux: EC2 has scheduled forced reboots on the 5th.
< TD-Linux>
I haven't gotten a notification for mine yet.
< megan_>
Hi i am new baby in bitcoin development Please let me know how to get started in initial development
< bitcoin-git>
bitcoin/master aad3090 Jeff Rade: [rpc] Adding ::minRelayTxFee amount to getmempoolinfo and updating mempoolminfee help description
< bitcoin-git>
bitcoin/master a9a49e6 Wladimir J. van der Laan: Merge #12001: [RPC] Adding ::minRelayTxFee amount to getmempoolinfo and updating help...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12001: [RPC] Adding ::minRelayTxFee amount to getmempoolinfo and updating help (master...update_mempoolminfee_help_details) https://github.com/bitcoin/bitcoin/pull/12001
< wumpus>
BlueMatt: luke-jr: making the tarball include all git files was discussed a few files already, I think everyone is okay with that in principle, it's just hard to unify with the 'make dist' makefile-isms
< wumpus>
*I mean not include the git files, but all files from the repository
< wumpus>
^^ those kind of spurious PRs are the only kind that really annoy me
< zelest>
I just wish to remove as much clutter as possible when it comes to documentations. :)
< zelest>
hehe
< wumpus>
I agree, but I don't think it's clutter, just try to move it to a place it won't be in the way when just following the guide
< wumpus>
we don't have the capacity to act as tech support so anything that pre-empts issues that people might have is a win
< zelest>
Yeah, but the clang thing.. why does the user need to know what the compiler is capable of since what version of openbsd? :)
< wumpus>
you could shorten it, the point is that people are bound to forget the CC=cc CXX=c++ thing
< wumpus>
if they do, they end up in a situation where e.g. berkeleydb is built using gcc, and bitcoind using clang
< wumpus>
then they'll have linker errors
< zelest>
hmms, yeah, true
< wumpus>
the underlying issue is that openbsd 6.2 still has the gcc compiler, if it didn't, this wouldn't be an issue at all. Maybe for the next release it'll really go away?
< wumpus>
but for now, as long as gcc 4.2 is still installed, we need it
< zelest>
it will probably be there for quite some time
< zelest>
the whole ports tree and all the different architectures they build on
< wumpus>
and automake/autoconf tends to choose gcc over cc if it can
< wumpus>
which is terrible in this specific case
< * zelest>
nods
< zelest>
yeah, i should've based my changes on your pull request, like you initially said...
< zelest>
oh well, at least I've learned a bit more how github works now :)
< fazec>
I learned about syncing and forking at a certain height
< fazec>
I specified the params in src/chainparams.cpp
< fazec>
but still it's giving me a lot of errors such as 2018-01-04 12:07:30 ERROR: AcceptBlockHeader: Consensus:│ :ContextualCheckBlockHeader: 0000000000000000008c8f2437d│ 13a70632eb9e5ece259f2f96d03cac3ae5c84, not-hardfork, inc│ orrect block version (code 16)
< fazec>
Anyone?
< wumpus>
forks are offtopic here, try #bitcoin-forks
< Varunram>
wumpus: What is the possibility of a testnet seed connecting to a bitcoin abc seed?
< Varunram>
Asking this because I happened to connect to Peter Todd's seed and got redirected to an abc seed
< wumpus>
redirected?
< wumpus>
DNS seeds shouldn't redirect at all
< Varunram>
hm, bad language on my part I guess. So a related question would be what actually happens when I try to connect to a testnet seed? (you can answer at #bitcoin if its off-topic :) )
< wumpus>
in principle the DNS seeders should avoid reporting nodes that are on forks, but in the current implementation this is based on service bits, they don't actually (Afaik) check what chain they're on
< Varunram>
oh, alright. Weird thing was it didn't spawn an error (might be someone messing with the banner). Our fault I guess. Thanks!
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #12089: qa: Don't remember TestNodeCLI options between calls (master...Mf1801-qaCliOptions) https://github.com/bitcoin/bitcoin/pull/12089
< fanquake>
wumpus With the amount of forks I'm surprised we don't see more of those prs
< Varunram>
fanquake: The problem is, anybody can compare the diffs and PR..
< Varunram>
i.e. they needn't fork the fork's repo
< luke-jr>
why did Bech32 completely omit P2SH^2 stuff? :/
< sdaftuar>
luke-jr: not sure if my memory is failing me, but i believe p2wsh uses a single sha256 of the script, no?
< sdaftuar>
(anyway this is the first i've heard of the p2sh^2 idea, so i can't comment on your question generally)
< sipa>
i don't think relying on relay policy to prevent data storage is very realistic
< sipa>
at best it will make miners create websites where you can submit things
< luke-jr>
relay+miner policy; realistic or not, having it as an option is helpful
< luke-jr>
it might not help much with our current problems, but in the future it could become valuable
< luke-jr>
sdaftuar: elaborated more on my bitcoin-dev post; from the BIP, it doesn't seem to use single SHA256
< sipa>
luke-jr: it's also fundamentally incompatible with one of bech32's design goal: being forward compatible with future witness versions that may use dofferent hashing schemes
< sipa>
*different
< luke-jr>
sipa: but not forward compatible with this scheme :x
< luke-jr>
what if we define the first decoded data value being 17 or 18, to P2SH^2 modes?
< luke-jr>
or something like that
< sipa>
meh, that would be possible, but won't be extensible to newer witness versions (which i exoect will be proposed soon anyway)
< luke-jr>
could do 17 to indicate "additionally SHA256 hash", 18 to indicate "additionally RIPEMD160 hash", and then have a byte following it be the witness version
< luke-jr>
ugh, GitHub requires JS for opening PRs :<
< promag>
sipa: do you think it makes sense to return the number of processed characters in base_blob::SexHex?
< provoostenator>
luke-jr: you could probably use the Github API
< cfields>
I'd still like to avoid a lapse if possible, though
< cfields>
note that we also have the actual signing process to deal with
< jonasschnelli>
yes. In "emergency" cases, we can still create a single-person RSA cert...
< achow101>
although sooner is better. otherwise it becomes a release blocker
< cfields>
luckily I hacked up the mac codesigner last year, but it needs a bit of polish
< jonasschnelli>
achow101: Yes. Though we have the fallback doing the same as we already did (single person RSA cert)
< jonasschnelli>
How about Windows?
< cfields>
the only snag is that it doesn't handle timestamping. So worst-case, we may do a non-timestamped 0.16. It could be followed up with a timestamped release once that's worked out
< jonasschnelli>
Timestamping of what?
< cfields>
imo we should go ahead and do Windows once we've gone though the process for osx and identified the kinks
< jonasschnelli>
I have no insights how Windows code signing works... but probably the same RSA approach could be taken, right?
< cfields>
windows uses a free/open-source signer though, so that's no concern
< cfields>
yea, ideally we'd use the same procedure for both
< * jonasschnelli>
curses apple closed source signing
< cfields>
it's possible that it's just an hour's worth of work. I just haven't looked into apple's timestamping mechanism yet
< cfields>
ok, that's it from me
< jonasschnelli>
thanks for the update! Thanks for working on this cfields
< achow101>
I'm not quite sure how to interpret the results
< achow101>
but it basically looks like it performs no worse than the current algo
< jonasschnelli>
Maybe Murch can comment on your results?
< achow101>
It looks like it usually does slightly better since BnB is hit a small percentage of the time
< Murch>
achow101: If you're only simulating flat fees the only thing that you're counting is the number of transactions that don't create a change output.
< achow101>
Murch: I've only simulated flat fee so far. Maybe I should try it with somehow using mainnet fee estimation?
< Murch>
achow101: What would be really interesting is whether the different selection algorithm has an impact on the cost in varying fee levels, because it could cause BnB to select more unspents at a higher fee level and fewer at a lower level, which would only be visible in a scenario of varying fee levels.
< Murch>
That's at least my main concern in regard to deploying BnB.
< achow101>
Murch: I did run the simulation at different flat fee rates
< provoostenator>
Vaguely related question: is it possible to refactor the coin selection algo into a pure function that takes whatever info it needs (coins, mempool stats, etc) as input and returns the coins? That might make it easier to try different algos.
< achow101>
*simulations
< Murch>
achow101: Yes, I see that. But the selection effect would only be visible in a scenario with changing fees.
< jonasschnelli>
provoostenator: also in the past, there where discussions about having multiple coin selection
< jonasschnelli>
*selections
< provoostenator>
Right, that would be the idea. Easier to add more experimental selection mechanisms.
< achow101>
Murch: ah, right
< instagibbs>
provoostenator, standard coin selection right now is a loopy affair, kind of complicated :/
< Murch>
provoostenator: achow101's implementation does a big step in that direction .
< jonasschnelli>
other topics?
< Murch>
@achow101: The table seems to show only the final UTXO count, right?
< Murch>
Interesting would also be the final balance of the wallet, especially in regard to the scenario with varying fee levels.
< achow101>
Murch: it shows all of the same things that your simulation framework outputs
< achow101>
I think
< achow101>
It's a big table, you'll have to scroll
< Murch>
Perhaps we could put our heads together in the next few days.
< achow101>
ok
< Murch>
Great work there, though thank you!
< jonasschnelli>
Yes. Thanks achow101!
< Chris_Stewart_5>
provoostenator: So basically you pass in a higher order function to the actual 'read from wallet' function
< jonasschnelli>
Other topics?
< promag>
merge fest?
< provoostenator>
Maybe after SegWit UI is merged?
< promag>
I'm talking about that one :)
< provoostenator>
(I mean SegWit wallet)
< jonasschnelli>
Soon. :)
< jonasschnelli>
#endmeeting
< lightningbot>
Meeting ended Thu Jan 4 19:24:02 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< cfields>
kanzure: heh, looks like saurik added osx signing to ldid ~the same day we discussed in the meeting here last year
< cfields>
so we can cross that off the todo list :)
< phantomcircuit>
i was busy sleeping
< kanzure>
cfields: chalk this one up to teamwork and call it a day :P
< cfields>
kanzure: nah, i'm chalking it up to you pinging him about it. So, thanks :)
< cfields>
(and also to Cunningham's law, as my quick hacks probably made his eyes bleed)
< sipa>
oops, i was timezone confused and missed it
< luke-jr>
I thought we weren't having meetings during Christmas? :p
< Murch>
no wonder the meeting was so short and few ;)
< Chris_Stewart_5>
Murch: rekt! ;)
< instagibbs>
luke-jr, when does Christmas end for you
< sdaftuar>
sipa: any further thoughts (concept ack/nack) on whether you think #11739 is worth doing?
< gribble>
https://github.com/bitcoin/bitcoin/issues/11739 | RFC: Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis by sdaftuar · Pull Request #11739 · bitcoin/bitcoin · GitHub
< sdaftuar>
if so i feel like next step would be for me to email the dev list and figure out a way to document this (maybe update one of the existing bips?)
< luke-jr>
instagibbs: Jan 6 I think
< maxzor>
Hello, pls bear with some chitchat :) do you have an estimate of the average concurrent nodes working on a given transaction? Of the blocks that are discarded (are they stored in the extensive ledger?) ?
< sipa>
#bitcoin or bitcoin.stackexchange.com please