Grin development , for general questions use the #support channel- https://github.com/mimblewimble/grin
welcome back @antiochp !
:wave:
it's good to "see" you again
been a little distracted with other unrelated things the past few weeks... back at least part time for the next couple of weeks
no pb, fully understand distraction
your single coinbase PR still had some good cleanup in it, no?
yeah I'll pull those out and rework a simpler cleanup PR
yes, good to see you around @antiochp
taking some catching up with everything that's been going on recently
things are moving pretty fast
tell me about it...
Welcome back @antiochp
loads done, loads more to do
yes, fast and slow at the same time
@antiochp @quentinlesceller I can check the code but hoping either of you know, what happens if a transaction, after aggregation, becomes invalid?
if it becomes invalid due to a new block (output already spent via another tx) then the tx pool should see that and evict it from the pool
as part of reconciling the tx pool against the updated chain state
so say I make a 499 outputs tx, yours coming after would get kicked out?
I don't fully follow - what do you mean by "after" here?
my 499 tx came in the stem first
you mean if my tx was attempting to spend one of the outputs you just spent?
no, it just gets aggregated with mine
how does that make it invalid?
oh I see what you're asking now
@tromp we have a max of 500 outputs
oh hmm
oh, that's a strange limit
i mean, why have a limit at all?
so maybe we're happily building a tx with too many outputs because we're not validating the limit during aggregation?
oh
I guess the full aggregated one gets kicked out as invalid
memory exhaustion, network abuse and all that fun stuff, bitcoin has a tx size limit as well
we won't attempt to de-aggregate or recover the constituent txs in that scenario, no
everything we read from network (or even disk) must have limits
ok, I'll create an issue to track this, let's not delay the meeting further
we should probably respect the limits during aggregation
but grin is supposed to make aggregation easier
hope everyone is having a great summer!
been an interesting one for sure
☀️
too summer
if some service can securely aggregate hundreds of tx, like coinjoin, then we're actively preventing that
i mean some ppl may want better aggregation than dandelion can provide
more of a meteorological scorched earth policy than a summer
@tromp perhaps we can increase the limit, but one's needed, you can't go beyond block size either
right, the block size is where it shld stop
I think we still have to limit the number of outputs anyway @tromp
lets discuss in the git issue (or here) later?
heh, heard of a drought going on in the UK, which I always thought was impossible
so let's go over the boring code stuff quickly and get to the interesting bits right after
as always, lots of small fixes and improvements, especially following T3
still lots of changes in the wallet but that's maturing nicely as far as I can tell
anything someone wants to mention in particular?
my mmr changes shld be rd now that i addressed remaining comments
@tromp yes, was going to do that very soon actually, sorry for the delay
:+1:
there's still the issue of simultaneous 0-based and 1-based indexing but that can be fixed separately
okay, then another good news is @hashmap is now officially a committer
:clap:
gratz @hashmap !
:clap:
🎖
which has limited perks right now but I guess that's a good segue into governance
perks?!
Corner office?
free coffee and such
all the T3 grins you can eat
before going into the harder bits, I just wanted to acknowledge all the great folks here that are being immensely helpful even though they don't have much direct code in the grin repo
:+1:
apologies to the one I forget, but @jaspervdm, @lehnberg, @tromp and many others are right in there
:smile:
in addition to the people who do contribute code on and off, which is always extremely appreciated
ok, with that off the table, let's move on to governance
the crux of the matter, is how can we be worshipped for the next thousand years
as demi-gods, preferably
in our dreams, clearly:-)
:)
that would be quite the nap
more practically, @lehnberg created a real nice document to clear up the most pressing issues:
https://github.com/mimblewimble/docs/wiki/Regarding-Foundations
https://github.com/mimblewimble/docs/wiki/Regarding-Foundations
:rocket:-ing things to the moon, or further, seems popular
I'm now thinking more and more that there's no point in trying to formalize too much right now, it's a little too close to boiling the ocean
Glad it was useful, writing it helped clear out a lot of things in my own head that was floating around.
we can let various forms of interactions emerge and keep an eye on them and wait to formalize, this seems like a much more sensible approach
so what's left is what's on that page and some other topics like disaster recovery
regarding disaster recovery, I think we should start from a similar list and see what we're comfortable with or not
so let's wait until we have that to discuss
sounds good?
until we have a disaster?
Can you give an example of what disaster recovery would be in this context?
heh, ideally before
just for clarification - you mean disaster like "libsecp is broken"?
I would say vulnerability in rangeproof for example
yes
we discover that someone exploited a weakness and created grins out of thin air
aliens teleport a quantum computer down here
or an important privacy breach in the pedersen commitments
all are good examples
so a good first step would be to list them, propose some possible fixes (rollback the chain, start from scratch, etc) and see which we're willing to consider
perhaps the possibility of a 100x ASIC should be listed in there as well, just to make clear what we would or would not do
Agree we can do that on the wiki just like the fundation page by @lehnberg .
exactly
yes, that sounds like a good approach
we discover that someone exploited a weakness and created grins out of thin air
This is quite an interesting example. cause it might for example put invisible inflation against privacy breach. I.e. to try to “fix” the inflation issue, privacy could need to be lessened.
What would be correct at that stage, might have a lot to do with what the priorities are. Control of supply (thus coin value) over privacy? Or vice versa. This is just an example, but if there is no project mission / vision / values, it might end up becoming quite ad-hoc at the time, which might lead to a lot of contention.
ok, so we can all wait for one of us to start it first and then after a year add to it :P
I guess what I’m saying is, a lot of the answers to the possible disaster scenarios outlined, will depend a lot on what this project/community is about.
yeah - I think a lot of the definition and clarity around values may emerge from this discussion
there are some more obvious ones and some less so, like a bug in the wallet that results in unspendable coins for example
that's not necessarily grin, but it still somewhat is
@lehnberg correct, and there are measures we may not be able to take anyway
okay, so we can progress on that as well, now going back to foundation-like topics, at this stage I think we shouldn't pay too much attention to the legalese
is the issue tracker a good place to introduce and discuss disaster scenarios (ie each one in separate issue) ?
unless someone strongly disagrees
liability is going to be very limited until at least 6 months in mainnet
@tromp the doc repo might be better
@tromp I for one would appreciate using issues even for non-dev stuff.
possibly somewhere where it’s not in the way for regular dev.
@tromp I'd agree with @quentinlesceller, start with a doc and then if there are some code implications on grin, create issues
which legalese do you mean? Or do you mean shouldn't worry about legal issues in general?
issues in the doc repo?
We just have to open issues
issue tracker might make discussion easier
not sure if that's the best though, but better than in the main repo.
to seoarate things for those not interested in 'politics'
@yeastplume mostly what's listed in the foundation doc, legal protection, legal representation
I'm concerned they'd get lost or buried under unrelated issues - and would get stale as they wouldn't necessarily be actionable immediately
@tromp I liked the approach of a doc and a link to a thread on the forum
problem with the wiki is that there is no easy meta-discussion functionality where you can talk about the contents and edits. we tried to link to a grin-forum thread to mitigate.
yes, what @antiochp says, triage isn't always simple...
'liability' would be tied to the general appetite of anyone affected by any grin-losing technical issues to try and sue somebody, which will in turn be directly related to grin's market value
and it's a wiki, we can easily accept named notes at the bottom of the page
@ignopeverell doc is fine as long as it's clear where to join in the discussion
I'm voting for doc + forum
@yeastplume that's one example, but I would point out that 1) it's never been done so might be premature worrying about it 2) it's also premature from a timing standpoint
that's probably not a concern until we hit an issue at least as large at what Ethereum has gone throught, don't you think?
regarding foundations etc, personally I’ve started to appreciate the absence of “official” entities. it’s a feature of the decentralized system, not a bug.
true, but I wouldn't want to keep it on the long finger forever, speaking as someone who's public (not that there aren't a zillion other coins made up of mostly public members)
we can only dream of having a problem that large...
also, as @tromp pointed out on grin-forum.org, my anonimity can be used to diffuse some of this
lol - @yeastplume takes the fall for whatever happens
Agree with @lehnberg here
:smile:
@yeastplume in the short to medium term, I won't hold it against you if you just say "that was igno's idea" when someone gives you $h1t
I was not initially in agreement with @lehnberg after reading through that doc the first time but after thinking about it a bit more I'm leaning toward being more in agreement
@yeastplume In that case, are you concerned with legal stuff ?
@yeastplume and there are quite a few coins with very identifiable entities
Meaning some kind of foundation that will protect the devs ?
@ignopeverell that's not necessarily a watertight defense if things go really wrong though
devs are protected if final authority rests with anonymous entities
@antiochp it's a complex issue and nothing is water tight
I'm a bit concerned in the case igno disappears @tromp
no I know - being facetious there
Not overly concerned at the moment, and having clear policies as to what would happen under certain disaster scenarios would go a way towards mitigating that, but I don't think we can hold these issues off indefinitely.
that is a prime calamity to consider
@quentinlesceller then you'll just have to migrate to an anonymous persona, just say you're Tom Elvis Jedusor :P
and I'm french so it fits well
even if leaders were not anonymous, there is no profit model here. nobody is making money by luring in innocent people and ripping them off.
free lunch!
@ignopeverell are you eating well? taking care of your health? getting enough sleep?
for example, I'd cite this p2p sharing company, forgot their name (emule? edonkey?), the RIAA was so ticked off they sued the company, and then the founders and every single investor personally
so much for limited liability...
it’s hard to become liable when there’s no dev company profiting, there are no six figure foundation grants etc
@tromp asking the real questions here
so anyway, not living in the US is a good first step here...
@tromp I'm pretty healthy I think, exercising regularly and all :-)
sorry, can't share a medical
I think perhaps in the first instance, some kind of EULA (for lack of a better word) might be in order... by using this software you agree.. etc.. though is that really enforceable and counter to the spirit of the thing, etc
that's very good news!
(using ominous 'qoutation marks' is also supposed to help, maybe against libel laws)
I think the biggest risks/downsides with a relatively anarchic approach is that things might take longer. Things might not always get done. Might not always get done well. And it’s just a bit more disorganised and fewer people are accountable for performance.
@yeastplume I think it's totally fair in the first year to have some "at your own risk" on the website
just throwing this out for discussion - do we gain anything in the theoretical situation where all devs are anonymous?
@lehnberg yes, that's the drawbacks of open source generally, but comes with tremendous advantages, at least in some cases
(typically Swedish to like Föreningar. Ok maybe I'll shut uo already...)
you lose ability for devs to give talks
@antiochp a little bit, probably not much
yeah - there are a load of downsides, just wondering if liability issues are "solved" with something like that
I'd personally lean towards having a group of people setting development priorities, while still allowing others to pick up and join on whatever they want
@antiochp anonimity of lead dev is very useful. having more anon devs means you have backups in place
if I had to weigh liability risk, one of use living in a country that would forbid anonymous coins would likely rank higher
but even then, most non-authoritarian countries don't go after developers
@ignopeverell
for example, I'd cite this p2p sharing company, forgot their name (emule? edonkey?), the RIAA was so ticked off they sued the company, and then the founders and every single investor personally
so much for limited liability…
Yes exactly. Meanwhile Bram Cohen got away with Bittorrent cause he open sourced the protocol and gave it all away for free. This is a great read for those who are interested: https://medium.com/@jbackus/resistant-protocols-how-decentralization-evolves-2f9538832ada
@apoelstra has never touched the grin codebase (and I believe has stated as much) for similar concerns, for example (I may be mistaken here though, apologies if so)
thanks for the link @lehnberg
@yeastplume that seems feasible, which form would you envision that in, some sort of high level roadmap?
well, on that point I'd be happy with an 'EULA' at launch put together by someone who might have some sort of clue legally (whatever that means)
@yeastplume makes sense.
@yeastplume read the ASL license at the root of our source tree? :smirk:
@yeastplume do we have someone legally knowledgeable here ?
@ignopeverell on the setting priorities point? Yes.. a roadmap would be a good start... but beyond that, for instance if the team gets more than one paid developer, who ultimately tells them what to do?
this EULA should apply to what segments? grin-tech.org
IANAL but I'm fairly familiar with the legal issues surrounding open source projects, licenses, trademark law, copyright law, patent law a bit
@yeastplume who tells you what to do?
me, but that doesn't necessarily scale to n paid developers
🐈
Monero governance: https://medium.com/@dhsue/an-analysis-of-monero-governance-3f8bef770b29
Their core team act as “stewards”, and their definition is quite interesting: https://getmonero.org/2018/03/01/core-team-announcement.html
I don't think we should go too far into dev babysitting, that goes more in the corporate model and less open source
which doesn't preclude help and guidance
@yeastplume depends on who pays
sections 7, 8 and 9 starting here:
https://github.com/mimblewimble/grin/blob/master/LICENSE#L144
https://github.com/mimblewimble/grin/blob/master/LICENSE#L144
@hashmap that gets contentious quickly
we can reproduce a slightly shortened version of that here and there
if someone with a pile of cash pushes for specific features to be built - does that affect the roadmap? should it?
not babysitting.. guidance definitely.. and who decides who can be a paid developer or not, and who decides when a paid developer isn't pulling their weight and shouldn't be a paid dev any more?
Afaik, the core team elects new members to the their team themselves, but are not the ‘bosses’, and no central point of failure. This hopefully makes them quite sibyl resistant as well as they are known figures. Nobody decides what gets built, so in a way there’s nobody to blame for that either.
and who decides who can be a paid developer or not
In my mind, the dev herself.
regarding DAO disaster. let's make clear we do not bail out any buggy scriptless script, no matter what:-)
and who decides when a paid developer isn't pulling their weight and shouldn't be a paid dev any more?
In my mind, the people who choose to donate (or not)
@antiochp that should be the same as every open source project, a pile of cash can get the job done, not necessarily accepted, the team would decide on that
@tromp Let's create Grin Classic
I agree with @lehnberg here
Agree with @ignopeverell here, it's totally okay for someone to be paid to contribute. The team decides if it worth integrating it or not in the end.
@quentinlesceller or rather somebody has to fork Grin
I personally do want as many developers as possible here to be paid for their work
in my mind every one of you deserve it and then some
@antiochp yeah I think the main crux is ‘who decides to merge a contentious feature’. And this is where things tend to grind to a halt when it comes to Ethereum and Bitcoin as well… Meaning, if enough time passes, it will inevitably be the case that there will be contentious features. And how are decisions then made?
Right now that would be @ignopeverell, but what if he disapears?
maybe public meetings, Zug style
anomymity in numbers
so one option would be for many individual devs to fundraise individually?
I can only think of 2 models here, bitcoin where nothing happens if there's no consensus, Ethereum where there's a core team that decides
@lehnberg have a project mission statement and debate whether contentious features align or not with it?
Yeah, @kargakis. That certainly would help.
:arrow_up:
otoh things may change in between
I'm thinking about funding vs merging contentious features as two orthogonal concerns but maybe they are more tightly linked
@antiochp there are many options, we haven't gone to that part yet, but OTOH either fundraise individually, we have some sort of common funds to pay some devs, or find employment with a company interested in grin that pays you to work on it
what if Jedusor's tor hidden service vomes back? maybe good to agree ahead to ignore any such events, and have defined reasoning why
@antiochp they are not orthogonal, sadly, as if you have more resources, you can lobby and push for things potentially much more efficiently.
I'm thinking that once we're done with this and the "what when shit happens" doc, we'll have a clearer view on dealing with most contentious issues
perhaps GIPs (Grin Improvement Proposals) could be decided by consensus of core devs after sufficient discussion with community, with ignotus having veto rights, and 2/3 majority consensus
@lehnberg true, what people often don't realize with open source is that just doing things gives you a lot of power
but is that an issue? I'm not so sure
@sesam we're way past jedusor I think so that likely wouldn't be such an issue, thankfully we don't have a Satoshi
grin-affiliated domain owners going random on Twitter. policy for/ against politicking?
@sesam oh?
I'm somewhat interested in separating code and politics. hard, though.
Personally (speaking from experience) I like the monero forum funding model for specific developers/tasks. We'd still need to figure out what to do with central funds, (voluntary mining contributions or fair mining contributions)
(code also might become law at some point)
okay so what we have for now
- Doc about major failure scenarios and discussion on how we deal with them
- Point out what our license says here and there so it's more obvious (like on binary download for example)
- Some high level roadmap, I can do that for now obviously with feedback from people here
Sounds great
now as @yeastplume mentions funds, let's explore that a little
big enough chunk to start with
there are things we will need to finance, some small (website, maybe some build infra, etc)
part of central fund might go to bug bounties
and some larger, like bug bounties like @tromp mentions, or security audits
I'm still hoping we can get academic reviews as well, which we wouldn't have to find funds for
good to make a large enough, specified, wishlist
and maybe a good public acknowldgement system would go a long way as well
in terms of funding, I think it was @hashmap that mentioned that someone had suggested that a mining pool could have the opt-in/out option to donate a certain % of proceeds to a central fund
a lot security companies need to be able to clame public audits of high-visibility projects
yeah, it was Karthik Raju
yes, so for the source I'm thinking:
- the tromp fair mining license
- push forward services that redistribute some minimal profits (pools, exchanges, etc)
- general donations from helpful people or companies
now say that goes to a big pot, we can finance some of the project stuff
Are we planning to have another website or a we staying with grin-tech.org ? In term of public acknowledgement
I don't think we can promise any sort of regular pay from that for developers, so I think the @yeastplume style fundraising will still have to be around, although if we have enough money that pot could fund that directly
+1 for a less technically targeted site in addition to the existing grintech
but I was also thinking more about "bonus" distributions if we have more than we need for project-stuff
@quentinlesceller I think so yes, once we're ready for it
ok
any reaction regarding what I just mentioned regarding funds?
PRs with :tada: might qualify for bonuses once merged
what would be a 'bonus'? Perhaps using excess funds to fill up developer campaigns?
or lambos for all?
I think its hard to visualize what funds from 1+2+3 would feasibly add up to in the short to medium term
I was thinking more of a general distribution
yes, so for the source I'm thinking:
- the tromp fair mining license
- push forward services that redistribute some minimal profits (pools, exchanges, etc)
- general donations from helpful people or companies
This sounds good. And generally, I think less is more here. The moment there’s an open ended pool of money, the issue becomes how to spend it. The better we can define how money is to be spent, the less headache there is around managing it.
I agree @ignopeverell, mentionning service that follows the fair mining license is a great idea. It's in everyone's interest.
Donations might go a long way, if there is a healthy community.
Seems to have worked well enough for monero
yes, I've had various people/organization contacting me to say they'd contribute
There can be “grants” made available for devs for example
I think we just need to make sure people think about what would seem fair to them
Say a company wants to donate $x,000. Well they can fund a developer for six months with that, and then developers can be invited to apply for the grants.
and taxes
the part I find tricky is say you have a yeastplume, and antioch and someone who's paid part time to work on grin
the first is paid through donations
@lehnberg the problem with that is that can become very unsteady work
then what's fair as fair as distribution?
I think its hard to visualize what funds from 1+2+3 would feasibly add up to in the short to medium term
At the moment, I don’t think there’s a clear definition of how much funds is even needed in the short to medium term.
a company might fund some dev directly. Loyalties follow
@ignopeverell distribution of what?
some funds
well, what funds?
grins
where did it come from?
donations from mining for example
yeah @ignopeverell I'm not sure there's any way to fairly distribute - what would it be based on? LOCs? Tenure? Random?
Yeah… I guess if there’s a technocratic council, and part of the council’s job is to oversee the funds coming in from mining, then it would be up to them to make it work
well, you can estimate how much work each dev is doing more or less
the issue is we can't ask mining pools or miners to follow the project closely to a point where they fund people individually every time needed and prioritize, etc
for funds allocated for dev purposes
@kargakis I'm not convinced you can - in any "fair" way
@ignopeverell yes, it’s tragedy of the commons in a way
free-rider dilemma
at least not fair and objective
(for some definition of "fair" above)
yes, it's very difficult to estimate how much work a dev is doing... there's a lot of thinking and learning involved in everything that doesn't necessarily show up in LOC counts
let tromp decide? :)
only some of grin users will donate, but all will reap the rewards
@lehnberg contributing monetarily isn't free-riding, at least it's a contribution, but we can't ask a lot of attention in addition
its not the amount of work that counts though - its how much value it actually adds
exactly
if i decide it all ends up as bounties:-)
I don’t think there is a fair way of determining how much work went into it
might be fair that way
another funding mechanism, which I’m not so sure makes a lot of sense, I thought of, was some kind of optional “annual membership fee” to the “Grin association"
bounty of well defined ahead of time
we could say decide an amount every quarter and split amount committers, but that's unfair to non-committers
ok, let me rephrase this - you can estimate how much value is added by contributions
you pay some grins, and it gives you a right to participate in something
and that applies to any kind of contribution
community votes (non-binding) etc
signal had a PR merge bounty, 0.1BTC or so. long ago...
ok, so before we go too deep in how to distribute, everyone is in agreement with sources of funding, some sort of pot (still have to discuss who can move that) and using it for the project, with some redistributed to contributors judiciously (like don't bankrupt the project)?
+1
yeah no disagreements here
Agree
I'm not a big fan of community votes, that's going to leave all the gnarly complex work even more unrewarded
Completely in agreement
:+1:
phew, didn't expect to go that far
as long as central fund is small (< $100K), paying contributors according to efforts will work reasonably well. it's when the fund swells to millions that you will run into political troubles
Yeah, and I’m a bit worried...
indeed
there’s a lot of admin that comes with it.
and a lot of contention.
not sure what the alternative is though
Multi sig everything
let’s solve 100K problem first:)
multi-sig is good to solve the "pot of gold control" issue, but not necessarily allocation
🍍guy
heh
my ideal scenario would be to only collect money centrally for pre-defined purposes
never to a “slush fund"
+1 for predefined
Yeah that would avoid sitting on a huge amount.
I agree it would be the ideal scenario, but that's not reality
does anybody know how that’s been working out for monero?
(is that even how they do things?)
@lehnberg I think we have that in the 'forum funding' parts of the model, but if grin is successful we get a large amount of non-earmarked funds from mining, etc
I wouldn't necessarily use monero as an example, they've had a huge issuance very early on and quickly haven't needed much external funds
not a pre-mine, but not entirely too far
I don't believe Monero has a centrally managed slush fund. Think everything is purely donation based for individual proposals
and times have changed as well
True, what worked for them might not work for Grin
So yeah, maybe very clear rules for how to keep that slush fund from growing into a headache, i.e. making sure it gets spent often enough
we know there will likely be multiple millions of dollars allocated to mining grin from early on, say they're all nice and want to contribute 5%
if fund>lambo: big hackathon/party announced
it’s very tricky tho huh. the moment you start paying people on a fixed income, you expect accountability
prefer just from fast
@lehnberg I don't think we should do some fixed income
just a few beats away from mid-level management haha
bounties for critical bugs (that could collapse all grin value) might justify receiving majority of fair-mining-funds
as @yeastplume mentioned, I think developers should still handle their own fundraise ala monero
that's how you eat and get vodka on an everyday basis
but is this going to work forever and for everybody?
but I think it's fair to have some way to reward good people and vest them more
no, definitely not fixed incomes... my grin funds are treated like billable hours for any other contract work
okay so maybe it’s better to start in the other end then: first define how much money is expected to be needed
@tromp agreed
and for what
and based on that define allocation of whatever money comes in
so we keep on order of 100K to reward code contributions and reserve all rest for bug bounties?
At least we can foresee that we will need a security audit
@tromp likes his bounties
@lehnberg but you're still trying to get back to an allocation model, which doesn't work with most mining-related revenue
or good citizen businesses
said differently, do you think the community would do a better job at allocating funds, or would they?
@yeastplume i do because they're more easily predefined in justifiable way
😬
indeed but you can't live on bounties
Has anyone thought about using a private corporation to handle some of these issues?
unless you're dog, the bounty hunter, I guess
@Crushhhhhhh for sure but that creates a lot more problems and doesn't necessarily solve the issue
so i would prefer to see donations sent directly to developers rather than a central fund
said differently, do you think the community would do a better job at allocating funds, or would they?
Not sure I follow, but if the community allocates funds, there’s fewer management issues.
we may get a popularity contest in result
yes.
donators might be more at ease knowing whom they're funding too
so Grin Mining Inc. raises $5M in a grin mining farm, they want to make sure the project doesn't die in the first year, so want to give away 5% of profits, what do they do?
Maybe we should some kind of buckets and fill them by order of priority with the funds (bug bounties, dev...)
they contact the technocratic council
and work with them and the community to come up with a productive way to spend that money
yeah I like @ignopeverell idea about multisig wallet
heh heh, @lehnberg that's about the same thing, how does the technocratic council decides?
say, an anonymous donor might prefer donating to someone working anonymously
Grin Mining Inc. looks at The list of proposals (a la Monero), and funds them: https://forum.getmonero.org/8/funding-required
well the technocratic council is the technocratic council for a reason. so I guess they decide the same way you, the technocratic council, decide today
but who decides on the makeup of this council as the project grows?
my interpretation of your process is some kind of consensus effort, then maybe voting,and then ultimately an igno veto
the same way as today
the council decides
but the council might be bound by a document
today had no central funds
some kind of mission statement / constitution call it whatever you like
the trick is that member of that group are also receivers of funds (partially) - if they can’t reach a consensus nobody gets paid
I guess what I'm getting at is what difference does it make with getting the funds in the same pot as bounties/project needs/etc if the council decides anyway?
it will be interesting to see what happens the first time we have an unpopular igno veto
it still boils down to people. and politics. sooner or later. unless defined ahead
GMI donates either to existing dev whose work they really like (e.g. Yeastplume) or to new one that has a promising dev proposal which they somehow trust
but does GMI care at that level of granularity or do they care more about the project as a whole succeeding?
@theodoricthegreat that's very unlikely to work the majority of Grin Mining Incs out there won't bother
what @antiochp says
or do they want to control the project and drive it via funding?
I guess what I'm getting at is what difference does it make with getting the funds in the same pot as bounties/project needs/etc if the council decides anyway?
Good question. I’m not sure. A lot will depend on the degree of transparency, due process, and perceptions here.
we have to consider contributions from donors who don't actually care about much more than their bottom line
right now people are contacting me to say "hey, we're going to do X and Y and we'll donate some to the project"
don't those ppl trust you to find a proper allocation?
my answer to that is rather inadequate...
from a practical level, I have had quite a few people ask how they can donate to help the project succeed, and if someone is there and wants to donate, you need to strike while the iron is hot and not put barriers up in front of them before they can do so
some GMI will want goodwill too, and to avoid "taking a stand". Sports sponsorships are sticky.
their definition of success may differ from others definition of success
@tromp perhaps, but before any actual allocation it's hard to tell
what @yeastplume said too
Agree with @yeastplume
Okay. So listening to this, what y'all are saying is basically it makes sense to have a collection hat ready to accept donations whenever they present themselves.
and conditions are “hey you donate, but it will be up to the grin project to decide how to best spend it, not according to your personal interests or affiliations"
@sesam I don't think we're saying we want to constraing their choices either, if they're more comfortable donating toward specific developer projects, they can always do that
…and then the techno-council can decide? and the techno-council is up for that?
are you? :-)
@ignopeverell to your example earlier - are you treating those interactions with potential donors as with you personally or with you as the leader of the project? At what point does the larger Grin community get involved?
The point that GMI won't be granular enough to donate to individual projecst makes sense
how about giving GMI and other people the option to donate to
- A general fund that is allocated by Grin Foundation or Grin DEvelopers,
- Specific projects
@antiochp sadly, no one has offered to throw money at me yet, so I had to return my Volkswagen
general fund can also allocate to specific projects/proposals
I think I’m up for the techno-council to decide on a central slush fund, as long as there’s not inaction that allows that slush fund to grow to a massive amount of money. And as long the techno-council is up for dealing with all the admin involved with that.
@antiochp so it's all been people trying to find way to contribute monetarily to the project, not necessarily right now but in the near future
Might be the first permanent staff member of the project to be honest, some admin person that can manage all this stuff and ensure money gets spent and communicate transparently about it to everybody.
yeah - not saying you're sitting on secret contributions :smile:
I guess it's just that my email is on my github page and it's easy to send an email...
you are using email? shame!
@kargakis what should I use?
pigeons
fire signals
that would solve a lot of problems
(BTW - s/mime is considered harmful)
so everyone is ok with "individual developer campaigns, possibly some prject-related fundraise, and a techno-council for all unspecified donations?"
I think its a good starting point
And bug bounties
But yes we have to start somewhere
yeah, think that's okay for now
yep.
sounds like a good start
right, so I'm thinking the techno-council will have to start allocating some pots for bug bounties, reviews, etc
and we deal with the fallout of a disagreement on the council as it occurs
@ignopeverell is wise as King Solomon and will be mediating
yes, we need enough people and dispute resolution but we'll get to that
“Split the chain in half!"
I'm proposing we start with a techno-council made of the all the current committers (so 5) and first thing we do is identify some more people
I'm thinking ultimately a dozen people would be a good start
get them from Lobby, maillist and forum
for sure
And those are: Igno, Antioch, Yeast, Quentin, Hashmap -> Correct?
yes
some non-devs to balance
absolutely
everyone in that list is ok being part of this btw?
sure
as long as I don't have to take minutes for any meetings
yep
yeah
then we can decide on a subset for the multisig maybe, with agreement than nothing should move without some council agreement
or something like that
ok cool, @antiochp will take minutes for the next meeting
lol
yay
that's what we have gitter for I guess
Sure to be part of this
indeed
ok, I'll write something up on grin-forum first to get some discussion and make sure it reflects everyone's understanding
Sounds good
good show
thanks. gotta go now
Was is the longest Grin meeting ever ?
ok; off to bed
nice one. good discussion
g'night , all
night
Good night everybody
Night!
anyone wants to yell some violent disagreement at this point?
ah, everyone to bed, ok then!
too late
I DON'T
Lol
is that meeting too late?
too late to yell:)
excellent then!
Could be an hour earlier but I’m fine with the time anyway
I'm temporarily in their timezone.. it's 1AM now
oh...
same here
if any of you want to move it earlier, please say so with some time proposal
we'd originally intended 9 GMT, which became 9UTC which became 10 GMT and 11 CET
so 7 UTC?
exactly, but winter is comming
6 UTC?
The timing is not euro friendly for now
@yeastplume picked the 9 GMT at least
(not to point fingers or anything)
9 GMT with daylight savings adjustments
are all our countries doing daylight savings?
for 1 hour meeting time is fine
Yes both Canada and France
1 hour meeting at current time is fine
all our current ones, let’s say
okay, we can try to stick to 1h, this was just progressing more than expected