Prevent double spending of a name in one block + Atlas network K-size

[mmkonrad]

Hi there,

After reading the whitepapers I have some questions I would like to know the answers to. I considered this part of the project as the correct address, since it covers documentation and published papers. If I am wrong about this, I would be happy if you point me into the right direction.

First question: How does blockstack prevent double spending of a name in the same blockchain block? The underlying Bitcoin blockchain has its own mechanisms to prevent double spending. Bit it came to my understanding that Blockstack operations are stored as additional metadata in a metadata field of a block header.

Do the same mechanisms of the blockchain apply there or how does blockstack prevent double spending in the same block?

The second question I have is about the Atlas network. It is said that the Atlas network implements a K-regular-random graph. It is just said that each nodes selects K other nodes but no further information was provided. I would like to know what the size of K is (in case it is a fixed number) or otherwise what determines its size?

Thank you very much for helping

Marcus

[larrysalibra]

Hi @mmkonrad ! Thanks for your questions!

First question: How does blockstack prevent double spending of a name in the same blockchain block? The underlying Bitcoin blockchain has its own mechanisms to prevent double spending. Bit it came to my understanding that Blockstack operations are stored as additional metadata in a metadata field of a block header.

Blockstack transaction data is stored in the OP_RETURN field of a bitcoin transaction.

Do the same mechanisms of the blockchain apply there or how does blockstack prevent double spending in the same block?

Blockstack uses the time ordering functionality from the underlying Bitcoin blockchain to prevent double spending of a name. For example, if I broadcast a transaction that is a name transfer operation transferring valuable.id to alice's bitcoin address at the same time as a broadcast a transaction that is a name transfer operation transferring valuable.id to bob's bitcoin address, the first transaction to be included in a bitcoin block is the valid transaction. The second transaction is invalid. These are enforced by the consensus rules in blockstack-core.

For example, image both alice and bob try to register cool.id at the same time. They would both send pre-register transactions for the name, both of which are valid bitcoin transactions. If both of these transactions are included by miners in the same bitcoin block, the transaction that occurs first in the list of transactions in that block is the valid one. The second one would be ignored by blockstack core.

The second question I have is about the Atlas network. It is said that the Atlas network implements a K-regular-random graph. It is just said that each nodes selects K other nodes but no further information was provided. I would like to know what the size of K is (in case it is a fixed number) or otherwise what determines its size?

@jcnelson is probably the best person to answer this question.

[mmkonrad]

Thank you @larrysalibra for your reply. You helped me a lot.

So it is true, that the same protocol (aka your implementation of the protocol) gets applied. That is the answer I was looking for.

[mmkonrad]

@larrysalibra I have a follow-up question:

Blockstack core is able to process the transaction regarding their timestamp and only accepts the first one in case of a name registration request.

My question is: One could try and tamper with the timestamp and set it to e.g. January 1st 1970 and therefore gets his/her name registration request accepted and other user's requests get denied by the virtualchain. Am I right guessing that you have implemented in your protocol that transactions (e.g. name registration requests) that are about to get written into the metadata field have to meet additional conditions regarding their timestamp?

If so what are these conditions/restrictions?

There have to be mechanisms/protocols to keep malicious users (or anybody from the outside who is just messing with the metadata of a Bitcoin block) from tampering with the blockstack transactions.

[mmkonrad]

@larrysalibra any ideas?

[jcnelson]

One could try and tamper with the timestamp and set it to e.g. January 1st 1970 and therefore gets his/her name registration request accepted and other user's requests get denied by the virtualchain.

Name operations are processed in the order in which they appear in the block (recall that Bitcoin does not timestamp individual transactions, but instead imposes a total ordering on transactions within a block). In the event that two different registration transactions for the same name appear in the same block, the first registration will be accepted and the second one will be rejected.

The second question I have is about the Atlas network. It is said that the Atlas network implements a K-regular-random graph. It is just said that each nodes selects K other nodes but no further information was provided. I would like to know what the size of K is (in case it is a fixed number) or otherwise what determines its size?

Each node will report up to 80 randomly-chosen neighbors who have a minimum peer health. Each node will remember up to 65536 peers, and will add at most 10 newly-discovered peers (chosen at random) and remove at most 10 unhealthy peers every five minutes. Peers are classified as "healthy" if they respond to RPC messages over 50% of the time, and "unhealthy" if they respond less frequently.

Each peer tries to build up a random unbiased sample of the global peer graph to calculate its neighbors. It does so by executing a random graph walk on the global peer network, using a variation of the Metropolis-Hastings graph sampling algorithm but tuned for sampling peer networks that undergo churn while the sampling takes place (see https://arxiv.org/pdf/1204.4140.pdf). Every five minutes, the peer attempts to take one step on the peer graph and learn the new peer's neighbors. The probability that a new peer is walked to is proportional to the ratio of its degree to the current peer's degree (this is typical Metropolis-Hastings). But, if the new peer is the same as the previous peer (i.e. this node backtracked), then a different neighbor is selected and the node walks to it instead of backtracking with a probability based on how much better connected the newly-sampled peer is than the current peer versus how much better connected the current peer is than the previous peer. This is meant to remove bias towards well-connected peers in the sampling algorithm.

[mmkonrad]

Thank you for taking your time for answering my questions. You helped me a lot.