Witness

What is a witness?

A witness is a highly reputable user with a real-world identity, who acknowledges each transaction seen. There are 12 witnesses involved in every transaction. In exchange for the work involved, a witness collects part of the transaction fee (the payload fee). This list varies very little from transaction to transaction. There cannot be more than one change in the witnesses list. The witnesses majority (6+1) show the path to the main chain. Some witnesses may even be down for a period of time without affecting the network. The security of the network would only be threatened if 7 witnesses colluded together, which is almost unthinkable.

How to replace a witness

Wallet menu > Settings > Witnesses displays the 12 witnesses set in one's wallet.

• If "Auto-update the witness list from the hub" is turned off, click the witness (just one) you want to change, then paste in the new ID and click Save. Note that if your hub suggests a different witness list, it will notice the difference and prompt you to change it back.

• If Auto-update is turned on, one's witness list will be updated to match the hub's default list automatically.

New default witness

After a new default witness has been approved, the next time one's wallet is turned on a screen will suggest replacing a particular Founder's Witness with the new one. So select either "Replace" or "Maybe later."

Non-Founder's witnesses

Why change?

The platform was set up with 12 witnesses all being the founder, Anton Churyumov (Tony). He is, of course, "a highly reputable user with a real-world identity", and totally trustworthy. Obyte is his baby, after all. But this couldn't get more centralized, unwelcome in a going-to-become decentralized system. So we need to diversify, to start trusting others willing to stand up publicly and put their reputation on the line.

portabella, the first independent witness

No real-world identity posted. Known in the Obyte community as a veteran Byteball developer and contributor, who started this very wiki. Also operated the first independent Byteball hubs (see hub list) from January 2017. Currently (2019) not active in Obyte.

seb486, the cashback witness

No real-world identity posted. Known in the Obyte community as seb486 on Slack and Bytefan on BitcoinTalk. Not operating as a witness since July 2018.

Rogier Eijkelhof

The first default decentralized witness, from the Netherlands.

Fabien Marino

The second default independent witness, co-founder of Busy.org and SteemConnect, involved with Obyte since February 2017.

Bosch Connectory

This is the third default independent witness, overwhelmingly approved by vote (178:2 addresses, 31320 GB : 68 MB).

PolloPollo

In a poll closing on 4 Feb 2020, PolloPollo was convincingly voted in as the fourth default independent witness.

Witness monitoring service

This is a useful page: https://stats.obyte.org/witnesses.php

Witness list

Witness ID	Owner	Discord ID	Started
BVVJ2K7ENPZZ3VYZFWQWK7ISPCATFIW3	Anton Churyumov	@tonych	2016-12-25
DJMMI5JYA5BWQYSXDPRZJVLW3UGL3GJS	Anton Churyumov	@tonych	2016-12-25
FOPUBEUPBC6YLIQDLKL6EW775BMV7YOH	Anton Churyumov	@tonych	2016-12-25
GFK3RDAPQLLNCMQEVGGD2KCPZTLSG3HN	Anton Churyumov	@tonych	2016-12-25
H5EZTQE7ABFH27AUDTQFMZIALANK6RBG	Anton Churyumov	@tonych	2016-12-25
I2ADHGP4HL6J37NQAD73J7E5SKFIXJOT	Anton Churyumov	@tonych	2016-12-25
JEDZYC2HMGDBIDQKG3XSTXUSHMCBK725	Anton Churyumov	@tonych	2016-12-25
JPQKPRI5FMTQRJF4ZZMYZYDQVRD55OTC	Anton Churyumov	@tonych	2016-12-25
OYW2XTDKSNKGSEZ27LMGNOPJSYIXHBHC	Anton Churyumov	@tonych	2016-12-25
S7N5FE42F6ONPNDQLCF64E2MGFYKQR2I	Anton Churyumov	@tonych	2016-12-25
TKT4UESIKTTRALRRLWS4SENSTJX6ODCW	Anton Churyumov	@tonych	2016-12-25
UENJPVZ7HVHM6QGVGT6MWOJGGRTUTJXQ	Anton Churyumov	@tonych	2016-12-25
MEJGDND55XNON7UU3ZKERJIZMMXJTVCV	anon	@seb486	2017-05-25
4GDZSXHEFVFMHCUCSHZVXBVF5T2LJHMU	Rogier Eijkelhof	@Rogier	2018-10-23
FAB6TH7IRAVHDLK2AAWY5YBE6CEBUACF	Fabien Marino	@fabien	2019-04-16
2TO6NYBGX3NF5QS24MQLFR7KXYAMCIE5	Bosch Connectory	N/A	2019-12-27
APABTE2IBKOIHLS2UNK6SAR4T5WRGH2J	PolloPollo	@punqtured	2020-02-04

---

FAQ about witnesses, double spending, finality

Witnesses and consensus

Q: Those witnesses that wallet has chosen that will try to determine the validity of the transaction/message?
A: Actually, No. Witnesses are not sole validators. All full nodes perform validation, witnesses are a small subset of full nodes. They are not special in regards to validation. Witnesses play other role. Remember we are on a DAG, there is no strict order between units. All full nodes look at witnesses in the recent history to establish the path of the Main Chain. The Main Chain is chosen such that it goes through as many witness-authored units as possible. Total order is then determined relative to the Main Chain, and total order resolves conflicts caused by double-spends -- the earlier version wins. That's the role of the witnesses -- to draw the Main Chain through them.

Q: Are witnesses required to validate all transactions?
A: Witnesses are required to be full nodes, hence validate all transactions

Q: So in effect, a witness has the same role as any other full node, except when attempts of double spends without partial order occur?
A: Yes but even in this case witnesses don't decide anything, rather their positions on the DAG are used by all nodes to resolve double-spends. (Actually the position of the units that are authored by the witnesses)

Q: Does a full node need to receive and validate all transactions?
A: Yes, that's the definition of a full node

Q: To illustrate how little a witness has to decide:
A: A witness doesn't even has to know that it is a witness. For example, you can set bittrex address QR542JXX7VJ5UJOZDKHTJCXAYWOATID2 as one of your witnesses, you don't need to ask bittrex for permission, and bittrex doesn't need to know it and do anything else in addition to what it already is doing.

Q: The witnesses together they decide which branch of the transaction tree is the real one?
A: More accurate wording: they don't decide but enable others to decide, by looking at witnesses as markers of reality

Q: A witness’ task is to "stamp" [i.e., “comment upon"] every legitimate transaction it sees by issuing a transaction "on top of it", that means by choosing the witnessed transaction (unit) as a parent for the fresh transaction (unit) of the witness?
A: Correct.

Q: Are the “witnessing” units specialised by any means?
A: There are no specialised witnessing units. Any witness-authored unit counts as “witnessing” unit

Q: If the witness was already about to issue a unit -- maybe the witness wants to send some Byteball bytes to someone for example -- that unit does double duty? First: with that unit the witness sends the bytes to the intended recipient, second: that unit counts as witnessing unit?
A: Correct

Q: The protocol requires that transactors have an overlap of 11 (out of 12) witnesses, correct?
A: The requirement applies to neighbors and all units on the on the chain built by following best parent links starting from the current unit until the stability point

Q: 6 witnesses can determine the chain state entirely, with no need to internal considerations (contrarily to most other blockchains that use biggest block height, with some weighting). Correct?
A: No, witnesses do not determine the chain state

Q: is there an option of organic replacement of one or more witnesses?
A: Edit the list in the wallet settings

Q: Is it possible that 24 active witnesses exist in the DAG and some users have completely different witness lists than the other? If not, why not?
A: If we define users as those who post transactions to the DAG, No.

Q: Is it possible to choose 12 completely new witnesses for my wallet? What would happen?
A: Possible but you won’t be able to post any transactions until all active users migrate to roughly the same list

Q: What does “predominant witnesses” mean?
A: Those that you see on the most recently posted units (they can be slightly different)

Q: According to the White Paper, “general consensus is required for a change bigger than one position”. What does this general consensus mean? It means the consensus of the current 12 predominant witnesses?
A: Yes, the majority of the current predominant witnesses

Q: If an individual, company or government seizes a witness (or all), would they be able to censor transactions?
A: If "a" witness, no, they will only censor out themselves. If all witnesses, yes.

Q: What happens if all witnesses are shut down?
A: There will be no confirmations. The MC will still be there but the “stability point” will stop advancing.

Q: Is it possible that for the majority of witnesses they stop posting because they funds became pending (waiting for confirmation in the DAG)? And hence we lose the majority of witnesses?
A: Theoretically possible if the majority of witnesses are negligent enough to allow this. Not a concern after we activate the update that allows spending unconfirmed funds.

Double spending

Q: Are full (or light) nodes capable of identifying and solving double spend attempts without the use of witnesses?
A: No, they need the witness-authorized units’ positions on the DAG to build the MC, and they use the MC to resolve doublespends

Q: If a user violates the rule that requires all his txns to have partial order, what's to stop him? For example, if I introduced a pair of conflicting double spending txns, would one be accepted eventually? or would both be discarded?
A: One of the two conflicting transactions will be censored: the one that is later on the “Main Chain”. Not just censored by witnesses, but censored by every full node who follows the protocol.

Q: What about if the attacker shuffles the order of the two conflicting txns, and sends to two different sets of users? Wouldn't one group censors one, then the other censors the other? how would this be mediated?
A: This is a basic requirement for every working consensus algo that it should be protected from partitioning. The answer is that both sets of users must accept both txs. The order of transactions (hence voiding of the tx that appears to be later) is decided only after they become “final”, i.e. when reordering of these transactions becomes impossible.

Finality in Byteball

Q: What is “finality” in Byteball?
A: Finality means that the transactions cannot be reordered and all nodes agree about the order of transactions before the “stability point” (“before the stability point” = “between the Genesis unit and stablitiy point unit in the DAG”)

Q:.What is “stability point” in Byteball?
A: A stability point is the position of a specific unit in the DAG. Between the Genesis unit and the stability point all nodes have a consistent view of the ledger. If a node does not received all the fresh units yet, then that node still has an “older” version of the stability point, that is closer to the Genesis unit.

Q: Is it possible that the "Stability point" is moving backwards, I mean towards the Genesis unit? (By any means, may it be a misbehaving witness, or some other attack).
A: No, it is not allowed.

Q: So based on this, is it correct to say that if misbehaving witnesses are colluding to build a shadow chain and suddenly connecting the shadow chain to the main chain and trying to "hijack" the main chain "behind" the stability point (that is between the genesis unit and the stability point), they will fail? A: if the colluding witnesses are a majority, the network will get into undefined state once they publish the shadow chain

Q: If there is a new full node, he does calculate the current stability point by himself, or he is receiving it from some other nodes?
A: Every full node replays the entire history and recalculates the stability point itself

Additional comments

[Slack 11:00 PM 2017-06-22]

markcross: And it's those witnesses that wallet has chosen that will try to determine the validity of the transaction/message?

tonych: To make sure there is no misunderstanding, actually, No. Witnesses are not sole validators. All full nodes perform validation, witnesses are a small subset of full nodes.  They are not special in regards to validation.  

Witnesses play other role.  Remember we are on a DAG, there is no strict order between units.   All full nodes look at witnesses in the recent history to establish the path of the Main Chain.  The Main Chain is chosen such that it goes through as many witness-authored units as possible.  Total order is then determined relative to the Main Chain, and total order resolves conflicts caused by double-spends -- the earlier version wins.  That's the role of the witnesses -- to draw the Main Chain through them.

[Bitcointalk 2017-02-06]

Tonych: When changing your witness list you remove one old witness and replace it with a new one. If the removed witness is the same on all nodes (which is more likely in practice, e.g. if negative information about a witness is released), all nodes stay compatible: only one mutation relative to the old list and relative to each other. The nodes can perform more changes as long as their new lists stay compatible.

Decentralizing witnesses

[Bitcointalk 2018-03-21]

Tonych: Looking for reputable well known people/orgs/businesses who satisfy all the criteria https://github.com/byteball/byteball-witness. Any help with approaching them is appreciated.

Witness functions

[Slack 2018-05-14]

tonych:

> · Are witnesses required to validate all transactions?
witnesses are required to be full nodes, hence validate all transactions
> · What happens if all witnesses are shut down?
there will be no confirmations. The MC [main chain] will still be there but the stability point will stop advancing
> · If an individual, company or government seizes a witness (or all), would they be able to censor transactions?
If "a" witness, no, they will only censor out themselves. If all witnesses, yes.
> So in effect, a witness has the same role as any other full node, except when attempts of double spends without partial order occur?
Yes but even in this case witnesses don't decide anything, rather their positions on the DAG are used by all nodes to resolve double-spends
> Every full node validates all transactions?
Yes, that's the definition of a full node > · Are full (or light) nodes capable of identifying and solving double-spend attempts without the use of witnesses?

No, they need witness positions on the DAG to build the MC, and they use the MC to resolve doublespends

Tsonko Mirchev: Is that mean that full node doesn't need MC to resolve doublespends?

tonych: no, it needs the MC

tonych: another thing to illustrate how little a witness has to decide: A witness doesn't even has to know that it is a witness. For example, you can set bittrex address QR542JXX7VJ5UJOZDKHTJCXAYWOATID2 as one of your witnesses, you don't need to ask bittrex for permission, and bittrex doesn't need to know it and do anything else in addition to what it already is doing.

slackjore: My reaction is "What?!!!". I've been trying to understand witnesses for 10 months, but get lost in the "Main Chain" statements. I'm not much of a techie, so I try to keep things simple. I thought that a witness "stamped" every legitimate transaction it sees by issuing a transaction "on top of it", parent/child relationship of some kind. Looking at Explorer, this is what I see: most of the units are witness units. Now, with regard to Bittrex (for example), it's obvious that one can send any Byteball token to any Byteball address. But surely one can't send into the DAG a transaction *from* any address, as that would imply one has the private key. So, someone please explain in simple terms what I don't get.

slackjore: I'll itemise my assumptions, one or more of which must be wrong. Repeating a higher-level general explanation doesn't help me. (1) a witness "stamps" [i.e., comments upon"] every legitimate transaction it sees by issuing a transaction "on top of it", parent/child relationship of some kind. (2) these "stamps" are units injected into the DAG, visible on Explorer (3) the source of these must be a full wallet with additional software, running on some hardware controlled by someone (4) this someone has also been called a "witness", as in "how to become a witness" or "a witness must be reputable" etc. (5) the name "witness" also refers to the Byteball address the witness (person, company) is using as a unique identifier -- although one entity can also obviously control more than one. (6) One can't send into the DAG a unit *from* any address, as that would imply one has the private key. Which of these is wrong?

tonych: no, witnesses do not "stamp", stamping would make them gatekeepers

tonych: the functions are just to 1) be honest, and 2) be there

> because together they decide which branch of the transaction tree is the real one more accurate wording: they don't decide but enable others to decide, by looking at witnesses as markers of reality > Hm, I added Bittrex as a witness and the explorer considers the tx stable, but my wallet doesn't

if your wallet is light, it sees stability later

slackjore: OK. I was using the word "stamp" wrongly, to mean basically "comment upon". How about my other assumptions?

tonych:(2) correct

(3) correct, the "additional software" is anything responsible for frequent posting of transactions
(4) correct
(5) correct

(6) of course

slackjore: Thank you. So how can Bittrex act as an unknowing witness, if a witness has to author units?

tonych: they do withdrawals and other txs from this address

slackjore:yes, but you said: https://byteball.slack.com/archives/C9GDDLW0N/p1526293317000487

tonych another thing to illustrate how little a witness has to decide: A witness doesn't even has to know that it is a witness. For example, you can set bittrex address QR542JXX7VJ5UJOZDKHTJCXAYWOATID2 as one of your witnesses, you don't need to ask bittrex for permission, and bittrex doesn't need to know it and do anything else in addition to what it already is doing.

Posted in #marketing_discussionToday at 11:21 AM

tonych: yes, any contradiction?

slackjore: A witness (entity) authors specialised witnessing units into the DAG that have nothing to do with its own regular non-witnessing transactions. Only the designated witnesses do this. How can Bittrex do this if it knows nothing about the duties of a witness (entity)?

tonych: there are no specialised witnessing units, any witness-authored unit counts

slackjore: I mean a unit like this: https://explorer.byteball.org/#OaMFZKr+2zQp4Ce0Oxz0tpTaB4Jb2jLDYcrLACxt+jA= arbitrary, first one I saw

tonych: nothing special in it

slackjore: Let's say I send someone 50,000 Tangos. I'll call this a substantive transaction, not because 50,000 is big compared to 5, but because it has, er, substance. This DAG entry floats around the globe and gets seen by all full wallets. Almost all of them passively do nothing more than validate it and add it to their databases. The 12-14 functioning witnesses, however, author units related to it: if the witness was already about to issue a unit -- maybe the timestamp oracle, for example -- that unit does double duty. If the witness does not have its own substantive unit to issue, it simply issues a non-substantive unit, what I called a "witnessing unit" to say it has seen the valid Tangos unit, plus details of it. Is that correct?

tonych: correct. Note however that issuing non-substantative units is not required, it is just one of the ways for a witness to show its presence. And there might be other new units that would trigger a non-substantative unit.

slackjore: ok, great, now I understand how Bittrex could be an unknowing witness. Thank you very much indeed.

---

Person: Hi @tonych please help to answer some questions. I would like to understand the WP.

1. WP Chapter 6. Witnesses: “travel along the MC back in time and count the witness-authored units. [...] We would stop traveling as soon as we had encountered the majority of witnesses.” - Here you consider any witness? Or only the witnesses of the candidate parent? Or only the witnesses currently defined in the user’s wallet? How the majority is calculated?

2: WP Chapter 6. Witnesses: “We would then measure the length of the longest path on the graph from the point at which we stopped to the genesis. We’ll call this length the level of the unit where we stopped, and the witnessed level of the parent whose MC we are testing.” - Why don’t you use the notion MCI that was already used before in the WP? Is there any difference between “level of unit” and “MCI”?

3: WP Chapter 7. Finality: “Let’s travel back in time along the current MC from the tip until we meet the majority of witnesses” - Here by “meeting a witness” you mean that we find a witness-authored unit on the current MC? And, “majority of witnesses” you mean 7 out of 12 witnesses defined by the current stability point, correct?

4: WP Chapter 7. Finality: “If at least one of them lies earlier than the current stability point” - Here earlier means “between the the genesis unit and the current stability point?

tonych: 1. the witnesses of the newly added unit

2. level and witnessed level are different from MCI. In particular, they are constant for each unit, they are just a function of its position in the DAG, while MCI is recalculated every time a new unit is added and can change while the unit is unstable.

3. correct

4. correct

Person: tony: Is it correct to state that the “current MC” is determined by the witnesses of the unit in the current stability point?

tonych: No, no witness list matters at all at this step. You just define the best parent using witnessed level and level

Person: [question lost]

tonych:. Not at all. More accurate: replace "among these witnesses" with "among these units" (authored by witnesses). We just look at these units and find the minimum witnessed level.

How to become a witness

To become a winess, you are expected to:

• have a publicly known real name, no anonymity
• be well known in the community
• be trusted
• have a lot to lose (material and/or nonmaterial) in case of misbehavior. The loss is your business (outside Byteball) and/or reputation
• have enough technical expertise to ensure uninterrupted operation 24/7 and security of your private keys (they must not be stolen and used to post on your behalf)
• be prepared to adapt your own witness list when you feel the community wants to change the list in some way and the new candidate satisfies the above rules. This includes removing your witness from the witness list.

If you think that you satisfy these criteria, this is your course of action: <snip>

External links

• Video: Byteball Witnesses - the basics explained
• First decentralized witness candidate
• Bosch Connectory Approved as Obyte Witness