Witness

From Obyte Wiki
Revision as of 18:31, 22 May 2018 by Slackjore (talk | contribs) (added slack messages (not edited yet))

A not-too-technical description of what a witness does; why we need non-default witnesses, and who's available

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.[1]

How to replace a witness

Wallet menu > Settings > Witnesses > then either

  • Turn on "Auto-update the witness list from the hub"; or
  • Turn it 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.

Non-default 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. Byteball 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 Byteball community as a veteran Byteball developer and contributor, who started and maintains this very wiki. Has also operated the first independent Byteball hubs (see hub list) since January 2017.

Based in Stockholm, Sweden, a software developer by day, Byteballer by night. Replace the default witness JED... with 7ULGTPFB72TOYA67YNGMX2Y445FSTL7O. You can do so in the Global settings menu - Witnesses, or by changing hub to byteroll.com/bb and accepting the witness-list it suggests, which is the above JED... to 7ULGT... change. Operational security is of highest importance, as such it will never run in a cloud or somebody else server, it is currently in a physically secure location with auto-destruct if tampered with. There are no backups for high-availability, as any restart requires the manual entering of passphrase. The passphrase and keys have been generated and not ever copied anywhere else.

Contact info: @portabella at our Slack.

@seb486, the cashback witness

No real-world identity posted. Known in the Byteball community as seb486 on Slack and Bytefan on BitcoinTalk. With a partner operates 4 hubs globally (see hub list). Main website is https://byteball.fr.

In his own words:

We are based in France and operate the first Byteball redistributive witness, also know as "the cashback witness". Each time you post a unit to the byteball network you pay a Payload fee which is proportional to the weight (in bytes) of your unit. The 12 witnesses your unit is authored on receive each 1/12th of the Payload fee. Use the Cashback Witness as one of your witnesses and 50% of the payload income it earned from you is given back to you. The process is fully automated and 100% anonymous, no registration is needed.

You earn back bytes for free. It is as simple as that![2]

Contact info: #cashback_witness channel at our Slack 

Witness monitoring service

This is a useful page[3] created and maintained by @seb486

Witness list

Witness ID Owner Slack 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
7ULGTPFB72TOYA67YNGMX2Y445FSTL7O anon @portabella 2017-02-14
MEJGDND55XNON7UU3ZKERJIZMMXJTVCV anon @seb486 2017-05-25

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.[4]

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.[5]


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.


Hi @tonych please help to answer some questions. I would like to understand the WP :slightly_smiling_face: 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 [12:18 PM] 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

tony: 1. > Is it correct to state that the “current MC” is determined by the witnesses of the unit in the current stability point? No, no witness list matters at all at this step. You just define the best parent using witnessed level and level 2. 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>[6]

External links

References