Detail Whitepaper GitHub Comment Analysis

WebSite	https://particl.io/
GitHub	particl/particl-core
Update Date	2018 Oct 16 07:10:49

Circulating Supply	8,069,480
Total Supply	9,065,480
Max Supply	0
Price	$2.6620803
Volume 24h	$170,236
Market Cap	$21,481,604
Change 24h	-2.1%
Update Date	September 26th 2018, 2:02:19 am

v0.1

Satoshi Nakamoto, the visionary and creator of Bitcoin[1], originally intended that Bitcoin be paired with a marketplace, as evidenced by beginnings of a market framework included in early snapshots of the Bitcoin codebase.[2] The market related code was eventually stripped out however, presumably as he decided to focus first on creating his world changing currency. The concept of a decentralized marketplace in itself is not novel, there have been a small set of academic constructions and even serious attempts at creating them.[3], [4], [5], [6] They either propose solutions that scale extremely well and neglect the privacy implications, or they propose very privacy conscious solutions that do not scale well. Privacy and efficiency are often at odds with each other, ”to hide the signal there must be noise”. [7] Tor exemplifies this well, the traffic is pushed through various nodes with several layers of encryption before arriving at its destination, it is deliberately inefficient but the privacy provided by the trade-off is well worth it.

A transaction using the above mentioned script signature is unspendable therefore the output is also not added to the UTXO database due to OP RETURN. The fee however is available to the actors that ensure consensus, miners in the case of Bitcoin. The fee determines the duration for which a listing is active, serving as a mechanism to expire and automatically garbage collect references. The inputs of the listing registration transactions would reveal the financial history of whoever initiated the market listing thus a payment scheme which obfuscates the origin is required to maintain privacy. Another optional approach could be to require a short PoW phase instead of a fee, including an adjustable difficulty arguably like mining blocks, this prevents network spam yet has the additional benefit that it eliminates any potential trace to the financial history of whoever created the listing. To maintain interoperability with Bitcoin derivatives, we did not make this the primary option. See ’input correlation attack’ in the appendix.

If only the item public key is present in the deletion transaction then all of the listing id’s for that respective item public key will be deleted. If additionally a listing id is specified only that instance will be removed. If additionally a protocol id is specified then only the protocol for that respective listing id will be removed.
Note that OP REGLIST and OP DELLIST are ’virtual’ opcodes, they are always after OP RETURN, meaning there is no requirement to implement new opcodes into the scripting language of the blockchain it is operating on.
This draft does not yet include information pertaining the details to how categories should work. Ideally this is also stored in the registration transaction, allowing to categorize listings without putting an unnecessary stress of the DSN network. Performing searches, especially full text ones, over decentralized networks remains a hard problem.
B. Private payment scheme The transparent nature of the Bitcoin blockchain can potentially give away a trophy of information about the finances of the transaction creator. Therefore a payment scheme such as RingCT is required to shield the privacy of all users. It is worth noting that the payment scheme must provide hidden amounts to prevent a blockchain analysis technique that is described in the appendix of this document.
C. Identities The current system does not support linking items to an identity. In other words, buyers have no way to see what items one specific merchant has for sale. The primary reason is to disable a wide category of passive analysis techniques that this could enable. The time at which listings are registered on the blockchain for example can reveal the timezone of the merchant given they have posted enough items to the network. Identities also aggregate data about the possible funds of the merchant when registering listings.
A more nuanced vision is required to balance this issue.Insinuating that the listings can not be linked to each other breeds false sense of security to the merchants. Time,image and linguistic analysis can provide a crucial trophy of information to a passive adversary, generating a fairly unique fingerprint that is hard to reduce through software design. These are issues related to the input of humans and only can only be dealt with in a certain degree. The defacto removal of image metadata for example can greatly reduce the fingerprint, auto correcting words can provide improvements in linguistic analysis.
Branding and name awareness are a common practice in todays world and are vital to a good working of the market.It improves the overall level of trust as quality merchants can build long term relationships with their customers. Therefore having an identity system is a trade-off worth having, the economic benefits outweigh the seemingly small negative consequences to privacy, given that you take the analysis techniques into account.

The cryptography behind BitMessage is simplistic, there is only one key for decryption meaning an adversary can read all future and past messages once in possession of said key. The protocol in itself does not provide perfect forward secrecy, nor perfect future secrecy. These two features should not lack from an end-to-end encrypted messaging solution with a completely decentralized topology, mainly because adversaries can collect all messages and store them indefinitely. We can’t erase the encrypted messages from third parties therefore at least it should use a proper key ratchet and delete the private keys to decrypt the messages when they’re being deleted. Another issue is that the curve secp256k1 is hard to properly do in constant time. BitMessage solely relies on OpenSSL to do the cryptographic lifting for them.In recent years Bitcoin Core has developed their own faster and potentially more secure library libsecp256k1, removing the dependency on OpenSSL for the most part. Another concern is the fact that BitMessage (at the time of writing) still uses SHA1 as checksums with their ECDSA signature. SHA1 is a hash function for which the first collision has been found.[11]
The author of this paper has disclosed this but the maintainer of the PyBitMessage implementation was already aware and quickly replied with an upgrade plan, a move to SHA256 seems to be planned in the near future.

The marketplace as proposed in this paper provides an extensible framework that will operate on any Bitcoin-based blockchain and allows for a multitude of data storage network solutions to be utilized. The field of decentralized data storage is constantly expanding, it seems wise to not commit to one protocol when there are so many new innovations spurring everywhere, hence a generic approach was adopted.
A. Future research: Data Storage Networks One DSN was discussed, namely ’BitMessage’ because it does not leak details about lookups (what listings you’re viewing) to other nodes. A extended research will be the comparison of different solutions for data storage such as BitMessage, Kademlia, IPFS, MaidSafe etc. We chose to discuss BitMessage in this paper because the system design intuitively seems like the most privacy protective. A formal academic backing to this claim is planned as future research.
Scaleability however does remain a concern hence the reason why DHTs are a necessity. Private messaging on any DHT does remain a challenge, the receiver needs to be made aware of the hash of the message to be able to retrieve it.BitMessage and RMIDs can help solve this issue by linking RMIDs to hashes that can be retrieved on a DHT.