Topic: Obyte: Totally new consensus algorithm + private untraceable payments - page 1072. (Read 1234271 times)

Can't I sign a unit that has as its parent the, differs by 1 witness from the, genesis. Then sign a unit that has as its parent the, differs by 1 more witness from the, unit I signed in the prior sentence. Repeat as necessary. All those witness can be ones I control which I have sign units in my chain. If necessary I can control different addresses to make it appear that many people were using this chain branch.

So I can build a secret chain branch that double-spends one of my units from the public chain, then I release this secret chain branch. Then it is entirely ambiguous which of the double-spends is first and which of the chain branches is the "real" one, i.e. finality was not reached and the "stability" point was not stable.

I repeat that afaics your design is flawed unless you set a static global list of 12 witnesses.

There can't be a branch with substantially different set of witnesses.  There are no forks by design.  This is because the stability point can't advance without support of the majority of witnesses named in the previous stability point.  And there is a rule that the set of witnesses in new units should differ from the witness list at the stability point (specified in the new unit) by no more than one mutation.  The rules are really tight, you can't go too far from the witness list at the stability point.

Typical multi-sig and smart contracts are not going to grow the size of transaction by orders of magnitude.  And I don't see much use of Byteball in microtransactions, in particular because we don't address the blockchain bloat (or rather ledger bloat) problem.

That would be true if the ability to earn fees were the only witness' stake.  But it isn't.  As I said, the stake is outside the system, it is the reputation, the trust, the business that a witness has in the real world and would damage if it were to misbehave.

Okay good point, but the counter point is that we shouldn't assume that all lower valued transactions will be necessarily simple transactions. Let's think multi-sig, smart contracts, etc, then we might see problems at around $10 - $100 billion market. And if those are micropayments (which smart contract gas is for example), then we are getting into potential trouble at $100 million market cap.

Also there is probably also a tradeoff in that the lower the value of the fees for witnesses at low market caps, then perhaps the more incentive witnesses have to game and attack the system. That is getting into what I alluded to by "nothing-at-stake".

This is true. And if the market price falls too low, it will not be a good anti spam token.

Well, while theoretically possible, the valuations need to be quite high for this to happen.  The size of a simple transaction is about 500 bytes, let's round it up to 1000 bytes.  For this fee to be equal to $1.00, the market cap will have to be $10¹², or $1tn.

If you can't find such parent, you can't send any transaction.  But remember, although it is the default behavior to choose parents among the most recent childless units, you don't have to behave this way, you can also choose an older parent if it is compatible with your witness list.

You edit your witness list in your wallet.  Obviously, having full control also means being able to hurt yourself (not fatally, though).

Because the bytes being spent in the transaction have an exchange value. As the exchange value rises, then the quantity of bytes that will be transacted will decrease. When it decreases below the size of the transaction, the transaction is no longer economic.

The transaction fee is equal to transaction size.  How can it be related to the exchange price?

I think you'll have the best experience with the light wallet, but the choice is yours.

The section on 7 on Finality in the Byteball whitepaper is written in a way that I find to be very convoluted. But I was eventually able to understand what you wrote there by conceptualizing it a different way and then relating my conceptualization to your explanation.

My conceptualization is that if witnesses are required to serialize their units and if we can assume we know what all the witnesses can be, then once we have a majority of the witnesses as ancestors of a unit, then the said unit is a stability point because it is impossible for a best parent MC for a future unit to assign a lower ordering number to a double-spend of any unit from which the said stability point unit is a descendant.

But sorry to say the flaw I see in your analysis is that you don't appear to consider the case where a new branch appears (which was formerly hidden by network disruption, propagation delays, or intentionally) which has a sufficiently different set of witnesses from the "current MC" which any particular node analyzed.

Thus afaics, there is no finality. The only way to have finality is to make the set of 12 witness globally static.

P.S. Readers the term 'serial' in the white paper means that it is assumed (how required?) that a witness will only create a new unit (i.e. vertex on the DAG) for which all of the prior units of that said witness have the newly created unit as a descendent. In other words, a witness is assumed to not go creating units which exist on branches of that DAG which don't contain the prior units of that said witness. Without this rule, then the logic of my 2nd paragraph above would not apply.

Here's a step by step guide:

- make yourself a bitcoin testnet wallet (online wallet, mycelium testnet for android, etc.)
- grab some testnet bitcoin at a faucet
- install the Byteball TN wallet
- click the link for the transition bot on byteball.org, it's under the download links
- transition bot will start in byteball wallet and will guide you
- send the exact bitcoin amount to the bitcoin testnet address the bot tells you
- wait for confirmation (the more bitcoin fees you add to the tx, the faster it gets confirmed)
- the bot tells you your balance, probably not enough, because your bitcoin wallet moves the change amount to a new bitcoin address. In this case, you have to transfer the complete amount of bitcoins in your wallet to yourself. The bot tells you from which bitcoin address your payment came in, check if that is your address and if you're sure that this is your address, send your complete bitcoin balance there
- wait for confirmation of this tx, the bot will update your linked balance (you can enter any text like "Hi" for an update from the bot)

Furthermore, I am sorry to say that my analysis is that once the exchange price has risen high enough, the transaction fee will exceed the value of the transaction and so the transaction can't be economic.

This appears to break the coin.

What happens if I can't find such parent, the transaction fails? Also as a user, how do I choose witness? if I have full control of the list, then there's no guarantee that I can choose most the same as others.

lol its a fake blockchain it will work with bb testnet ?

i cant use it..i have 2 transac but no balance..how it work pls 

hello @tonych

i check new testnet (tn) but i dont know if i will do good choice..so can yu tell me if it is best to choose full wallet or light wallet..wht do yu recommend ? i can reboot after install it if my choice doesn't satified me ?

hi, yu can find sign campagn here : https://bitcointalk.org/index.php?topic=1666370.0;topicseen

translat isn't reserved do it and contacted @tonych gy 

I mean exactly the same.

It is the set of witnesses specified in the unit we started traveling from.

I mean stake in more general terms of what is at risk in the game theory of attacks not specifically its assumed meaning in PoS, but I need to understand your design better before I can posit anything concrete on that. Any way...

I don't understand how you achieve this sentence in Section 6 of the white paper:


How can you know what the set of witnesses is in the history when the set is allowed to change in time?

Note I may be wrong about lack of objectivity since I have just noticed your rule that addresses have to reference their prior units in the parent chain else that is objectively misbehavior, so I presume the same rule applies (stringently) to witnesses.

Before I had just skimmed the paper and now I am reading it in detail.

Don't confuse with PoS, witnesses' stakes are outside the system.
Looks like you want to get a deep understanding of the design, then you have to read the first few sections of the white paper that discuss consensus.