< Luke-Jr>
jonasschnelli: re isolating "Bitcoin Core" to fewer places.. there's 8 instances in the .ui files; I could move those to the equivalent .cpp, but it would look not-so-nice in Designer; thoughts?
< jonasschnelli>
Luke-Jr: hmm.. we could place a "placeholder" in the .ui files and populate them over code?
< Luke-Jr>
that would work
< jonasschnelli>
Or let the "placeholder" be taken care over the translation files.
< Luke-Jr>
?
< jonasschnelli>
Na. Bad idea.
< jonasschnelli>
Let's just populate it over code.
< jonasschnelli>
with your new var
< jonasschnelli>
It is really a good idea to isolate the application name. Thanks for doing this!
< Luke-Jr>
ok
< Luke-Jr>
do you know if src/qt/res/bitcoin-qt-res.rc can use PRODUCT_NAME?
< Luke-Jr>
it has includes, but it's not quite C++ O.o
< jonasschnelli>
hmm... i think it can't
< jonasschnelli>
Let me have a look
< jonasschnelli>
In that file we have things like CLIENT_VERSION_MAJOR
< jonasschnelli>
that seems after autoconf stuff?
< jonasschnelli>
So.. should work i assume.
< Luke-Jr>
I guess I can throw it through gitian to make sure
< jonasschnelli>
Luke-Jr: yes. I think that would show if it works or not. If you push/update your PR, i can also kick my gitian-builder again.
< Luke-Jr>
jonasschnelli: ok, pushed the rc changes; not done with ui ones yet, but that presumably needs no testing
< jonasschnelli>
(i mean in the original png pictures)
< Luke-Jr>
oh
< jonasschnelli>
But thanks for doing that!
< jonasschnelli>
Even if there are some differences. A SVG makes much more sense.
< Luke-Jr>
does the macdeploy stuff need to work outside gitian?
< jonasschnelli>
hmm... macdeploy stuff is not really used i guess.
< jonasschnelli>
I can't think of a use case where someone wants to build the mac dmg without gitian.
< jonasschnelli>
Also not sure if it really works
< jonasschnelli>
(nobody uses it, very likely to break)
< Luke-Jr>
cool, so I can just make the font ttf be an input? :P
< Luke-Jr>
(seems silly to include it in git just for this)
< jonasschnelli>
Luke-Jr: I think creating the background.png could be a manual step/sciprt
< jonasschnelli>
otherwise run the script withing the make deploy target
< Luke-Jr>
sure, my point is getting the TTF into the gitian VM
< michagogo>
Luke-Jr: depends package please
< michagogo>
The inputs/ dir shouldn't be used when it can be avoided
< wangchun>
should multiple signrawtransaction runs to the same unsigned transaction return the same signed hex or not?
< morcos>
wangchun: i'm not sure, but i think it should in later versions of bitcoin core
< wangchun>
morcos: it has changed?
< wangchun>
before i remember they are different despite the same input
< wangchun>
now they are all same, is it safe?
< morcos>
wangchun: see PR #5227. It looks like that went in for 0.10, which makes signing deterministic according to RFC6979
< morcos>
wumpus: suggested topics for todays meeting: 1) BIP 68 questions - a) semantic change to assume MTP b) implentation approach change to #7184
< morcos>
2) mempool containing only txs valid for the next block : is this something it would make sense to relax in the future, under what constraints?
< morcos>
wumpus: gmaxwell: #4906 which removes extraneous inputs disturbs me a bit. I see gmaxwell commented earlier on about some concerns, and it wasn't really clear to me how disproven those concerns were with the code that got merged.
< morcos>
there is not a lot of coherence around wallet logic and what our goals are, so its a bit concerning to have a change like this without realy understanding that its better
< MarcoFalke>
morcos, coin selection code is independent of MIN_CHANGE, at least in the scope of AproximateBestSubSet()
< morcos>
thats not to say i'm convinced it's worse, but just throwing it out there
< MarcoFalke>
If this was your concern
< morcos>
MarcoFalke: that PR is near the top of my list to review but what does that have to do with #4906?
< MarcoFalke>
The discussion in this PR covered far more than the actual commit changed
< morcos>
yeah i suppose they are tied together a bit, in MIN_CHANGE and not removing extraneous things both serve the same purpose
< MarcoFalke>
You could still NACK 4906, though. And say it is preferred to keep some low value coins in the inputs to put downward pressure on the utxoset.
< MarcoFalke>
But then again the transactions are larger and user pay more fee, which is also not wanted.
< wumpus>
with regard to privacy it's better to include as little inputs as possible
< morcos>
4906 is merged
< wumpus>
and also to generate smaller transactions where possible
< morcos>
wumpus: i was a bit confused by the sorting direction confusion, but if big inputs are removed first thats obviously better
< MarcoFalke>
I still think it's good to have it and focus on different approaches to reduce the utxoset
< morcos>
well gmaxwell's point was over the long haul it might be better to have larger txs and merge small inputs now rather than later
< wumpus>
I'm a bit doubtful about changing selection 'for the good of the utxo set'
< morcos>
ha, you mean not changing.
< MarcoFalke>
You'd need to make the selection algorithm work on more than just nValue of each coin
< MarcoFalke>
But I am planning to address this...
< wumpus>
(at least when it interferes with local concerns)
< morcos>
i don't think its just utxo set, i think its a question of whether its going to grind your wallet down into small inputs yourself which is bad for you
< MarcoFalke>
Are you referring to 6696 now?
< morcos>
like perhaps it would be better to remove at most one input
< morcos>
no i'm only referring to 4906
< gmaxwell>
wangchun: They are the same now, because we use derandomized DSA now, it's safe and has been this way since 0.10.
< morcos>
wumpus: mostly i think given the fragile and complicated state of wallet logic and the many competing goals, its probably preferrable to be conservative in merging small one-off changes of dubious benefit
< morcos>
i agree with you that perhaps something shoudl be done to avoid egregiously adding tons of small input txs that turn out to be easily removable
< MarcoFalke>
In most cases the diff does not affect the selected set at all.
< morcos>
but maybe that thing is a bit more nuanced than jsut removing them all
< morcos>
anyway, i'm not suggesting to revert, just trying to make sure its an area where we're particularly careful of unintended consequences.
< MarcoFalke>
I agree it was merged a bit too fast
< wumpus>
too fast?!?!
< MarcoFalke>
I haven't even had time to look at each commit
< wumpus>
it has been open since 2014
< MarcoFalke>
When he did the rebase
< wumpus>
has been the oldest pull for quite some while
< MarcoFalke>
Then two or three days wouldn't hurt ;)
< wumpus>
at last I prefer not including unnecessary commits, I admit other people may have different opinions, but that's the annoying thing about having one wallet implementation bound to bitcoin core
< wumpus>
commits->inputs
< morcos>
anyway, that's all i wanted to say. on another note please see my topic suggestions above which i put in the wrong channel.
< MarcoFalke>
I was only referring to the "dirty diff" when saying "merged too fast"
< wumpus>
anyhow if people are serious about wanting it reverted I'll revert it
< wumpus>
but next time if a pull is open for more than a year and you disagree please NACK it
< morcos>
if gmaxwell doesn't chime in then just leave it i say.. will be more real world data to help build even better algorithms
< wumpus>
I checked the logic for correctness but assumed no one was strongly against it
< wumpus>
(because of how long it was open)
< wumpus>
may be better to close old pulls no one cares about unmerged, I don't know
< morcos>
it could be part of the weekly meeting, to suggest a few old pulls that either need new attention or to be closed, and people could look at them in the following week
< morcos>
if no action happens, they get closed
< wumpus>
sure
< wumpus>
re: privacy, one concern has been that people have been sent small 'tracing' amounts on purpose, in the hope they will include it in a transaction. Removing unncecessary inputs makes this less likely. Of course, when it wouldn't link further inputs including them is less harmful.
< gmaxwell>
wumpus: to prevent that we should be selecting by link-group, and adding all the coins in a link-group whenever we spend.
< morcos>
wumpus: oh thx for mentioning that, i've never understood its value, is that something that is supposed to help pierce the obfuscation of coinswap or join or what have you?
< morcos>
otherwise i don't understand its purpose
< gmaxwell>
morcos: people pay small amounts to random addresses that have been spent from completely; so that when they spend from other address in the future, they will pick up the small amounts, and then show common ownership of the new address and the only one.
< wumpus>
morcos: well you send a small amount to an address someone gives you - they'll link it with other coins when they send
< morcos>
what gmaxwell said about a spent address makes sense
< wumpus>
morcos: which reveals some outputs belonging to theirw allet
< morcos>
but otherwise why not just watch existing ocins in the address
< wumpus>
there may be none
< gmaxwell>
E.g. you want to know who owns 1apple but can find nothing, 1apple has no coins assigned. You keep paying 1apple 0.00001 BTC whenever it runs out of coins, in the hopes that it gets spent at the same time as another address you can find out something about.
< gmaxwell>
also the more small coins the more likely linkage happens.
< morcos>
yeah, ok.. yeah thats what sdaftuar just explained to me as well
< morcos>
sigh.. people
< gmaxwell>
the whole coinselector in bitcoin core appears to have been written with a strong assumption that an address isn't used more than once. :(
< sdaftuar>
meeting time?
< Luke-Jr>
jonasschnelli: any easy way you could test a modified DS_Store file?