< achow101>
the results don't seem to be very impressive though
< meshcollider>
wumpus: that's pretty orthogonal I think, it's a privacy thing rather than an efficient selection thing
< wumpus>
ok...
< achow101>
I'm not sure of BnB is going to be much of an improvement over what we currently have
< achow101>
s/of/that/
< achow101>
at the very least, it doesn't do worse
< wumpus>
that's already good if it is a win in runtime
< achow101>
it actually runs a lot slower
< meshcollider>
Oh
< wumpus>
ouch
< achow101>
I noticed during the simulations that running BnB takes longer since it has to exhaust the search before it continues with the current algo
< morcos>
Should we save this conversation for when Murch can join?
< achow101>
It seems to only be faster when it can find a solution, which is not all that frequent
< Murch>
achow101: I just had a look at the results. How come that there were several hundred instances of BnB use but only one fewer change output created than without BnB?
< Murch>
I think there is an unexpected behavior there.
< achow101>
oh, that's strange
< achow101>
I will look into that
< wumpus>
thanks
< wumpus>
any other topics?
< Chris_Stewart_5>
achow101: It seems like the algo would obviously be slower if it reverts to the old algo?
< jtimon>
perhaps a short meeting today?
< achow101>
Chris_Stewart_5: yes
< meshcollider>
jtimon: yes seems sipa's talk has stolen the show today :)
< achow101>
Chris_Stewart_5: logically, reverting means that it's running more code, so it kinda has to be slower
< Chris_Stewart_5>
so the high failure rate is the main concern?
< jtimon>
meshcollider: oh, what talk?
< meshcollider>
jtimon: at bpase
< wumpus>
jtimon: yep
< wumpus>
let's review stuff for 0.16 after the talk :)
< jtimon>
oh, I'll wait for the video
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Jan 25 19:30:28 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< cfields>
kanzure: thanks a ton for that, btw. There's no wikipedia entry for BN sigs, so I always end up hitting that link when I google for the paper
< kanzure>
yep no problem
< kanzure>
really weird how a lot of this stuff just gets lost
< jojeyh>
sipa, is it possible to see these talks live ?
< jojeyh>
or even a recording i guess
< sipa>
kanzure: at RWC we ran into Neven, who sounded very excited that someone may actually use his scheme :)
< sipa>
jojeyh: there will be a recording later
< jojeyh>
danke
< kanzure>
sipa: has he reviewed the paper yet?
< BlueMatt>
jonasschnelli: yup
< instagibbs>
gmaxwell, morcos some not completely thought out discussion on fee bumping/transaction replacement #12271 . I haven't really seen a good central location for discussion, so I continue re-inventing the wheel
< luke-jr>
:o "Two new instructions (addex and vmsumudm) introduced to accelerate arbitrary-precision integer arithmetic, and specifically to accelerate Blockchain’s implementation of elliptical curve encryption signature algorithm. The OV bit is employed to provide an additional, independent carry status bit, allowing software to parallelize carry propagation."
< wumpus>
luke-jr: whoa, interesting
< achow101>
luke-jr: what is that for?
< wumpus>
powerpc 9 ISA apparently
< luke-jr>
achow101: POWER9
< luke-jr>
"Add Extended using alternate carry bit Z23-form" and "Vector Multiply-Sum Unsigned Doubleword Modulo VA-form"
< luke-jr>
"The unsigned integer value in doubleword element 0 of VR[VRA] is multiplied by the unsigned integer value in doubleword element 0 of VR[VRB] to produce a 128-bit product. The unsigned integer value in doubleword element 1 of VR[VRA] is multiplied by the unsigned integer value in doubleword element 1 of VR[VRB] to produce a 128-bit product. The two 128-bit unsigned integer products and the 128-bit unsigned integer in VR[VRC] are summed.
< wumpus>
vmsumudm seems SIMD 2x 64*64 -> 128 bit multiplication, where the two results are added to a third 128 bit value
< luke-jr>
The low-order 128 bits of the sum are placed into VR[VRT]. Any carry out or overflow status is discarded."
< luke-jr>
hopefully this is compatible with libsecp256k1's existing optimisations
< wumpus>
that seems quite useful for the kind off mult-sum operations in secp256k1 secp256k1_fe_mul_inner and such