< Luke-Jr>
cfields: yeah, but I'm not finding any practical way to do that.
< cfields>
Luke-Jr: worked fine in my local test..
< cfields>
PYTHONPATH=$(PYTHONPATH) python foo
< Luke-Jr>
cfields: well, if the user is overriding PYTHONPATH, presumably they want it used with any program during the build process..
< cfields>
Luke-Jr: yes, so make sure it's invoked like that any time python is used
< cfields>
or more easily, just export it from the makefile
< Luke-Jr>
is that portable? and would we need to do it in every makefile?
< cfields>
should be portable, yes. no, all makefiles are included from the top one
< cfields>
well, all in src/ anyway
< jrmithdobbs>
i'm sorry, that was poorly executed. That is all.
< jrmithdobbs>
my bad.
< blade>
my transactions are not being confirmed whats going on
< blade>
its been over an hour
< blade>
im useig the bitcoin core wallet
< jcorgan>
blade: this is not the correct channel for this, please go to #bitcoin
< blade>
ok ty
< GitHub106>
[bitcoin] jrmithdobbs closed pull request #7243: This community NEEDS to adopt a code of conduct. Recent events make t… (master...code_of_conduct) https://github.com/bitcoin/bitcoin/pull/7243
< jrmithdobbs>
I just wanted to say again that I am sorry for that shit storm and thank you guys for what you do.
< dcousens>
jtimon: that came out wrong
< dcousens>
I meant, that is certainly the dream, but, I don't think its where bitcoin/bitcoin is headed
< dcousens>
At least, that opinion is based on the last time I spoke about it
< jtimon>
dcousens: it is certainly where Bitcoin JT is headed :p
< dcousens>
jtimon: haha
< dcousens>
Just realised as I re-read my comment, that it might have come across as "your dreaming buddy"
< dcousens>
when really it was more along the lines of "I hope so to, but, even this PR is having trouble :P"
< jtimon>
it came across just like Luke-Jr's later "I like that but seems out of scope for this PR"
< jtimon>
I literally mean just replacing the ints with strings for now
< dcousens>
I think its worth suggesting, but, theres still the concept which needs to be reach ACK'd status before the syntax is wortwhile
< jtimon>
maybe I should make clear that I will maintain a branch with equivalent functionality on top of major releases starting with 0.12 regardless of the PR being merged or not?
< dcousens>
I think people will certainly look to that PR for a simple patch set
< jtimon>
yeah, I will just do free a back-and-forward-port service of the PR with my nits squashed
< midnightmagic>
jtimon: You mean with full-RBF as an option?
< jtimon>
both fullrbf and firstseen, just like the PR (and then, hopefully more)
< midnightmagic>
jtimon: if you want someone to gitian it with you let me know, i'd be happy to an i have plenty of build capacity
< jtimon>
midnightmagic: that's great to know, my plan was to have only a source repo, but if you gitian it, that would be awesome
< jtimon>
Luke-Jr: didn't pblocktemplate->vTxSigOps[0] used to count p2sh sigops too ?
< Luke-Jr>
jtimon: yes, it's supposed to
< jtimon>
so that's what you mean when you say that you won't be able to recommend 0.12 for mining?
< morcos>
jtimon: it still does or there is a bug
< morcos>
but i'm pretty sure there isn't, b/c in checking that blocks were the same i verified that the sigop count was the same
< morcos>
oh [0], i missed that. i don't think i changed that line.
< jtimon>
in last-0.12.99 3cd836c1 I see pblocktemplate->vTxSigOps[0] = GetLegacySigOpCount(pblock->vtx[0]);
< morcos>
yeah, i think thats what its like in 0.11 too
< morcos>
yep
< jtimon>
yeah, that's not changed in 553cad94
< jtimon>
Luke-Jr: is it supposed to count p2sh sigops or not?
< morcos>
its probably meaningless the way its used in practice, because a p2sh script isn't used as the coinbase dummy argument
< Luke-Jr>
jtimon: yes
< Luke-Jr>
it's supposed to be everything to total to the sigoplimit
< jtimon>
oh that's only for the coinbase, never mind
< jtimon>
sorry, metal furt
< jtimon>
mental
< Luke-Jr>
[04:11:29] <jtimon> so that's what you mean when you say that you won't be able to recommend 0.12 for mining? <-- by this I mean, removal of priority policy support
< Luke-Jr>
note the current status quo is not merely "disabled by default", because the new implementation is still buggy
< Luke-Jr>
(status quo in master, I mean, not the network)
< jtimon>
I'm mostly interested in your opinion on last-0.12.99 3cd836c1
< jtimon>
Luke-Jr: ie what you think that needs to be solved for 0.12
< Luke-Jr>
the big things IMO are 1) ability to configure RBF policy (high demand from users); 2) fix policy support; 3) restore sane default setting for policy size
< * Luke-Jr>
looks over PR list to make sure he didn't miss anything too important
< Luke-Jr>
bytespersigop may be a good idea, and is tagged for 0.12
< Luke-Jr>
but technically not a fix
< jtimon>
oh, you expect the optional fullrbf to be backported to 0.12 ?
< jtimon>
I mean, I wouldn't oppose
< Luke-Jr>
yes, that was something many people expected to be part of the original PR..
< Luke-Jr>
I consider it a bug that it's not configurable right now.
< jtimon>
well, I consider it it cheap-to-maintain missing functionality, but we agree overall
< Luke-Jr>
7217 and 7213 also stand out as bugfixes that perhaps ought to get into 0.12
< jtimon>
I guess the difference is that I would be happy if it was merged in master but not backported to 0.12
< Luke-Jr>
many people I spoke to (on reddit especially) found the RBF changes acceptable only knowing it was configurable
< jtimon>
I think we should have supported fullrbf optionally and firstseen as default ages ago, maybe opt-in rbf wouldn't have been necessary
< Luke-Jr>
well, in general I think opt-in was a good improvement. but not if it entails developers trying to control users.
< jtimon>
yeah, I agree opt-in is a great solution to the dilema, I'm just pointing out that for me there wasn't a dilema in the first place, if there's controversy, that's more of a reason to offer both sides of the local policy controversy so that people can choose
< jtimon>
I hope this doesn't get rejected under the "controversial syndrome" btcdrak once talked me about
< sipa>
Luke-Jr: all fine with making optin configurable
< sipa>
i am not fine with adding full rbf support
< Luke-Jr>
sipa: it's not your place to decide.
< sipa>
sure it is
< sipa>
it is not my place to decide what people run
< Luke-Jr>
no, it is the end-user's right to decide.
< sipa>
it is my place to decide what i want the software that i am maintainer of to encourage
< jtimon>
sipa: why -policy=firstseen is fine but -policy=fullrbf is not?
< sipa>
jtimon: it breaks a social contract
< Luke-Jr>
it breaks no social contract. -.-
< jtimon>
what social contract?
< sipa>
whether you like it or not, some people see transactions as implicitly promising to not double spend
< jtimon>
this is policy, -policy=firstseen users must accept that they can't do anything about me running -policy=fullrbf (and viceversa)
< Luke-Jr>
RBF does not change that.
< sipa>
we can explain to people that this is a bad idea, but it does not change the expectation
< sipa>
and we just made that promise stronger by giving a way to opt out of it
< jtimon>
sipa: and they are free to use firstseen, whatever they like it or not, there's people that prefer fullrbf
< jtimon>
and they can't do anything to stop them
< sipa>
jtimon: absolutely!
< Luke-Jr>
Opt-in RBF does not opt out of the implied promise not to fraudulently double-spend
< sipa>
but i don't think we should encourage it either
< sipa>
Luke-Jr: imho it does
< Luke-Jr>
sipa: that's ridiculous.
< Luke-Jr>
those promises are part of society, not the protocol
< jtimon>
ok, but let's not make another bool please, let's do -policy=firstseen -policy=optinrbf even if bitcoin core insists on having people like petertodd publishing parallel releases
< jtimon>
it will be cleaner for me to add the -policy=fullrbf option in bitcoin JT 0.12
< jtimon>
Luke-Jr: I think he means bitcoin core did the promise, not the protocol
< Luke-Jr>
jtimon: any interest in combining efforts perhaps BTW? maybe Bitcoin LJR + Bitcoin JT can merge to some not-so-personal name?
< jtimon>
I would be happy to collaborate with you in bitcoin-policy if that makes sense to you
< jtimon>
as long as it starts with something like #6423
< jtimon>
but I'm still recovering from #5595/#6068's depression...
< Luke-Jr>
jtimon: I suspect the key thing to merging our forks will be whether the changes you want conflict in unresolvable ways with the ones I want.
< jtimon>
and sorry for being sincere, but you're partly responsible of me being so disappointed about that, I would have happily s/CStandardPolicy/CDefaultPolicy/ or added a TODO to some of the interface methods documentation to say it's incomplete months ago, but not when I closed it , for my own sanity
< btcdrak>
sipa, luke-jr, we should just leave rbf as it is for now
< btcdrak>
rbf will come slowly. it wont come by trying to push too fast
< jtimon>
if you want to collaborate with me on this bitcoin-policy branch you'll have to learn to nit faster, because I already have Bitcoin Core for when I'm fine waiting
< sipa>
agree
< jtimon>
btcdrak: sipa: ok, but let's not make another bool please, let's do -policy=firstseen -policy=optinrbf even if bitcoin core insists on having people like petertodd publishing parallel releases
< sipa>
jtimon: totally fine with that
< jtimon>
Luke-Jr: would you be fine with that for #7219 ?
< Luke-Jr>
jtimon: using -policy now, locks us in to the syntax for it; I don't know that the final syntax is so obvious
< jtimon>
supporting -policy=firstseen and -policy=optinrbf, but not -policy=fullrbf (yet, we can do that on our branch for now)
< jtimon>
well, in #6423 I was preparing for different policies to be able to have different attributes and command-line options dynamically
< jtimon>
(even if most policies just use specific default values for parameters in CDefaultPolicy)
< Luke-Jr>
hmm, so -policy would be kind of a "load this module" type logic?
< jtimon>
see also #5180
< Luke-Jr>
jtimon: how would you propose users select opt-in FSS?
< jtimon>
optin FSS?
< jtimon>
what is that?
< sipa>
fss rbf?
< Luke-Jr>
jtimon: first-seen-safe RBF only with the opt-in flag
< jtimon>
I was thinking of maybe cpfp variations as more potential options, or maybe just a parametrizable cpfp class that extends CDefaultPolicy
< sipa>
can we just stop doing dozens of policies that nobody asks for?
< sipa>
i understand that you'd want to disable rbf
< Luke-Jr>
sipa: that implies we should do policies that people *do* ask for.. like priority space and full RBF
< jtimon>
sipa: now we're talking about our potential collaboration (or Bitcoin JT if Luke-Jr cannot commit to the "nit early, nit often" principle) in which I'm interested in exposing as many policies as possible (just to prove the reusability of the underlying Cpolicy interface)
< Luke-Jr>
jtimon: unfortunately, I don't think I can commit to that, due to time constraints.
< sipa>
Luke-Jr: yes, i would like to support priority space; that's just an engineering tradeoff that it is hard to maintain; i am willing to promise that i'll personally look into a replacement
< sipa>
Luke-Jr: full rbf makes no sense for a full node unless miners do it
< Luke-Jr>
sipa: I'm pretty sure there are miners who do ti.
< sipa>
Luke-Jr: once they do, i'm sure we can even discuss it as default policy in bitcoin core
< sipa>
once they do in significant numbers
< Luke-Jr>
wangchun: ^ willing to take the heat? :P
< jtimon>
Luke-Jr: that shouldn't be an impediment, bitcoin-policy can be just the subset of bitcoin JT related to policy that you are happy with when you have time to be happy with it, not in a hurry for review anymore since this is going to be on top of 0.12 instead of master (I don't plan to PR anything policy-related until all the consensus code is encapsulated in a single building module independent from storage in master)
< Luke-Jr>
sipa: a replacement for the priority area would be nice, but until it exists and is well-tested, it isn't reasonable to remove the existing, working policy there
< btcdrak>
Luke-Jr: imo the best way for rbf is we release as is with optin full enabled, after 6-12 months after wallets have adapted and people see the world hasnt exploded, then we can propose a move to full full
< btcdrak>
petertodds optin full rbf is a political compromise
< btcdrak>
as was fssrbf
< btcdrak>
baby steps...
< Luke-Jr>
btcdrak: it wouldn't bother me as much, if it wasn't a pattern moving from "work toward increasing policy options" to "remove policy options and make them harder to develop"
< jtimon>
btcdrak: maintaining the optional -policy=firstseen shouldn't be more controversial than not doing it
< jtimon>
maybe -policy=default is better than -policy=optinrbf, but that is more resuable code and shouldn't be more controversial
< jtimon>
or I don't see how unless we support -policy=fullrbf in core, but as said I'm not concerned about maintaining that in a separate branch, it should be much easier to rebase to the next major release from now on than it was before for petertodd
< jtimon>
let's not support it on github/bitcoin, but it would be good that people understand that is going to be supported anyway, even if they don't like that
< jtimon>
just like we fullrbf supporters understand that firstseen is going to be supported (in my case, I really want it to be supported)
< jtimon>
just from the noise in the PR, I believe there's demand for firstseen, and I haven't seen anyone opposing to expose that, only some people opposing to fullrbf
< Luke-Jr>
if we're going to deny an option to full-full-RBF users, it makes just as much sense to deny the option to no-optin-RBF users. neither opinion has a more logical basis than the other, so we shouldn't play favourites in this extreme.
< jtimon>
well, although I agree that both parts in the policy-discussion should be treated equally (not necessarily with defaults) I guess the difference is that firstseen was the policy that was previously available
< jtimon>
anyway, I would like to understand your opinion on the special-space better too
< Luke-Jr>
jtimon: you mean priority?
< jtimon>
when I ask what's the use case you keep saying "to support the current policy", but I don't see how the current policy cannot be implemented with a unified metric, even if it's time dependent (which may have performance costs)
< jtimon>
but there's no need for a separated space
< Luke-Jr>
jtimon: by considering the feerate together with priority, it exposes the policy to feerate-based attacks (which are clearly a "when", not "if")
< jtimon>
yep, you could have a g(f(fees, size), priority) "fitness function" for transactions without special space
< Luke-Jr>
and then when someone games the fees, the whole block is spam and legit users are blocked
< jtimon>
no, you can create an heuristic function that is equivalent to any policy you can think of based on separated spaces, that should be methematically provable (not that I can do it right now)
< jtimon>
no, when I say equivalent I mean equivalent
< aj>
jtimon: only if you adjust g() based on what transactions are available
< Luke-Jr>
jtimon: that's at the very least much more complex to implement
< sipa>
jtimon: that's not the case unless you're willing to recompute virtual fees after every tx
< jtimon>
aj correct, that only seems a performance challenge
< Luke-Jr>
the goal ought to be to make policies *easier* to write, not absurdly complicated
< sipa>
Luke-Jr: how about we introduce a new scripting language then to configure relay and minig policies?
< sipa>
we still have engineering tradeoffs to makr
< jtimon>
aj not a code complexity one, we can maintain an optional functional-equivalent-but-far-less-performant version of "the current policy" with reduced maintainence costs, if someone wants to maitain the re-optimizations that's another topic
< Luke-Jr>
sipa: that's basically my long-term goal
< Luke-Jr>
minus it being a new language.. no reason not to allow using existing ones
< jtimon>
the goal of my branch is to offer as much functionality as possible as a showcase that the refactors behind it actually make the code more reusable and maintainable, not necessarily that all particular optional functionalities are suppported in the most optimal way
< sipa>
maintainable code is a worthy goal, and that's the extent of my support for policy refactors
< sipa>
i don't agree with the extreme configurability of policy as a goal
< jtimon>
no, extreme configurability is the means
< sipa>
extreme runtime configurability i mea
< jtimon>
it doesn't need to get into master, but a -policy=<string> is, I think, not that much to ask (and could save us some new bool command-line options in the future)
< sipa>
making policy changes easy to write is indeed a good way to verify the modularization you're obtained
< jtimon>
yes, yes, I mean the same, the goal is software quality, extreme runtime configurability is kind of a test to reusability
< sipa>
ok, agree!
< aj>
jtimon: hmm, if you want to define your own g() and make it vary depending on the remainder of the mempool, maybe the way to do that is with a generic update_mempool_tx_score rpc call, and writing the actual logic externally in python/etc?
< jtimon>
that's why I'm intersted on what luke really wants behind its defense of the separate space, because I find "the current policy" uninteresting to support in terms of reusability, I cannot think of another policy that is not time dependent and requires a separated space
< jtimon>
aj: well, I would just start with a CPolicy abstract class
< jtimon>
or a -policy=<string> command line option would also help
< jtimon>
but yeah, we could have -policy=rpc_mempool_score_update, shouldn't be hard
< jtimon>
and it could have different command-line parameters also configurable via GUI
< jtimon>
s/requires/"requires"
< jtimon>
so I would like to know more from luke about what's so great about not checking any minimum fee for some transactions
< jtimon>
aj in other words:
< jtimon>
def g(tx)
< jtimon>
if reason(tx.fees, tx.size) < reason_plus_ddos(mempool, tx):
< jtimon>
return false
< jtimon>
if priority < simulate_separate_space(tx, whatever)
< jtimon>
return false
< jtimon>
return true
< phantomcircuit>
Luke-Jr, i agree with jtimon that the cli parameter should be a string
< jtimon>
if priority(tx) < simulate_separate_space(tx, whatever)
< Luke-Jr>
phantomcircuit: comma-separated?
< phantomcircuit>
Luke-Jr, rbf policy option should be a string not 0,1,2
< phantomcircuit>
(just noticed you closed it, so nvm)
< Luke-Jr>
phantomcircuit: how do you specify both FSS and optin?
< Luke-Jr>
phantomcircuit: "nvm" is unnecessary, as this is still going in LJR
< phantomcircuit>
Luke-Jr, specify the parameter twice
< aj>
jtimon: the thing with priority is you can't just rely on choosing where in the order to insert the tx initially; you have to re-sort the old transactions as time passes. with an rpc set_mempool_tx_score call you could do that, but you'd still have to apply it to an individual transaction repeatedly while it sits in the mempool
< phantomcircuit>
isn't it implemented as a multimap anyways?
< Luke-Jr>
ew
< jtimon>
no!!!
< jtimon>
-policy=a, -policy=b, -policy=a_and_b: that's how you do a_and_b
< jtimon>
I mean, how you support it in parallel to only_a and only_b
< Luke-Jr>
jtimon: that isn't going to scale
< jtimon>
I still don't think I undesrstand firstseen
< jtimon>
I still don't think I undesrstand firstseen_optinrbf, isn't that the same as optinrbf?
< Luke-Jr>
no, it isn't.
< Luke-Jr>
why would you use underscores instead of commas?
< phantomcircuit>
Luke-Jr, meh, internally it's a bitfield presented to the user as -policy=A -policy=B
< jtimon>
Luke-Jr: well, some policies must die so that others can be maintained in parallel to the default one, infinite configurability forever certainly doesn't scale
< jtimon>
the goal of bitcoin-policy could be to support the most interesting ones that are relatively easy to rebase from the latest major release, or that can be easily added in the current one
< Luke-Jr>
…
< jtimon>
Luke-Jr: re why would you use underscores instead of commas?
< jtimon>
I would use # or @, of course, (ie -policy=a#and#b), but I thought underscores were the new trend
< Luke-Jr>
more user-friendly to use commas
< Luke-Jr>
since it's being parsed into multiple options
< jtimon>
the point is, once it is a string, I don't f#$%^ care what symbols you prefer as long as they play well with the command line (ie not -policy=m-y-p-o-l-i-c-y)
< jtimon>
and the other point is, I undesrtand -policy=firstseen and -policy=optinrbf, but not -policy=firstseen,optinrbf
< btcdrak>
I think it's the status quo in software to use the American spelling
< dcousens>
pretty much
< btcdrak>
I dislike that fact a lot...
< dcousens>
I gave up on `s` in favour of `z`, and almost never use `u`
< aj>
sipa: yeah, that seems sufficient, would be a bit painful to use for externally hacking priority back in
< dcousens>
jtimon: would it ever be worth policy being that 'plug and playable' though?
< dcousens>
like, unless you're a miner, or doing it for hardware reasons
< jtimon>
dcousens: as aj suggests? I don't know seems it would be very slow
< dcousens>
you're almost better off just capturing everything
< dcousens>
having your policy mimic miners is great for having an insight into what could be included in the next block
< dcousens>
but, its entirely speculative
< jtimon>
I would chose whatever option it's easier to maintain, if only I had an intersting use case (I just don't think free transactions are an interesting use case)
< jtimon>
in fact, I believe I will just remove the free tx special case from bitcoin-consensus-policy-jt, so it doesn't beelong in the bitcoin-policy-luke-jt common branch
< wangchun>
Luke-Jr: But I think for cafe-like small businesses, 0-conf is already unsafe as the block becoming full
< Luke-Jr>
wangchun: unconfirmed transactions are absolutely unsafe, I agree
< wangchun>
If a customer pays the bill with a no-fee tx, what should the cashier do? It probably never get confirmed
< wangchun>
And for priority space, if the block is not approaching to max block size, I would like to include some free tx in my block
< Luke-Jr>
wangchun: well, he can always CPFP it
< Luke-Jr>
and yes, priority will eventually make it eligible for charitable miners
< wangchun>
but if the block is already full, why should I still sort some tx by priority?
< wangchun>
That is why I used minblocksize=250000 before
< Luke-Jr>
wangchun: well, what about if there is a spam attack with fees?
< Luke-Jr>
like in the summer
< wangchun>
I have to set limitfreerelay to zero because I am aware some of my tx to be dropped randomly from mempool due to one patch recently get merged
< wangchun>
I am glad to hear how to disable this "feature", however.
< wangchun>
Luke-Jr: As you have suggested before, set minblocksize to 250k may open a door to spammers
< wangchun>
CPFP should solve cafe owner's problem
< Luke-Jr>
wangchun: no, I mean like over the summer, when spammers backlogged with paying fees
< Luke-Jr>
wangchun: if you put fees first, you would mine those before priority txs
< maaku>
wangchun: it is only a matter of time until mempools are always full
< wangchun>
maaku: that's why we have limitfreerelay to zero
< maaku>
wangchun: no matter your parameters. bitcoin usage will grow to exceed capacity. this is the expected outcome
< wangchun>
But if any devs could tell me how to disable the mempool tx dropping feature, I would like to increase limitfreerelay value to 3 or 5 which should help no-fee tx
< wangchun>
also priority size should decrease as the block template is approaching max block size
< wangchun>
Maybe I should write the patch
< sipa>
wangchun: the mempool limiting will only drop the lowest fee transactions, quite intelligently
< wangchun>
Luke-Jr: What's your attitude toward priority size?
< sipa>
wangchun: the solution is just to increase the size of the mempool
< wangchun>
sipa: I know, but we have the most important tx the lowest prioirty..
< wangchun>
sipa: so I must switch off this feature
< sipa>
wangchun: that i don't understand
< Luke-Jr>
wangchun: I think it should be non-zero :p
< wangchun>
sipa: I have a txt which has a list of tx we must confirm at the highest prioirty
< wangchun>
sipa: this txt file is read every time createnewblock is called
< sipa>
wangchun: you can use prioritisetransaction ?
< wangchun>
sipa: but the tx themselves in mempool remain their priority untouched
< wangchun>
sipa: prioritisetransaction does not persist
< wangchun>
sipa: and it cannot be edited with vim
< sipa>
wangchun: across restarts it does not
< Quent>
if blocks are full is it not easy to ddos spam the system so increasing the fee short term to unbearable amounts?
< Quent>
I think someone has some maths to show it too...
< sipa>
wangchun: it'd be pretty easy to hook up the reading of that file with the prioritization inside the mempool that prioritisetransaction does too
< sipa>
wangchun: which will automatically make those transactions ineligible for eviction
< wangchun>
sipa: I don't know how often it is called, reading files is expensive i suppose
< sipa>
wangchun: i haven't seen your code; i'm just saying that the two mechanisms should easily combinable
< wangchun>
sipa: but if you point me the git rev of the tx-dropping patch, that would help
< sipa>
wangchun: just increase the mempool size to whatever you can support
< wangchun>
sorry I have to leave, check irc log later
< sipa>
wangchun: -maxmempool=10000 will give you a max 10G menpool
< sipa>
wangchun: so set it to whatever amount of memory you can support; if it's still higher you'd go oit of memory anyway
< sipa>
wangchun: anyway, feel free to ping here more if you have questions
< dcousens>
sipa: with segwit, a rescan is only possible with all the witness data no?
< sipa>
dcousens: no
< sipa>
dcousens: i hadn't thought about that, but you can rescan without witnesses
< dcousens>
sipa: how so?
< sipa>
dcousens: why do you need signatures?
< sipa>
the amounts, addresses, consumed coins, locktime, ... are what matters to your wallet
< dcousens>
sipa: I don't, but, I might need the output scripts, and if they are (not always, but maybe) in the seg wit data too
< sipa>
dcousens: output scripts only matter for payments to yourself, and for those you know the full script anyway
< sipa>
the witnesses are for inputs, not for outouts
< sipa>
it's the same as p2sh
< dcousens>
yeah, I guess I'd just watch for the sigwit hash that matched the P2PKH equivalent script
< sipa>
you don't need to know the redeemscripts to analyse p2sh ouputs to your wallet either
< dcousens>
nvm, ta
< sipa>
not the equivalent; your wallet would know it gave out a segwit script, and explicitly look for that
< dcousens>
sipa: a fresh import wouldn't know
< sipa>
dcousens: why not? you'd need to import scripts just as with p2sh
< sipa>
before import
< dcousens>
sipa: not sure of how bitcoind handles it, but, conceptually, in regards to say watching a BIP32 tree, and trying to 'rediscover' it, you'd be able to track whats used based on a deterministic witsig scriptpubkey
< maaku>
wumpus: what is the translation schedule for 0.12 ?
< wumpus>
string freeze was dec 1, translations from transifex will be merged up until the last RC
< maaku>
hrm ok. I'm on a project that could hugely benefit from #7192, shame if we have to wait until 0.13 for native translations :(
< wumpus>
sorry for that
< maaku>
yeah understandable
< wumpus>
well it's only 6 months until 0.13 - that's the other side, the advantage of having hard deadlines
< wumpus>
also: first RC for 0.12 is planned for start of 2016, so now changing so many original translation strings would give translators almost no time (and a shitty time, around christmas) to make native translations. Probably resulting in having no native translations for many of the new strings at all
< wumpus>
it'd be possible though to include it for 0.12.1 (so backport 7192 after the 0.12 release)
< maaku>
That would be nice.
< Luke-Jr>
wumpus: the translation freeze can't be semi-relaxed for an algorithmic change, if I adjust them myself?
< Luke-Jr>
I mean, I assume we're not using different package names within the translations..
< Luke-Jr>
(that is, Bitcoin Kern is every place Bitcoin Core would otherwise have been)
< Luke-Jr>
to be clear, what I'm suggesting means we wouldn't need to wait on translators to make the adjustment
< Luke-Jr>
(I've done it before for the older stable branches)
< GitHub83>
bitcoin/master 37d271d mb300sd: Rename OP_NOP2 to OP_CHECKLOCKTIMEVERIFY.
< GitHub83>
bitcoin/master 595f939 Wladimir J. van der Laan: Merge pull request #7213...
< maaku>
Luke-Jr: I believe he means that the translators will have to update the translated strings
< maaku>
unless you suggesting s/search/replace for each translation, which probably would work but should be approved by a native speaker...
< Luke-Jr>
maaku: that's what I am suggesting, yes
< Luke-Jr>
it shouldn't need approval from a native speaker, since it produces the same final strings..
< maaku>
Luke-Jr: it is possible that the product name is translated differently in some languages based on context
< Luke-Jr>
maaku: if so, then I would be unable to do the substitutions :p
< maaku>
in which case the approach of 7192 would still work, but the translator would need to reword their translation to use a consistant grammar so the product name can remain the same
< maaku>
no idea if this is actually the case though, and there's a good chance it isn't
< wumpus>
Luke-Jr: that requires a feat of use of the transifex API above my knowledge at leest - and it's not a simple replace, remember that the name of the program has actually been translated in the native translations
< Luke-Jr>
I can't really know without trying, and since trying takes some effort, I'd rather have someone "okay" the concept before I try
< Luke-Jr>
wumpus: it's a replacement for each language
< wumpus>
(and there's no guarantee of consistency there)
< Luke-Jr>
wumpus: /if/ I can get the same output strings cleanly, are you okay with backporting it to 0.12?
< wumpus>
imo there's just too little time left, at least I don't have a lot of time to spend on bitcoin the remainder oft this year
< Luke-Jr>
and if I don't make it in time, we just go ahead without it?
< MarcoFalke>
Wouldn't 0.12.1 be enough for that?
< wumpus>
but given that you can patch the appropriate messgaes correctly on every translation on transifex (e.g. using the API) I'm not against it
< Luke-Jr>
actually, I keep forgetting I need to do it regardless. so I'll just PR it when it's ready, and if that means it doesn't get merged until 0.12.1, so be it
< wumpus>
MarcoFalke: yeah that's what I said
< wumpus>
<wumpus> it'd be possible though to include it for 0.12.1 (so backport 7192 after the 0.12 release) <- I think we should stick to that
< wumpus>
"<maaku> Luke-Jr: it is possible that the product name is translated differently in some languages based on context" hah yes - that's what I'm afraid of too, it's also one of the reasons this pull is a great idea, at least the product name will be the same everywhere in the program
< wumpus>
(unless there are languages where it *has* to be translated differently based on the context for correctness... hmm)
< Luke-Jr>
if that were the case, I think we'd already have problems in other areas
< maaku>
right but a competent translator should be able to account for that to make it uniform everywhere
< Luke-Jr>
anyhow, I'll try it and we'll see what I find.
< wumpus>
maaku: yes that makes sense
< wumpus>
(though that's another argument gainst doing this bot-wise)
< Luke-Jr>
MarcoFalke: btw, re copyright display, note we've changed it from Bitcoin developers to Bitcoin Core developers already once :P
< wumpus>
yes, it's supposed to be Bitcoin Core developers - was it changed back somehow?
< maaku>
I think he meant to highlight me -- I was pointed out that e.g. if I use this patch to change Bitcoin Core -> Liquid, the Liquid documentation would say "Copyright 2009-2015 The Liquid Developers" which is wrong in at least two ways
< Luke-Jr>
wumpus: no, he's complaining that PACKAGE_NAME gets substituted in the rendered places
< Luke-Jr>
maaku: well, just the About dialogue; doing it in docs isn't practical
< Luke-Jr>
maaku: how is it wrong?
< MarcoFalke>
Luke-Jr, not everyone preserves git history and the binaries are often distributed without the source code, so there'd be no way to find out if "MF core developers" actually include the bitcoin core developers as well
< Luke-Jr>
MarcoFalke: how is this a problem?
< wumpus>
I understand MarcoFalke's issue - automatically updating copyrights can be a bit thorny
< MarcoFalke>
Implying "MF" is the author of something he is not actually the author of.
< wumpus>
it makes it easy to steal credit
< Luke-Jr>
it doesn't imply that, though..
< maaku>
Luke-Jr: (1) changing copyright from Bitcoin Core -> Liquid; (2) Should be Blockstream in this context anyway --- "Copyright 2009-2016 The Bitcoin Core Developers; Copyright 2015-2016 Blockstream"
< wumpus>
so maybe leave the copyright alone
< wumpus>
leave it up to a project to set that
< Luke-Jr>
maaku: from Bitcoin Core *developers* -> Liquid *developers*
< Luke-Jr>
neither is a legal entity
< wumpus>
it doesn't matter if theres one more place to update it
< maaku>
Luke-Jr: ok i suppose that is not strictly speaking wrong
< maaku>
anyway yeah the copyright string probably shouldn't be changed
< wumpus>
having it automatically substituted only makes sense for Bitcoin Core, derivative projects likely want to extend it instead
< MarcoFalke>
Luke-Jr, it implies that, imo. Imagine MF Core is some fancy bitcoin app with the whole gui changed but running bitcoin core in the background. The only copyright notice says "(c) MF core developers". This clearly implies MF core developers are the only authors of the app.
< MarcoFalke>
Right, it should be extended
< Luke-Jr>
hm
< MarcoFalke>
I think I saw some altcoins doing this correctly
< Luke-Jr>
maybe a separate variable?
< wumpus>
yes make the copyright separate
< wumpus>
it's a good point
< wumpus>
if we had done this naively, the altcoins doing it correctly would probably have been the ones reverting to doing it wrongly
< Luke-Jr>
hrm, this is not trivial to do without breaking the translatability of this
< wumpus>
maybe just skip it for now
< wumpus>
leave the copyright as it
< wumpus>
could do it later, or not, you don't have to iron out all the issues in one pull
< wumpus>
but why is it so hard? e.g. make a function GetCopyright() { return _("Copyright 2009-2016 blabla developers"); }
< wumpus>
use that in the two(?) places where you need it
< Luke-Jr>
four, but that's more or less the approach I'm using
< Luke-Jr>
difficulty is one of them is inside a plist
< maaku>
Luke-Jr: add a %s at the end of the copyright which is the empty string
< Luke-Jr>
maaku: O.o?
< wumpus>
well the plist is another issue
< wumpus>
imo you should leave that for another pull too
< maaku>
and agree with ^
< wumpus>
just mae your pull what it promises to do - unify the product name where it's *easy to do*
< maaku>
this is fixable, but for now just don't substitute "Bitcoin Core" in the copyright string
< wumpus>
maaku: exactly
< MarcoFalke>
Agree, we can leave that for now
< Luke-Jr>
wumpus: easy to do was part of the first commit; the rest does very non-easy things :P
< Luke-Jr>
what does strprintf do if there's more params than fields?
< wumpus>
Luke-Jr: raise an exception
< Luke-Jr>
thx
< wumpus>
the script to fetch translations therefore checks if the % interpolations match in the translation and original string before accepting a line
< warren>
wumpus: I suggested parameterizing the name "Bitcoin" everywhere in part to make the overall delta of a sidechain fork far smaller.
< warren>
maaku: FWIW, Litecoin added a second copyright instead of renaming "Bitcoin developers" as renaming would be disrespectful and probably a copyright violation.
< maaku>
Freicoin did the same
< maaku>
but my point was that the above PR would have automatically done the copyright violating rename
< Luke-Jr>
warren: how a copyright violation?
< Luke-Jr>
jonasschnelli points out on the PR, that we do not independently list LevelDB etc
< maaku>
I don't think it is a violation under MIT
< maaku>
legally, ethically yes
< jonasschnelli>
Right... I think the source codes copyrights are the "important ones", ... the distribution package copyright informations are different. Check the app stores (iOS/Android).
< MarcoFalke>
Luke-Jr, I think it's called copyfraud in english
< jonasschnelli>
It would definitively be unethically (copy the source, rename and change the copyright).
< maaku>
anyway I think the proposed plan is good -- hard-code "The Bitcoin Core Developers" in #7192, and then later PR a bike-sheddable extended copyright notice for non-Bitcoin Core implementations
< jonasschnelli>
And Luke-Jr does not change the string itself,... it makes it just more "accessible"
< jonasschnelli>
*Luke-Jr s'PR
< warren>
Can we go further and parameterize all variations of the word Bitcoin in various strings that are currently translated?
< Luke-Jr>
maaku: but that leaves the problem unsolved
< jonasschnelli>
;-)
< Luke-Jr>
warren: -.-
< warren>
Luke-Jr: to make it easier for sidechains and ... XT to rebase =)
< maaku>
warren: I believe this PR does just that
< maaku>
my experience is that there are a few spots you don't want to search-replace however, such as references to the Bitcoin Wiki
< Luke-Jr>
warren: sidechains are Bitcoin
< maaku>
and there's still a few places that need to be parameterized, like bitcoind/bitcoin-cli in the RPC help text
< MarcoFalke>
warren, I think this can be another PR if really desired?
< Luke-Jr>
I don't think we need to spend time making altcoins easier :p
< jonasschnelli>
maaku: i think Luke-Jr's PR does not change the binary names itself (like bitcoin-cli stays bitcoin-cli)
< warren>
Luke-Jr: good point
< Luke-Jr>
the goal here is to make it easier to rename and/or fork Core, but within the scope of Bitcoin
< Quent>
sorry to barge in, but was just wondering whether there is any documentation on the algorithmic optimisations to libsec?
< Luke-Jr>
Quent: I would expect to find it in source code comments
< Luke-Jr>
you might try asking in #secp256k1 also
< Quent>
there is no documentation of the maths etc used in libsec save for the code itself?
< jonasschnelli>
If you compile it with openssl, you can also run a benchmark IIRC
< maaku>
Luke-Jr: we're in an era where multiple forks of bitcoind exist, and indeed are encouraged (outside of consensus code), and sidechains are moving into production
< maaku>
I would also question the "but that makes altcoins easier!" argument -- who cares? -- but I know that would fall on deaf ears
< Luke-Jr>
maaku: I see no use case in parameterising "bitcoins" for forks/sidechains, only altcoins.
< btcdrak>
seems like much of this conversation belongs in #bitcoin-dev
< warren>
MarcoFalke: re "Bump copyright headers to 2015" counsel at Red Hat advised us that it's most proper to have a comma separated list of years instead of a range, worst is replacing it with only the most recent year.
< warren>
In practice the notice doesn't matter all that much and this is fine, just commenting what was practice at a major open source engineering firm.
< warren>
... and I think we violated that advice a lot and it didn't matter.
< Luke-Jr>
indeed, the notice only matters insofar as it indicates intent
< MarcoFalke>
warren, you are right, indeed. The old helper script replaced the copyright year which is wrong. I fixed it to extend the range.
< morcos>
wangchun: Not sure if this is related to the issue you were describing, but very recently a fix to the way PrioritiseTransaction works was merged: https://github.com/bitcoin/bitcoin/pull/7062
< morcos>
The theory is you should only have to prioritise each transaction once and then it should remain prioritized in your mempool. Eviction will consider its new modified fee and sorting for block inclusion will consider its new modified fee for each new CreateNewBlock. But you should apply a deltaFee not a deltaPriority.
< wumpus>
<maaku> I would also question the "but that makes altcoins easier!" argument -- who cares? -- but I know that would fall on deaf ears <- yes, who cares, I'd rather have people that disagree on fundamental properties of bitcoin working on altcoins than staying around here to troll
< wumpus>
and unifying repeated strings simply makes sense when it helps enforcing consistency
< wumpus>
I also don't care about comma separated list versus range - range is a fine simplification IMO, the exact time and date of every change can be found in git if that's necessary for legal purposes
< MarcoFalke>
I think comma vs range is not a legal issue. (Range sometimes includes more years than necessary, but you can't claim copyright for something that isn't there in the first place...)
< phantomcircuit>
wangchun, trying to get things into your mempool which are otherwise rejected because of minrelay fee?
< wangchun>
phantomcircuit: yes
< sipa>
i think if you first call prioritizetransaction, and then submit it, it will be accepted
< wangchun>
as blocks are not very full these days, we would like to confirm some free tx
< phantomcircuit>
wangchun, should work, looks like that rpc command calls CTxMempool::PrioritiseTransaction which doesn't check if the transaction is already in the mempool or not
< phantomcircuit>
wangchun, how are you selecting which free transactions to include?
< wangchun>
sort by prioirity of course
< wangchun>
priority
< phantomcircuit>
wangchun, yeah then using the rpc command and prioritizetransaction is the best way to do that