tornadocash
/
tornado-core
mirror of https://github.com/tornadocash/tornado-core.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

add balance

This commit is contained in:
Roman Storm 2019-07-15 12:19:34 -07:00
parent 039cfa006c
commit 4817b2216e
2 changed files with 19 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
README.md
View File

@ -6,11 +6,12 @@
1. `npm i`
1. `cp .env.example .env`
1. `npm run build:circuit` - may take 10 minutes or more
1. `npm run build:contract`
1. `npx run ganache-cli`
1. `npm run build:contract`
1. `npx ganache-cli`
1. `npm run migrate:dev`
1. `./cli.js deposit`
1. `./cli.js withdraw <note from previous step> <destination eth address>`
1. `./cli.js balance <destination eth address>`
## Testing truffle
1. `npm i`
@ -40,8 +41,8 @@
* Relayer is frontrunnable. When relayer submits a transaction someone can see it in tx pool and frontrun it with higher gas price to get the fee and drain relayer funds.
* Workaround: we can set high gas price so that (almost) all fee is used on gas. The relayer will not receive profit this way, but this approach is acceptable until we develop more sophisticated system that prevents frontrunning
* Bugs in contract. Even though we have an extensive experience in smart contract security audits, we can still make mistakes. An external audit is needed to reduce probablility of bugs
* Nullifier griefing. when you submit a withdraw transaction you reveal the nullifier for your note. If someone manages to
make a deposit with the same nullifier and withdraw it while your transaction is still in tx pool, your note will be considered
* Nullifier griefing. when you submit a withdraw transaction you reveal the nullifier for your note. If someone manages to
make a deposit with the same nullifier and withdraw it while your transaction is still in tx pool, your note will be considered
spent since it has the same nullifier and it will prevent you from withdrawing your funds
* This attack doesnt't provide any profit for the attacker
* This can be solved by storing block number for merkle root history, and only allowing to withdraw using merkle roots that are older than N ~10-20 blocks.

19
cli.js
View File

@ -31,6 +31,11 @@ async function deposit() {
return note;
}
async function getBalance(receiver) {
const balance = await web3.eth.getBalance(receiver)
console.log('balance is ', web3.utils.fromWei(balance))
}
async function withdraw(note, receiver) {
let buf = Buffer.from(note.slice(2), "hex");
let deposit = createDeposit(bigInt.leBuff2int(buf.slice(0, 32)), bigInt.leBuff2int(buf.slice(32, 64)));
@ -103,17 +108,17 @@ async function init() {
function printHelp(code = 0) {
console.log(`Usage:
Submit a deposit from default eth account and return the resulting note
Submit a deposit from default eth account and return the resulting note
$ ./cli.js deposit
Withdraw a note to 'receiver' account
$ ./cli.js withdraw <note> <receiver>
Example:
$ ./cli.js deposit
...
Your note: 0x1941fa999e2b4bfeec3ce53c2440c3bc991b1b84c9bb650ea19f8331baf621001e696487e2a2ee54541fa12f49498d71e24d00b1731a8ccd4f5f5126f3d9f400
$ ./cli.js withdraw 0x1941fa999e2b4bfeec3ce53c2440c3bc991b1b84c9bb650ea19f8331baf621001e696487e2a2ee54541fa12f49498d71e24d00b1731a8ccd4f5f5126f3d9f400 0xee6249BA80596A4890D1BD84dbf5E4322eA4E7f0
`);
process.exit(code);
@ -140,7 +145,11 @@ if (inBrowser) {
else
printHelp(1);
break;
case 'balance':
if (args.length === 2 && /^0x[0-9a-fA-F]{40}$/.test(args[1])) {
init().then(async () => getBalance(args[1])).then(() => process.exit(0)).catch(err => {console.log(err); process.exit(1)});
}
break
case 'withdraw':
if (args.length === 3 && /^0x[0-9a-fA-F]{128}$/.test(args[1]) && /^0x[0-9a-fA-F]{40}$/.test(args[2])) {
init().then(async () => withdraw(args[1], args[2])).then(() => process.exit(0)).catch(err => {console.log(err); process.exit(1)});