I have a few highly important technical questions about asset issuance that probably only a #ravencoin dev can answer posted here about fairness. 

I will post the questions and clear well written answers in a post, I do not want to create a back and forth mess of misinformation, so will summarize once the confusion clears.  Any help would be appreciated, I have to have these answered by Monday morning (Oct 29th) in order to make a platform recommendation, and if this is a go/no-go and go with something else.

Request Access
Quote 0 0
The gist of your question is "How does Ravencoin resolve asset name collisions when two (or more) transactions try to reserve the same asset name?"  

That is a fair question.

While I try to make things simple, the answer will use a few technical terms out of necessity.

Nodes that already have the name (in a block) will reject the transaction because the transaction is invalid - duplicate name.  Every full node holds a list of issued assets.

Nodes that do not have the name in its list, will check if the name is in the mempool (pre-confirmation).  If it does have the name, then it will reject the transaction, but the rejection does not trickle back to the issuing node.   The issuing node will not get an error back as the transaction might be propagated to some nodes and not others.  So until the asset has been confirmed in a block, it is possible for many issuances of the same asset to be in many mempools of different nodes, but two conflicting transactions will not be in the mempool of the same node.

It does not have to do with down-to-the-second timing.  There isn't any favoring for being "first", except that your transaction may have replicated to more nodes.

So how does this resolve?

Eventually, some node will solve a block - likely one that is a mining pool.  This transaction will be the winner, and the other transactions will be purged from the mempool, and therefore the 500 RVN will not be spent (not exactly refunded, but remaining a UTXO). 

We have run some multi-node tests, but this is difficult to test on a large scale, so the first week of Nov will be very experimental, as this code is new.   If you find any flaws in the code - before launch, please let us know so we can fix them and you will be eligible for 100,000 RVN bounty until the end of Nov, or the bounty funds are exhausted.

Assets are active on testnet, so you can set up as many testnet nodes as you'd like, and experiment with creating assets "at the same time"   Make sure you're using 2.1.1 or newer.  The source code is available, so you're welcome to examine it for the details of how it works, and how it handles block re-orgs and other challenging edge cases.

The other question was the timing for the activation of assets.

On Oct 31, 2018 at 00:00 UTC, the software will start looking for the next 2016 block boundary.  Once found -- could be 0 blocks (immediate), or could be 2015 blocks (~1.4 days).  Then it will start watching blocks, and counting the number of blocks that are mined with the asset aware software.   It is looking for the 90% threshold.  If not met, it will repeat this process every 2016 blocks.   Once met, it will "lock in", and then at the next 2016 block boundary (another ~1.4 days) it will become active.  This status will be reported by the getblockchaininfo rpc call for "BIP9" for "assets"

Quote 0 0
So the follow up question would then be:

Thank you for your reply, just now having time to circle back to this.  If anyone can please chime in on the next question.

As I understand it, if I request an asset, and am the first in line, having a provable time stamp requesting that asset before any others request it, I still may not get it.  The best way to secure an asset then is to have more nodes confirm it, before any of the others irrespective of other requests for the asset that were requested in close time.

Q:  The task then becomes: How do I get more confirmations, sitting here at home with a single box connected to the Internet?

Q: Can I add known, trusted, well connected influential nodes to raven.conf (would that help, and if so, adding what nodes would best help - send IP address list)?
If I set up a separate mining node of my own that I run, would adding that node IP to my personal box (resolv.conf), help?  (how would I confirm my own transaction?, at least get 1)

Any other ideas on how to get fast propagation of transactions would be most helpful, including resolv.conf params, any infrastructure or other.  This information is not just for asset allocation, but also to learn a few things, if the platform is wildly successful.

Quote 0 0
Is there any flag or switch I can add to my wallet-qt shortcut that will make the wallet mine or be a full node?
Quote 0 0
setgenerate true -1
Quote 1 0