Of course, I thought about it  The attack won't work because the spend proof must be sent from the owner's address, not from any address. What is an address ? e-mail or so ? How do others checking the block chain know that this private transaction belongs to an address and how do they find out who had send what from which address ? I think I'm missing something. If you mean an address on a P2P networks, Kademlia style, then you've undone the anonymity. Because if the address of the sender is included in the block chain, then, eh, the spending history is just as pseudonymous as bitcoin (your address is associated with all you do). And it would also mean that your coins are attached to your P2P address private key. In the simplest case, address is a hash of the public key, or something similar. The validators need to check one simple thing: if there are two transactions that (1) embed the same spend proof and (2) are signed by the same address (roughly equivalent to private key), it is a double-spend. Everything else is fine. |
|
|
|
I've just read the whitepaper and my brain is hurting now!  It also took some brain work to write Seems like a great project and I will try to get up to speed with this.
It seems that the whole source code is in javascript and the database used is sqlite, correct?
Correct, it is in javascript (or rather node.js), and for database we have a choice between sqlite and mysql. The role of the witnesses is interesting. Could you elaborate on the requirements to become one?
Anyone can become a witness, if he is chosen by users. The users would expect from a witness to waive his anonymity, at a minimum. Then, among the contenders, users are interested to choose the ones with good reputation, integrity, and long term interest in the health of the network. Users include the list of their favorite witnesses in every storage unit they post to the network, provided that the list is similar enough to the lists of other users who posted recently. This last requirement results in near-identity of witness lists posted by different users and slow evolution of an "average" observed witness list. It also means that any major change to the "average" witness list is impossible without approval of the majority of the present witnesses, one implication of this is that the witness list is immune to sybil attacks. |
|
|
|
Of course, I thought about it The attack won't work because the spend proof must be sent from the owner's address, not from any address. |
|
|
|
Much clearer. Got it.
So, a user can actually send a private txn where the payload and spend proof are gibberish. This would still get in the database, but would be useless as noone would accept it.
He can, although I don't see why he would want to do it. |
|
|
|
I am trying to install the Android app and was wondering why it needed access to Photos/Media/Files and Camera/Microphone.
Actually, I don't see mic on the list of requested permissions. The app is based in Cordova, and some Cordova plugins request permissions that are not actually used by the app. Of this list, we use only camera to scan QR codes, you can verify that by the source code. Also, would it be possible to provide an apk file (for those of us who do not (like to) use google play)?
There are services that automatically extract apk from google play, you can google for them. But remember that you'll have to update manually each time we release a new version. |
|
|
|
You are reinventing zerocoin.
Not at all. Zerocoin is based on zero knowledge proofs, while Byteball's private payments don't rely on any advanced crypto, just plain old hashes. |
|
|
|
I'll try to explain it this way, not exactly accurate, but simplified for ease of understanding of the concept. A regular transaction is just a collection of inputs (coins spent) and outputs (coins produced): payload: {
inputs: [...],
outputs: [...]
}
All of that is public, and everybody sees who spent what and to whom. Also, everybody can validate the transaction. Now, Alice and Bod don't want to show their transactions to the entire world, and Alice hashes the above payload and stores only the hash on the public database. At the same time, Alice sends the payload itself directly to Bob. Along with payload hash, she also stores the spend proof, which is a hash of the input. So, this is what she posts to the public database: private_transaction: {
payload_hash: ".....",
spend_proof: "......"
}
Both hashes posted to the public database are obviously meaningless for all third parties, they can learn nothing from Alice's transaction except the fact that she sent _some_ transaction. By making the spend proof public, we enable everybody to verify that the same input is not spent twice, as the same input will produce the same spend proof. Byteball way :
Alice creates a txn that has her 10(could be hidden) input and a 10 output to Bob.
Alice generates a random number, that she will need to share with Bob, along with ALL the previous proofs in the chain(if her 10 is hidden), to decode the spend proofs.
Previous proofs (spend proofs) are already public, they don't need to be sent directly. What is sent directly from Alice to Bob is previous payloads (plaintext inputs and outputs), which allow Bob to verify that the corresponding payload hashes and spend proofs do exist in the public database. Alice 'hashes-the-txn' with the random number. (There are a few steps here..) The random number is added as part of output, it is not something external. It's purpose is to make preimaging of the spend proof impossible, you can safely ignore this part for initial understanding. (This keeps the spend address visible for the network to check, but hides the rest.?) Correct, the network sees only the fact that Alice spent something, and here the network's knowledge ends. Alice sends the txn to the network and the spend proof to Bob. Who can then check for himself that the txn is what Alice says it is. And that all the parents are also valid.
Actually, the opposite: the spend proof is sent to the network (along with payload hash) while the plaintext transaction is sent to Bob. The network knows that Alice has spent the 10(or hidden value). but doesn't know to who or for how much.
The network doesn't know how much Alice spent, see above. The network doesn't know that Bob has a spendable output. So how does Bob then make a spend ? I know he knows, and he can prove the the next person, but the network won't have a record - so ..?
It's enough that Bob and all subsequent owners of the coin know that, the network doesn't need this knowledge. |
|
|
|
I have checked your wallet,really quite flexible and powerful ,waiting for new update.
By the way can you tell me how to attach btc address with byteball android wallet?
Best of luck for your project
The attaching phase will start later, watch the announcements in this thread. Currently, you evaluate the technology, see how ready it is for production use, and maybe build some tools/services based on it to get them ready by the launch. |
|
|
|
Hi spartacusrex, I'm glad to see the start of technical discussion in this thread! 49 Pages! .. And, if I may, I'm glad you think 'Simplicity is Beauty' or you might have tried to cram too much in..  It really does a lot. Congrats! (Particularly like the 'Leave' vote.) It is really a lot. And I tried to leave no questions unanswered (but apparently it's impossible). For private payments, the payload goes separately and additionally hides the
recipients of all outputs except the one that is meant for the payee I can see how to hide the amounts, using the blinding factor, but if you hide the output addresses as well, how do the miners prevent a double spend ? Or how does a user know that the output has not been spent already in another hidden txn ? Or am I misunderstanding and the outputs are not hashed, just the amounts ? That's what spend proofs are for. Spend proof is a hash over the output being spent, hence if you try to spend the same output again, the spend proof will be necessarily the same, and the validators (there are no miners here) will notice that immediately. |
|
|
|
sounds good dev! if i understood correctly we will not loose the testnet coin?
You can keep it but testnet coin is worthless by definition. |
|
|
|
Since there will be no ICO, how do you plan to fund this project in short term and long term?
Like I did before for the previous 22 months, plus I allocate 1% for myself. |
|
|
|
i am testing the wallet and seems to be very good! Did not take long time to sync! do you have any bounties for earlier testnet wallet dev?
I'm glad you like the wallet The only bounty we have is free bytes on testnet. |
|
|
|
New release v0.2: https://github.com/byteball/byteball/releasesAfter running for 3 days, a few insignificant bugs were found, most are fixed in the new release, some require more information. Please upgrade by the above link (Android will update automatically), report any issues you encounter. |
|
|
|
Interesting. Is there any tentative launch date?
Early November, subject to change. |
|
|
|
Do you allow exchanges to attach btc to byteballs? Most of the coins are in their reserve. They will get more number of shares than individuals. Otherwise, you can also make a giveaway with exchanges.
In this anonymous world, I can't say who is an exchange and who is not, and can't stop exchanges from using their customers' funds for themselves. If however any exchanges are willing to link their bitcoin addresses and receive bytes for their customers (not for themselves), they are most welcome. |
|
|
|
How many devs are working on this project?
One so far. |
|
|
|
If my device (smartphone/android) lost and i have backup the seed wallet.
How to import old wallet address?
Very good question. How would one import the wallet.dat for the phone app if phone was reset/crashed/bricked/smashed/thrown from a car window etc. Wallet seed is not enough because private assets, such as blackbytes, are stored only in the wallet (exactly because they are private) and get updated every time you send or receive a private asset. To secure against loss of the wallet, I recommend that you use multisig. For example, 1-of-2 multisig with one wallet on the phone, the other on a desktop computer. This way, the private assets will be automatically copied to the two devices. |
|
|
|
There is no ideal distribution. We all know what has happened with the Nem-sockpuppet-System.
The System of tonych is relatively good if you compare it with others.
What I would do in addition, even if it doesn’t add a lot of value, making a cap, so that one BTC-address doesn’t receive more than 1% of all coins (or even lower)
Whales probably split their funds but at the very end they don’t know how much they need to split (They don’t know how much 1% is, if tonych keep the numers secret and open them just after the distribution process)
It’s also an additional instrument to avoid whining and screaming when the distribution process is over, like it always happen here and everyone here is sick and tired of.
Example”Look, there are 3 whales that got 25% of all coins, Byteball has a really unfair distribution”.
At least this sentence could avoided if you insert a maximum cap of probably max 1% for each BTC-address.
I agree, one should compare the system with the others available, rather with some idealistic TheAbsoluteGood. Regarding capping, as you say, it is easily subverted by splitting the funds. I'm going to run the claiming phase as transparently as possible and going to make the numbers public to track the progress. I strongly believe that the best way to achieve a balanced distribution is by bringing in as many people as possible, both whales and regular bitcoin holders. When we have a whale, the best way to dilute his share is by bringing another whale on board (or a crowd of average Joes). This dilutes your share too, but remember that the value of the coin is proportional to the square of the number of active participants (Metcalfe's law), that's why you ultimately win. |
|
|
|
I added documentation about running headless wallet: https://github.com/byteball/headless-byteball. Like many things in Byteball, you control the headless wallet by talking to a chatbot:  You will see even more chatbots on the Byteball network in the coming months. |
|
|
|
|
Show Posts
