- MRL 已有可運作的多筆交易輸出的bulletproofs的java測試程式碼了
- 目前正在轉換為C++的版本(不包含多筆輸出的部分)
- 此技術對於手續費架構的影響也在研究中(輸出筆數若很大量可能會造成DoS)
- 單筆輸出的bulletproofs大小約略是704bytes，雙筆輸出則是768bytes左右。而依照目前門羅幣現行的版本，單筆輸出的大小是6k，雙筆輸出則是12k。
- 多數的bulletproofs在測試時平均大小約為2.2k
- bulletproofs可能會包含於門羅幣的2018九月硬分叉
- 供測試網路使用的版本可能會在一周內完成
- 為了準備發布新版本，程式碼將會在本月(2017十二月)底凍結
- Surae Noether 的multiSig植入工作已經差不多完成檢查
- 程式碼凍結時預計會包含到multiSig (因此multisig也會出現在下一發布版本中)
- 若有開發者對multiSig的開發方向和程式碼有興趣，現在是最好的時機到github上看看
- ZeroMQ(0MQ) 也預計會出現在下一個版本中，但此刻還有缺一些功能
- 依然在研究是否可以把門羅幣的亂數生產器(Random Number Generator)換成比特幣用的版本
以上翻譯來自於紀錄原文: https://monerobase.com/wiki/DevMeeting_2017-12-03
完整會議紀錄：
fluffypony> 1. Greetings
fluffypony> 2. Brief review of what’s been completed since the previous meeting
fluffypony> 3. Code + ticket discussion / Q & A
fluffypony> 4. Any additional meeting items
fluffypony> 5. Confirm next meeting date/time
fluffypony> so 1. Greetings
fluffypony> hi
ArticMine> Hi
iDunk> o/
fluffypony> luigi1111 (if you’re back) / smooth / hyc / moneromooo etc.
moneromooo> here
gingeropolous> etc here * hotoatmeal watching * WWW-XMRTalk-Org| (b84bd44d@gateway/web/cgi-irc/kiwiirc.com/ip.184.75.212.77) has joined
fluffypony> 2. Brief review of what’s been completed since the previous meeting
Slack_3>
serhack> hi :slightly_smiling_face:
fluffypony> lots of stuff
sarang> MRL has working Java test code for complete multi-output bulletproofs
sarang> It’s being ported over to C++
moneromooo> (not the multi output one)
sarang> The Java part is complete
moneromooo> Sorry, I meant just about the port ^_^
sarang> Discussions are ongoing about if/how the fee structure would be modified to prevent large-output txn DoS
fluffypony> what’s wrong with per-byte fees?
sarang> You can load a txn with tons of outputs
sarang> but verification is linear in the # of outputs
dEBRUYNE> fluffypony: verification is linear, whilst size is log
dEBRUYNE> basically
sarang> So for low fees you can force the network to verify
fluffypony> ah ok, makes sense
sarang> So we need to incentivize the use of aggregate BPs while basically scaling the fee to the number of outputs etc.
sarang> But things are looking good
sarang> Verification is still quite efficient
sarang> and with the multi-output setup, space savings are unreal
moneromooo> In fact, the per byte fee needs to be done first, as per kB is way too coarse for this.
sarang> Yeah a single output BP is about 704 bytes, while a 2-output BP is something like 768 bytes
sarang> (including commitments)
sarang> it’s just too damn good
fluffypony> nice
dEBRUYNE> For clarification, a single output is currently ~ 6 kB, whereas a 2-output is ~ 12 kB * hotoatmeal was about to ask
sarang> So we’ll continue moving forward with porting and testing
manifest> serhack here?
dEBRUYNE> A typical Monero transaction has 2 ins + 2 outs
Slack_3>
serhack> yep manifest
manifest> i was wondering who was the m8 that was gonna work on the go-library since i started on it myself a little bit swell
fluffypony> dEBRUYNE: this would also be a major cost-saving for pool payments
fluffypony> manifest: we’re in a meeting
sarang> For reference, the size of an M-output BP is 32*(2*log(64*M)+9) bytes (this doesn’t count the amount commitments)
sarang> add 32 bytes for each of the M amount commitments if you want to include them
sarang> (log is base 2)
Slack_3>
rehrar> manifest you can hop on mattermost.getmonero.org. Serhack is also there and you guys can PM and chat so as not to disrupt the meeting. Thanks. :)
ArticMine> I have to give some thought to the fees to deal with the verification issue
fluffypony> ok so beyond BP is there anything else worth noting?
sarang> We do require a power of 2 in the # of outputs * Gdhhyfjjs467 (adf42c28@gateway/web/cgi-irc/kiwiirc.com/ip.173.244.44.40) has joined
pigeons> So sometimes you just create an additional change output, or how do you cause always a power of 2?
sarang> We’ll need to either pad with dummy outputs or split into power-of-2 proofs
ArticMine> Split the change into two tx * WWW-XMRTalk-Org| has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
pigeons> OK
sarang> The dummy output doesn’t need to actually represent anything
sarang> It just needs to be there for the proof
sarang> It can be amount 0
ArticMine> that will work also
sarang> Anyway, that’s my 3 cents
luigi1111> Better to split
luigi1111> Space is cheap gp
luigi1111> Cpu is expensive*
ArticMine> We will have to price cpu
moneromooo> There’s a possible optimization for “filler” outs AIUI.
luigi1111> Probably not as good as not using them :)
sarang> There aren’t any security proofs for a non-power-of-2 proof
moneromooo> I was led to think it was not inherent in the scheme, though ?
sarang> It is
moneromooo> aw…
sarang> At least for right now
sarang> There’s a recursive step that split arrays in half
ArticMine> The issue I see is that the penalty only prices space
sarang> The authors of the paper are looking into a generalization, but it doesn’t exist yet
luigi1111> That’s interesting
fluffypony> ok so
fluffypony> anything else from the last two weeks worth noting?
sarang> suraeNoether is completing review for multisig
sarang> He is unable to be here today * amiuhle (amiuhle@206.223.178.27) has joinedblasty@shadowbroke.rs) has joined
Gdhhyfjjs467> Has a code freeze date for the next for been set yet?
fluffypony> Gdhhyfjjs467: yeah we’ll be branching towards the end of the month
fluffypony> assuming our comfort levels are ok
Slack_3>
rehrar> This was discussed briefly in MRL channel with the idea that if BPs are not too far off, would it be worth delaying the next hard fork by a couple months so it can be in?
dEBRUYNE> The plan is to include multisig right?
dEBRUYNE> ^ fluffypony
luigi1111> Yes
fluffypony> no need to delay the hard fork
luigi1111> I don’t think the upcoming fork does anything useful though
luigi1111> So there’s that
fluffypony> if BP is ready it’ll go into the Sept fork
dEBRUYNE> Should we fork if there’s nothing to fork for?
luigi1111> Who knows ^_^
fluffypony> luigi1111: consistency, then
fluffypony> well, that’s what we committed to with the fork schedule
fluffypony> “even if it’s just bumping the block version number”
dEBRUYNE> Sure, but didn’t we also discuss slowing things down once the ecosystem got bigger?
moneromooo> We did not commit to an exact fork schedule.
luigi1111> And who is this we :)
moneromooo> I, at least, did not :P
hotoatmeal> does the wallet release schedule track the protocol fork schedule exactly?
hotoatmeal> or do they have different cadences
moneromooo> The wallet needs to update for a fairly large subset of consensus changes.
pigeons> the wallet-cli and wallet-rpc are included with the daemon release that supports the fork
moneromooo> So it’s convenient to release at the same time.
fluffypony> dEBRUYNE: I don’t think we’re at a point where we can go to annual
moneromooo> Besides, the wallet and daemon rely on the same libs.
Slack_3>
rehrar> Isn’t ZMQ also in the new release? Or has that been there for a while now?
fluffypony> yes ZMQ is in the new release
moneromooo> There’s some of it in, but some of it’s still missing.
pigeons> there is some support for zmq over rpc, and more is comming, like tx/block notify and some changes to the existing zmq rpc * cialu has quit (Ping timeout: 240 seconds)
pigeons> *rpc over zmq
hotoatmeal> moneromooo: yeah, mainly thinking about when I need to spend time to get those two memwipe patches (and the third I haven’t written yet) reviewed/merged
pigeons> the notify is what the people i hear from are waiting for, and tewinget told me a few weeks ago he’s got the basics worked out
Slack_3>
rehrar> Are we still waiting on him for stuff?
moneromooo> There’s a patch waiting on changes IIRC.
moneromooo> (for 0mq)
Slack_3>
rehrar> *sigh* tewinget, can you please get this stuff done? Seriously.
moneromooo> Especially as I think some of the large pool speedups were lost.
moneromooo> (not 100% sure)
hotoatmeal> is there a way to detect that the network has forked, and your client hasn’t gone with it?
moneromooo> Kinda.
hotoatmeal> my local daemon got left behind on the last one, because I forgot to update
fluffypony> you can make an educated guess
hotoatmeal> cue colorful headscratching
moneromooo> Current daemon should moan if it sees blocks with a higher version than what it knows about.
fluffypony> and there’s auto-update records that notify
moneromooo> The block verison thing is a bit vulnerable to someone mining a bad block on purpose to make you think there’s been a fork though.
fluffypony> yeah
moneromooo> Losing 10 monero in the process or whatever it is :)
fluffypony> ok let’s move it along, then
fluffypony> 3. Code + ticket discussion / Q & A
fluffypony> are there any issues that could do with some input / resolution?
moneromooo> The handful of oldest ones.
moneromooo> The PRNG one.
moneromooo> ones.
moneromooo> For multisig, I think it’s pretty much ready to go in, stoffu’s done a lot of careful reviewing.
fluffypony> ok - what’s the blocker on switching to the Bitcoin one?
hotoatmeal> moneromooo: what still needs doing / deciding on your part of the memwipe ones, and how can I help there?
moneromooo> Mainly deciding whether we want to, or not.
moneromooo> And bitcoin has two RNGs, the one I ported, and one that’s closer to what we have. so there’s the possibility of entropy attrition using only the “good” one.
moneromooo> hotoatmeal: the only thing left IIRC was switching from std::vector
char> to std::unique_ptr
char[]> and I feel more confident getting it right with vector.
moneromooo> Other than that, nothing I think.
fluffypony> moneromooo: by “good” one you mean the ported one?
moneromooo> That can be done later by someoine who’s familiar with how the refcounting works with operators though.
moneromooo> Yes. The one that uses getrandom, etc. * Gdhhyfjjs467 has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
fluffypony> ok so I think if they haven’t hit entropy attrition problems over the past few years it’s unlikely we will - thoughts?
moneromooo> Let me rephrase:
moneromooo> Bitcoin has two RNGs: a good one using HW, and a… hmmm, less good ? one similar to our keccak based one
moneromooo> Using the keccak based one does not deplete entropy nearly as fast as using the good one. Monero can use a lot of entropy (eg, range proofs).
moneromooo> Therefore, I’m wondering whether using the good one all the time is worse than not.
hotoatmeal> moneromooo: ok, I’ll pick up the vector vs unique_ptr part of that later this month
moneromooo> Thanks
fluffypony> ok so what if we used the good one for critical stuff like privkey generation * Gdhhyfjjs467 (adf42c28@gateway/web/cgi-irc/kiwiirc.com/ip.173.244.44.40) has joined
fluffypony> and output selection
hotoatmeal> and if you give me some pointers, can look at whatever that refcounted operators thing is in Jan
fluffypony> and the stream one for range proofs
moneromooo> Well, if I knew that, I’d know the answer to my question, since they’re opposites.
moneromooo> Anyway, to go back to multisig, I tihnk it’s good to go now. If you haven’t yet reviewed it, and want to do so, do so now. * hotoatmeal drops out
fluffypony> ok
fluffypony> 4. Any additional meeting items
moneromooo> When do we want bulletproofs on testnet ?
dEBRUYNE> Tomorrow!
fluffypony> hah hah
moneromooo> A day may be a bit short to get people to update in time.
fluffypony> are we going to wait for the multi output stuff?
sarang> I think we should
moneromooo> Not sure. This is not quite finished (multiple of 2 requirement), and has a non trivial impact on fees.
sarang> Hrmm true, the fee thing
sarang> :/
moneromooo> And I’d really, really like to get smaller txes double plus quick.
fluffypony> ok so how would this work
ArticMine> A lot of people do
sarang> In case it’s relevant, every single-output proof is still a valid multiproof
moneromooo> That’s nice.
sarang> (provided we define the Gi and Hi in the same order)
sarang> (not sure if my extended code addressed that, will check)
moneromooo> So, no clear votes for or against. Except me ^_^ so that’s 100% of expressed votes :P * sarang checks the math on that
fluffypony> moneromooo: I asked how it would work
moneromooo> The fork ? I imagine similar to rct. Allow bulletproofs at fork f, optionally disallow borromean at f+1.
moneromooo> (the code currently does not do that second part)
moneromooo> That might become a bit more complicated if we start allowing aggregated proofs at f+1.
moneromooo> But not very much.
dEBRUYNE> so moneromooo, you’d like to start with single output right? And then eventually switch to multioutput
moneromooo> Yes.
Slack_3>
rehrar> Sorry if this was answered, but is there an ETA on multioutput port from Java? * Huskar has quit (Quit: Konversation terminated!)
moneromooo> No. It doesn’t appear to be a lot of work though.
fluffypony> so then txs with more than 1 output would use borromean? * blasty- (
moneromooo> No. They’d use two bulletproofs.
sarang> yup
Slack_3>
rehrar> Which is still a savings.
sarang> Still great space savings
sarang> And no DoS issues
dEBRUYNE> 2 bulletproofs is 1.3 kb give or take right?
fluffypony> ok
dEBRUYNE> And we can keep our current fee structure
sarang> dEBRUYNE: yes
moneromooo> Most of it, in fact. Txes are 2.2 kB.cialu@151.41.130.127) has joined
Slack_3>
rehrar> I think that’s worth it. And then it can be enhanced even further with multioutput later. But the immediate savings would be appreciated.
Slack_3>
rehrar> And gives time for the fee dislogue
fluffypony> and what’s our confidence level like in this? like is it March-fork-worthy?
Slack_3>
rehrar> Dialogue*
moneromooo> Well, we can know better if we fork in a couple days on testnet :)
ArticMine> I have an idea on the fee issue
Slack_3>
rehrar> It can be deployed to testnet asap no.
Slack_3>
rehrar> ?
moneromooo> That’s what I’m asking about, yes.
fluffypony> could we fork testnet this coming weekend?
moneromooo> Works for me. Gives time for review.
Slack_3>
rehrar> Exciting!
sarang> Yes and the code should definitely be reviewed by others
endogenic> who?
endogenic> if you had your pick
JollyMort[m]> could someone do me a favor and send me the log of this channel from 2017-04-18?
sarang> Ideally andytoshi since he’s a paper author
moneromooo> If I had my pick…
sarang> suraeNoether
fluffypony> Satoshi
endogenic> fluffypony: on it
sarang> Someone who digs the maths
Gdhhyfjjs467> So Evan duffield?
dEBRUYNE> luigi1111 I guess
endogenic> vtnerd hyc fyi
moneromooo> Oh yeah, luigi1111 is a good one.
Slack_3>
rehrar> Let’s just get all hands on deck for this?
endogenic> ok that means you too rehrar
Gdhhyfjjs467> Lol jk. I like andytoshi idea
sarang> I’m sure we’ll find additional optimizations… I know for a fact my implementation of scalar operations into vectors could be refactored
Slack_3>
rehrar> I will understand none of it, but I’ll look at it and either nod approvingly or cringe based on a coin toss.
sarang> but I didn’t in Java in order to keep it clean and understandable
endogenic> i move to instate rehrar as new RNG
moneromooo> The slice op ? Yes, but I don’t think it takes much time compared to the muls.
sarang> Random Nod Generator? * cialu (
sarang> Well and operations involving many vector ops could run a single loop per element, instead of per operation
sarang> but they’re generally fast and it makes things clean * nicksname has quit (Ping timeout: 260 seconds)
sarang> I’m not a huge fan of sacrificing clarity for a tiny speedup
sarang> I’d like to chat with moneromooo post-meeting about our basepoint selection, to ease the transition into multiproofs later
sarang> For those who want to compare code to paper, this is the paper: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf * nicksname (adf43028@gateway/web/freenode/ip.173.244.48.40) has joined
moneromooo> I pushed the patch as 2883 if people want to start reviewing ^_^
Slack_3>
rehrar> Can I make a Reddit post calling devs to review it?
moneromooo> Reddit.. devs ?
dEBRUYNE> ^ that lol
Slack_3>
rehrar> :P nvm then
dEBRUYNE> The people able to review it will be watching Github
endogenic> rehrar: answer is in the question :P
fluffypony> oh
fluffypony> I guess meeting ~done
fluffypony> 5. Confirm next meeting date/time
fluffypony> Sunday the 17th