Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 26 19:11
    hswick removed as member
  • Apr 26 19:11
    hswick removed as member
  • Oct 25 2020 17:32

    teutsch on master

    update (compare)

  • Dec 12 2019 04:03
    mrsmkl edited as member
  • Dec 12 2019 04:03
    hswick edited as member
  • Dec 12 2019 04:03
    bloodstalker edited as member
  • Dec 12 2019 04:01
    mrsmkl edited as member
  • Dec 12 2019 03:54
    mrsmkl edited as member
  • Dec 12 2019 03:54
    mrsmkl edited as member
  • Dec 12 2019 03:53
    mrsmkl edited as member
  • Nov 08 2019 07:23

    teutsch on master

    Update README.md (compare)

  • Oct 03 2019 12:42
    mrsmkl unassigned #70
  • Oct 03 2019 06:56

    mrsmkl on rollback

    (compare)

  • Oct 03 2019 06:56

    mrsmkl on rollback2

    (compare)

  • Oct 03 2019 06:56

    mrsmkl on master

    (compare)

  • Oct 03 2019 06:56

    mrsmkl on master

    (compare)

  • Oct 03 2019 06:52

    mrsmkl on rollback2

    (compare)

  • Oct 02 2019 14:10

    mrsmkl on master

    (compare)

  • Oct 02 2019 14:09

    mrsmkl on master

    (compare)

  • Oct 02 2019 14:08

    mrsmkl on master

    (compare)

James Seibel
@seibelj
OK, so the merkle path includes the leafs containing the state data itself that is modified by the instruction.
Finally, the merkle path and leaf containing the program instruction is also submitted by the solver? So the judge now has the actual relevant state at E - 1 and E, can verify that its accurate based on the state merkle root, the actual instruction from the merkel leaf and also verified by merkle root of the program, and using a TrueBit smart contract containing an implementation of WASM virtual machine, can actually execute the instruction. This is correct?
Sami Mäkelä
@mrsmkl
yeah
James Seibel
@seibelj
One more question. The reason that the solver doesn't just submit a proof with no work, and the verifier doesn't just say it's true, is that even if the majority solvers and verifiers are the same person, a single honest verifier can join and choose any and all tasks to verify (there is no lottery to determine who verifies what), so if this collusion was happening some enterprising verifier would quickly make money. Is this right?
Sami Mäkelä
@mrsmkl
yes, seems correct
Jason Teutsch
@teutsch
The incentive to verify has little to do with whether the Solver actually does work or not. Verifiers are just looking for "forced errors."
James Seibel
@seibelj
The verifier also wins when the error is just a mistake right (not the forced error)? I am not super deep into the game-theoretic underpinnings of the protocol but I do trust that all the major attack vectors have been thought through.
By the way, thanks so much for your time answering, I am super impressed with this project, I am going to be following it closely and experimenting. So cool I get to talk to you guys directly
Jason Teutsch
@teutsch
Verifiers might profit from finding "real" Solver mistakes, however, since we don't expect "real" mistakes to actually occur, they do not factor into the incentive structure. Whether or not "real" mistakes occur, the Verifier still has an incentive to participate.
It's great to have you here -- thanks for your questions! Are you building something with Truebit?
James Seibel
@seibelj
I am going to write an article similar to how I did for MakerDAO https://medium.com/@james_3093/the-dai-stablecoin-is-a-game-changer-for-ethereum-and-the-entire-cryptocurrency-ecosystem-13fb412d1e75 which got a lot of attention. When I see a super cool crypto project I dive deep. This one definitely needs to be understood in a significant way by a larger audience, and I hope I can do it justice
Jason Teutsch
@teutsch
Nice article! We'd love one on Truebit :) I'd be happy to discuss on a call if that would be helpful.
James Seibel
@seibelj
Sure! I will PM you
Moshe Praver
@mpraver1_twitter
Curious what the community thinks about this design pattern. We remove forced errors and instead rely on coordination between what would be the solver/verifier https://link.medium.com/LwIhh09vpS
Jason Teutsch
@teutsch
@mpraver1_twitter Why not just outright post the output in the first place if the applicant is going to reveal her secret later anyway?
Moshe Praver
@mpraver1_twitter
We need the verifier to derive the secret independently. If they are able to do so, this implies the hint:secret pair is valid.
Jason Teutsch
@teutsch
What do you assume about the attacker and the verifier selection? There could exist an incentive to pool verifier identities together in order to (errantly) pass verification.
Moshe Praver
@mpraver1_twitter
Yes - the cost of that attack is dependent on the ratio of “honest verifiers” to “dishonest verifiers”.
Moshe Praver
@mpraver1_twitter
We can also make this attack exponentially more costly by increasing the number of verifiers for each task.
Jason Teutsch
@teutsch
Does the protocol guarantee that the ratio of "honest" to "dishonest" verifiers remains constant over time?
Moshe Praver
@mpraver1_twitter
We can't know if a verifier will be dishonest. We can try to bootstrap the network by only making tokens initially available to well-intentioned verifiers. However, a malicious actor could try to accumulate enough tokens to pull off the attack.
The protocol can only ensure that such an attack would be very costly to pull off.
imTyrant
@imTyrant
Hi, @mrsmkl , sorry for bother you again... Recently I found that libpbc didn't meet my needs because the curves it supports are not used by ETH. Thus, I have to use another library published in https://github.com/herumi/ate-pairing. In the beginning, the emmake make command reports error: unknown FP unit 'sse', and I found a flag in the Makefile causes this. So, I delete the flag, and rebuild the code. And it reports following error. I personally think it not caused by the deleted flag. it looks like the compiler cannot find 64-bit version head file, and, instead, using 32-bit head file.
image.png
Sami Mäkelä
@mrsmkl
hmm, wasm cannot have 64-bit memory, so using -m64 flag probably won't work
Sami Mäkelä
@mrsmkl
anyway, it seems that the library generates x86_64 asm at runtime, so perhaps try libff instead
imTyrant
@imTyrant
@mrsmkl I download the libff, find that it also depends on ate-pairing. And I check the script libff.sh in https://github.com/TrueBitFoundation/wasm-ports/blob/master/libff.sh, however, the script doesn't download the dependents... like running git submodule init && git submodule update. So the script ignore this command....
And I replace the flag -m64 by -m32 in ate-pairing, the error is following.
image.png
Sami Mäkelä
@mrsmkl
libff has also another implementation for bn128, see https://github.com/scipr-lab/libff#elliptic-curve-choices
imTyrant
@imTyrant
Hi @mrsmkl , I test libff installed in docker by the code provided in https://github.com/scipr-lab/libff/blob/f2067162520f91438b44e71a2cab2362f1c3cab4/libff/algebra/curves/tests/test_bilinearity.cpp, with the command: em++ test.cpp -s WASM=1 -lgmp -lff -I $EMSCRIPTEN/sysytem/include -std=c++11 -o test.js. When I use node run the test.js, it returns following result...
image.png
What does this error mean?
Sami Mäkelä
@mrsmkl
I guess exception handling might cause problems with emscripten
but the problem is that profiling code calls some weird functions, if they are disabled, it works
Sami Mäkelä
@mrsmkl
I updated the script for libff at wasm-ports
imTyrant
@imTyrant
Oh! Thank you very much! I'll try the new script!
Bruno Barroca
@githubbrunob
cheers
imTyrant
@imTyrant
Hi, guys. How can I know how many TRUs a task needs to consume after it has been executed?
Jason Teutsch
@teutsch
We must to establish a market price for TRU, relative to the true cost of electricity per CPU cycle, in order to price a task. I believe that the Task Giver sets the price in the current implementation, but we'll need to enforce a lower bound on mainnet because underpricing a task eliminates the incentive for verification. In the long run, the task pricing mechanism must be decentralized.
imTyrant
@imTyrant
@teutsch Thank you for your explanation! Let me repeat it again. If there is a problem with my understanding, please point it out. In general, it is similar to "the market" in the economics which determines the price of commodity. Ideally, all participants, including Task Givers and Solvers in Truebit, will agree on the price of per CPU cycle, which is somewhat similar to gasPrice in Ethemum which floats around 8 Gwei. However, it seems the computational capacity still is bounded, since the total TRU consumption is related to the total CPU cycle used. is it somewhat similar to the gas in Ethereum?
And one more question, is there any tools can tell me how much CPU cycle a task will take?
Sami Mäkelä
@mrsmkl
@imTyrant probably the best is just use the interpreter to run your task, and then based on the time takes, you can estimate it's cost and how secure it is (if it takes forever, verification game might take 50x as long)
Sami Mäkelä
@mrsmkl
@imTyrant so if the transaction cost would be 1M eth gas, that might cost $0.50 and if computation would cost $1 per day, and 10 verifiers would be required, about an hour of computation would cost $1
Jason Teutsch
@teutsch
If the computation costs $1 per day, then shouldn't we get 24 Verifiers for an hour of computation at the same price?
Sami Mäkelä
@mrsmkl
@teutsch the transaction cost is included in the $1
imTyrant
@imTyrant
So... suppose a Solver solves a one-day task cost $1, then if we have another 23 Verifier solve the same task, the total cost will be $1 per hour. Am I right? But shouldn't the payment for Verifiers come from jackport instead of the Task Giver's deposit?
Jason Teutsch
@teutsch
The payment does come from the jackpot, but the jackpot is funded by the Task Giver. The Task Giver pays the Verifiers' expected reward so that the expected capital in the Jackpot Repository tends toward a constant over time. If tasks would be free to the Task Giver, this would probably induce spam. Then Verifiers could issue tasks that they already knew the answers to and get rich from solving them without doing any work. In this scenario, there is then little incentive to instead perform "real" tasks that involve actual work.
imTyrant
@imTyrant
In my understanding, what a Task Giver have to pay are 1) the reward for solving task, 2) the tax to be added into jackport repository. The reward must higher than the indeed cost of a task which is metered by CPU cycle of the task. The tax is for 1) maintaining the jackport repository in a constant value, 2) preventing some attacker from spamming. We believe that the price of per CPU cycle will be a reasonable price, compared with gasPrice in Ethereum, thus we can say the execution of complex task in Truebit is much more cheaper than in Ethereum.
Jason Teutsch
@teutsch
Yes, that's right -- the Task Giver pays both the expected Solver and Verifier rewards, which is not only much cheaper than Ethereum but also much more convenient when one plans to exceed the gas limit.