Re: [ANN] XtraBYtes - The Proof of Signature Blockchain Database

Proof of Signature Basic Introduction

The PoSign Mining is very easy to understand.

Each client (STaTiC Node) sees the same transactions and therefore each block is equally visible by the entire network. The STaTiC Nodes job with regard to the consensus is to simply sign the blocks. If any STaTiC tries to sign a fake block, the other STaTiC's will blacklist it and continue signing the VALID blocks.

For example:

Let's say there are 100 STaTiC Nodes online across the network and 1 tries to create a block that contains fake information (such as; fake transaction or bad blockhash etc...) This fake/bad block hash will be different than the other 99 hashes and therefore the other 99 clients (STaTiC Nodes) will send a warn/repair RPC message to the "bad" client. If the "bad" STaTiC Node repairs the block then the hash will become the same as the other 99. If it doesn't repair it and instead tries to resend over and over, the other nodes will eventually blacklist the STaTiC.

All other nodes (non STaTiC nodes) will see the last block that signed and how many STaTiCs accepted.

In comparison; Bitcoin and all other coins have only one untrusted, randomly selected node that signs and creates the block. With XBY, each block is created and signed by all the currently ONLINE STaTiC Nodes.

With XtraBYtes, there is no POW or POS mining to sign and verify the blocks. As we said, each online STaTiC signs and this is where you start to see the power of PoSign... Because, this means there are more signatures and more signatures = more security. Nobody can know all private keys from the STaTiC Nodes and therefore it is impossible to create fake STaTiC signed blocks.

At this point, we have ONLY 1 STaTiC node controlling XBY and the network is fast and secure...

After more STaTiCs have been registered on the network, XBY will be better than ALL other coins in the crypto world.

At this point, nobody really understands what is really happening here... We are developing THE COIN Wink

This is the LATEST INNOVATION in BLOCKCHAIN technolgy and our man Borzalom is the Genius Mastermind who thought of it.

So, to summarize:

If Bitcoin security is 100% (with untrusted nodes signing the blocks) How much more powerful is XBY when it is also (100% + the use of trusted nodes) * the number of STaTiC Nodes? Like I said... he was blowing my mind when he was explaining all this to me a few nights ago.

Congratulations to all of you who are already with XtraBYtes... You are way ahead of the people who will be coming on board soon.... VERY SOON...

I have a few questions about the specifics of your consensus algorithm.

I generally approach consensus algorithms from a few angles:
-What are the attack vectors (both in stalling consensus and in reversing established consensus)
-How is power distributed (and what effects does that have on censorship)
-How does it impact scalability (both in transaction volume and number of users)

With those main ideas in mind:
1. How does someone actually become a STaTiC node? Do they have to go through the developer, can they set it up themselves?
2. How do you ensure that each STaTiC node sees the same transactions? Further to that point, if I send two transactions that conflict with one another, and some STaTiC nodes see the first and some see the second, how do they come to agreement which transaction is the legitimate one?
3. What constitutes a 'fake' block?
4. How do normal nodes know who the STaTiC nodes actually are, to verify the signatures against? How do thin clients do it?
5. Are blocks deterministic (i.e. everyone on the network at any point would be able to construct an identical block)?
6. It appears every STaTiC node is able to independently create identical blocks, is that true?
7. What is the threshold for normal nodes to accept a block as valid (99% of STaTiC signatures? 51%?)
8. What prevents the creation of an alternative history if someone compromises the original private key of the first STaTiC node? Is the network only weakly-subjective?

This is one of the RARE occasions we will post with Borzaloms English. Anyone can see from his history that this is him...

I do not have time to convert this to easily understandable English at this time because we are busy preparing the announcements.

However, I do not want this to go unanswered because it is troll food and all of you deserve to have the best chance at winning here at XtraBYtes.

Thank you for understanding, Borzalom and I will update this post ASAP.

[3:46:20 PM] -- CCRevolution -- $: https://bitcointalk.org/index.php?topic=1864397.msg18775624#msg18775624
[3:46:46 PM] -- CCRevolution -- $: That is a very heavy question... We will not have time to answer this tonight I dont think... unless you can make it very simple.
[3:46:50 PM] Borzalom: 1 working. maybe just a hour needed
[3:47:35 PM] Borzalom: I like heavy questions
[5:09:07 PM] Borzalom: Here is the answers:
[5:09:13 PM | Edited 5:09:51 PM] Borzalom: This is a first very- very good question. Therefore firstly I thank your contribution. I love the hard constructive technical questions.

1.) need deposit ( own address ) + need registration + long online time need after registration ( until old STaTiC-s accept the new STaTiC-s )
Difference the now and later the first registration ( between 25.000 - 50.000 blocks ) don't need the long online time and old STaTiC-s acception.
After registration code released then don't need developer. Maybe some code fixes but no more. And of course this is experimental therefore
if don't work the original plan then consensus maybe will change.

2.) The "chord" type internal routing between the STaTiC-s ensure the communication. Example If the hash of transaction is begin the 0x1
then the 0x1 STaTiC will the root who first validate and accept this transaction. If you sent the conflicted transactions then the first
will accepted or both will denied. The target STaTiC-s will decide this. I say again, this is expermental therefore i don't know exactly
the best solution. We will see how to work and if need then i will change the protocol. This is a top reason why no whitebook.

3.) Very difficult to answer. Of course lot of checking needed. Better question that what is the good block. If any block not good then that is fake.
Each STaTiC need to make consensus and need exactly 100% same block accepted. If the all accepted transactions broadcasted between the STaTiC-s then
the transactions of block will be equal therefore block has also will equal. ( just signature will the difference )

4.) STaTiC registration will ensure the public keys of STaTiC-s. The key revoke will work simile. All emitted and revoked key stored to blockchain.
nonSTaTiC nodes download the blockcahin and after done the download then will see all STaTiC public key and see also if the public key revoked.

5.) YES. The nonSTaTiC nodes created the blocks too but not broadcast. Each nonSTaTiC node validate the signed block and compare that the self
generated block. Therefore if any STaTiC try generate false blocks then nonSTaTiC nodes will recognise too.

6.) YES. See above. All node is able to independently create identical blocks not just STaTiC. Difference between nodes: the STaTiC is able to signing too.

7.) Some STaTiC online and some offline therefore no exact number how many needed. After offline STaTiC go to online then will signing
the all unsigned blocks. This work like the confirmation of transactions. Each client decide yourself how many signatures needed to accept
the block. Now just one STaTiC working therefore very easy this number is one and 100%. Need expermence founding the best ratio and number.
After all newly registered STaTiC begin the work we will see how many online and offline at a time. I don't know this number exactly before STaTiC.

8.) The first static is just temporary. Required this fast patch because nobody want mining zero rewarded blocks. After STaTiC registration success then
i will burning the checkpoint to source code. The first temporary STaTiC will be removed.
[5:28:07 PM] Borzalom: ----
[5:28:09 PM] Borzalom: remark:
These answers valid at now. This is experimental coin. If required i change the plans. Remember why no white book. Just the goal fixed. We want STaTiC nodes, community owned coin and code, community data storage system, new block signing method. I personaly want very very big community who help me reaching the goals. I know this is big goal but i hope i have enought experience and knowledge to reache these goals. I say every time This is not tipical investment money this is experimental money. I don't richer or poor if you bought or sell. This is not my money i just the developer who experimenting. I think my first goal to save investor money who invested to bitmox successed. This is a next step. I don't guarante to this next experimence will als success or not.
[6:47:41 PM] -- CCRevolution -- $: Hello, I just finished the video...
[6:47:47 PM] Borzalom: ok
[6:50:15 PM] -- CCRevolution -- $: I am going to post your response as is... there is no time. So, here is how I will preceed:

Thanks for the answers.

How does the network know when to produce a new block? A decentralized network like this can't keep a reliable timestamp--for example, Bitcoin has a timestamp that can be about ±2 hours, and that timestamp is embedded by miners into the block they mine.

Also, how do you ensure that all nodes truly do see all the same transactions? While distributed networks like these generally work in a flood-fill-like manner, all kinds of things can cause nodes on the network to have a slightly different mempool. If all nodes on distributed networks truly had identical mempools, we wouldn't be having discussions about block propagation on Bitcoin, or they would be significantly different and less interesting (see https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 for example).

To clarify a bit on the 'transaction contention' issue, here's an illustration:

Assume the existence of two transactions which conflict with one another (but are each independently valid), Tx₁ and Tx₂.

Purple nodes are normal STaTiC nodes, red ones are regular or STaTiC nodes controlled by the attacker.

The attacker node on the right releases Tx₁ and the blue nodes are the STaTiC nodes which are aware that Tx₁ exists on the network.

The attacker node on the left releases Tx₂ and the green nodes are the STaTiC nodes which are aware that Tx₂ exists on the network.

The remaining nodes on the network all hear about either Tx₁ or Tx₂. At this point, some STaTiC nodes believe Tx₁ to be legitimate and others believe Tx₂ to be legitimate, and can't reconcile without abandoning what they believe to be truth. It could be said that, once a block containing either Tx₁ or Tx₂ reaches 51% signature threshold, that the other STaTiC nodes would reconcile. But then the attack vector still exists: what about 3 attacker nodes and Tx₁, Tx₂, Tx₃ which all conflict? And you can't just change the signature threshold to 34%, because then the reconciliation problem moves up to the block level. And on that note: if you choose 51%, then control of a few STaTiC nodes could double-sign and potentially cause desynchronization.

On the note of compromising the original STaTiC node, it would theoretically allow a separate, perfectly-valid blockchain separately. Since at block, say, b_n only the single STaTiC node was relied on, then compromising it would allow creating a block b_n+1, and a block b_n+2, etc. And since none of these blocks on the attacker chain would include commitments of additional STaTiC nodes, that blockchain would only ever have that single authority, and could be created to arbitrary depth effortlessly.

Sorry for the delay in responding to this very important question.

This is the first time I have revealed this process after coming up with it about 1 year ago.

P2P systems work like this:

This is not the best type of network and therefore many problems exist. You have displayed some
of these problems, but more exist which is why we will be using a type of "overview" network.

This is another very big innovation we are implementing and no other coins use overview networks:

We will use what is referred to as a chord overview network where the the STaTiC and nonSTaTic nodes connect to "chord nodes". The "chord network" is a "virtual overview" or in other words, the upper layer of the network and we will call it the Virtual Chord Network.

The STaTiC nodes and the nonSTaTiC nodes create the blocks... All nodes create the same block and all blocks have the same blockhash. Therefore, all block have the same ID (we will explain later why contain all blocks contain the same transactions).

Transactions work exactly the same as the block creation and so now we can see that all blocks will be the same in each STaTiC and nonSTaTiC and later you will see why this is, as we continue this explanation.

Each node (STaTiC and nonSTaTiC) is connected to one "virtual chord node" the chord nodes are only virtual, instead of being real nodes. If the block is ID=1 ( or if we create transaction then TR ID ) then this block will create the #1 virtual chord node and will then send the created block to the #2, #4, #8 nodes (this is an example of a network with just 16 virtual chord nodes) the #2 will send to #3 #5 #9 and so on...

The block creation time is not uncontrolled either. So, if we use 160sec block time (just an example because 160 seconds is easier to understand with a 16 virtual chord system).

Therefore, the chord nodes create blocks as follows:

#1 between 0-10 seconds
#2 between 10-20
#3 between 20-30

and continuing to #16 up to 160 seconds.

However, we will use more chords of course as this is just a simplified example so the process is more easily understood.

Therefore, no transaction or block conflicts occur and every peer knows who will create the block and who will first distribute the block.

Added question: But what if that creator block is down or attacked? Does it switch to a different STaTiC?

Since all chord nodes are virtual it is impossible to DDOS. There are no IPs or other relay identities available to attack.

Chord nodes are virtual, so they are never removed:

#1S = #1 STaTiC
#1C = #1 virtual chord node

If just #1S is online ( only one STaTiC ) then:

#1S will control #1C-#16

If #1S-#3S is online, then:

#1S will control #1C-#5C
#2S will control #6C-#10C
#3S will control #11C-#16C

If any STaTiC goes offline, for example #3S, then #11C-#16C will be shared between #1S and #2S

This is the reason why it is not important how many STaTiC nodes exist or how many STaTiC nodes are online or offline. The number of overview virtual network nodes is a constant. The block and transaction time are not part of the ID.

So, one of the key points to answer your question is that all STaTiCs and other nodes do not have to learn about the blocks simultaneously... The transactions distribute throughout our network, sequentially, over the 120 second block time in intervals that eventually get out to the entire network before the next block is created.

With regard to network lag, this is not relevant because the network is virtual. Therefore if lag exists it is equal across the entire virtual network. So, the virtual overview network or the Virtual Chord Network solves the problems you bring up.

To simplify this explanation for those less technical:

P2P (peer to peer file sharing type systems) is like water in a lake. The Virtual Chord Network is like a series of canals. We use water, just like in the lake, but the lake is uncontrolled.