Another Q&A from Byteball dev tonych

Some more Q & A from the main post on BCT forums here: https://bitcointalk.org/index.php?topic=1608859.0
Q = question from a poster.
A = answer from dev - tonych

Q: Wonderful news, does the trading bot works for blackbytes too? I am interested in trading some blackbytes for white bytes...
A: It works for bytes only.
We'll have a bytes-to-blackbytes P2P exchange on the network.

Q: Ok, thanks. But I meant the transactions made by others (not from/to my wallet) Smiley
Is there any way to see the timestamps on them?
A: There are no timestamps in Byteball protocol, they are just not needed. That's why there are no reliable timestamps.
The ones you see in History tab are the times and dates when your wallet first learnt about the transaction (or, if you are on light wallet, when the light vendor first learnt about the tx).

Q: Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.
A: If the user waits that the transaction is final, he cannot be defrauded.
In your example, you isolate the merchant from the real network and feed him with a fake branch. The merchant will accept your units and add them to his version of the DAG, but since there are no witness-authored units on your branch, it will not move the stability point forward and your double-spent payment will stay unconfirmed for as long as your attack continues. Number of nodes is totally irrelevant, it is the presence of witnesses what makes a branch real.

Q: Currently, that page is frozen with the balances and linked addresses used for the first round, so for now it is not getting updated. I think it might be the time to unfreeze it and/or maybe keep that state in a separate page: transition.byteball.org/firstround.html for instance, and update the main page with the current links.
A: Thanks for the suggestion, now the transition page updates again, and the balances used in the 1st round are moved to transition.byteball.org/firstround.html.

Q: This is what I actually supposed. Thanks for confirming that, tonich!
But don't you think such timestamps could be useful for some of the applications of Byteball? I understand they are not needed by protocol, but it could be useful to add them as an comment or "additional info", so it could be easier to trace transactions or analyze the chain. Simple example - I was trying to see when an amount was transferred to some address (some minutes ago or few days ago), and I found no way of using that! This is great for making things more obscure, but I suppose that is not something we want to achieve with Byteball...?
A: Applications are supposed to use timestamps posted by oracles they trust. There is already one timestamping oracle, its address is I2ADHGP4HL6J37NQAD73J7E5SKFIXJOT and this is one of its recent timestamps https://explorer.byteball.org/#vcwDbSwjOH4h0wdW5M51N92+ivdm8zgBArrdeSHDz5k=. A similar timestamping oracle on testnet is already referenced from smart contracts of our trustless exchange.

However, choosing which timestamping oracle to trust is entirely up the application, there is no single "official" timestamp. The best we could do to address the issue you describe above, is showing when a transaction was received by the explorer node. It's only that - when the tx was received. If we restart the explorer from scratch, all past transactions will be received within 1-2 hours after it is restarted and these timestamps won't be very useful.

Q: Right, but how is reputation and marketing in the real world determined algorithmically? If it's just number of votes, couldn't large ICO holders easily make the most txs and thus vote themselves as most reputable, especially when the coin is relatively small like now?
A: This is where the system is anchored to the real world. If someone feels that witness X should be replaced with witness Y for whatever reason, he can start a campaign and try to convince others to do the replacement (in the current version of the wallet, this can be done only manually in wallet settings). While some people have already switched to the new witness list and some are still on the old one, all users are able to add their transactions to the DAG because a difference of 1 witness is allowed. After the change has diffused throughout the network, a new change can be campaigned for and realized.

Obviously, no "votes" from anonymous users can be relied upon in a system with no barriers to entry. ICO holders don't get any more power automatically just from holding larger bags.

Q: Can you explain more technically how the change of witness is diffused througout the network?
A: This part is the least technical, just more users accept the new witness list.
Q: Which votes count, anybody making transactions? 1 vote per transaction?
A: As I said, there are no votes.
Q: Btw, does the amount of witnesses, 12, impose limits on transactions/second in any way, or latency for finality?
A: Yes it does. If we had 1 witness (which would be roughly equivalent to checkpointing that is used in some cryptocurrencies), transactions would confirm faster. If more than 12, then slower. See the chapter about finality in the whitepaper, we reach finality when we see the majority of witnesses on certain positions on the DAG.

Q: Good job. Is there a market for blackbyte / byte or blackbyte / BTC? If not, can users create any two pairs they want, or you have to create them?
A: Only bytes vs BTC so far.
We'll have trustless P2P exchange for trading bytes vs blackbytes.

Q: All the above sounds simple. It's this bit that's causing me a little confusion.
For the bytes you hold on mid-February (to be announced) you receive 0.1 new byte for each 1 byte of your balance, even if your bytes are not on linked Byteball addresses.
You also receive 0.21111 blackbytes for each 1 byte of your balance on the linked Byteball address, which currently is:
YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY 0 GB.
Move your bytes to the linked address in order to maximize the amount of blackbytes you receive.
I signed a message and successfully linked my BTC address to my byteball address.
I have a load of bytes and dark bytes sitting in that wallet also.
Now, why is it telling me I have to move my bytes to YYYYYYYYYYYYYYYYYYYYYYYYYY ?
Do I need to move resend my own bytes to myself at this YYYYYYYYYYYYYYYYYYYYYYYY address?
Many thanks in advance.
A: Yes, you need to move bytes to yourself, to your linked address.
To distribute blackbytes, it's not enough to know your BB address, we also need to know your device address in order to send the private payloads. Since we know this only for your linked BB address (but not for all your other BB addresses), you have to move bytes to the linked address.

Q: Price is exploding. Lisk please dump now, I want to buy more but cheaper! Max be our friend :-)
A: I'm in contact with Lisk and ICONOMI and they are not going to sell any time soon.