Bitcoin Forum
July 20, 2019, 11:24:55 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 [252]
  Print  
Author Topic: [ANN][CRW] CROWN (MN-PoS) | Platform | Governance | Systemnodes | Masternodes |  (Read 304755 times)
Do_zzze
Newbie
*
Offline Offline

Activity: 59
Merit: 0


View Profile WWW
July 05, 2019, 09:03:29 PM
 #5021

Sorry friends. You will soon be delisted by Bittrex and its sucker Litebit.eu too
1563665095
Hero Member
*
Offline Offline

Posts: 1563665095

View Profile Personal Message (Offline)

Ignore
1563665095
Reply with quote  #2

1563665095
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
crowncoin_knight
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500


View Profile WWW
July 06, 2019, 08:15:32 AM
 #5022


https://medium.com/crownplatform/development-update-july-2019-52410ddf09df

Development update July 2019

Slow is smooth. Smooth is fast.

Another month has flown by; it’ll be Christmas before you know it! In that time there have been some notable achievements on the Crown development fronts.

NFTs
Artem released technical documentation on the NFT framework on 20 June and v0.13.9 in testnet the next day. This is alpha software designed to foster collaborative development. There is enough functionality for developers to start developing applications and to identify problems, friction points and desirable changes or enhancements. Artem already has a list of next steps including NFT registration and trading but has spent most of the last couple of weeks working on the sandbox environment and a database corruption problem.

Crown contributor Andy D (defunctec) is working on a simple NFT generator addition to the https://crwwallet.net/ site to facilitate end-user experimentation. It will probably be available within the next few days and will allow less-technical users to create and experiment with NFTs without having to venture too close to a command line.

If you’d like to be more directly involved in testing and need any help getting started, please contact us in Discord.

Codebase update
Ashot has been ploughing through the thousands of commits which differentiate Bitcoin from Crown and carefully merging the two codebases together. He has also been working on the build environment. He has compiled all of the Bitcoin v0.17 depends but the main code compile is currently failing with Boost errors. This is very much a marathon rather than a sprint and it will be many more months before it is complete.

Most altcoins forked from Dash or PIVX or Bitcoin are forked from very old versions and very few are still under active development. Crown is here for the long term and we recognise the need to plan for the future by upgrading the existing codebase to something much more modern. This will bring security, speed and stability improvements, and allow for easier maintenance in the future.

Trezor
We are still waiting for Satoshi Labs to release the next Trezor wallet firmware upgrade. They don’t have a published timetable for doing so, but based on past update frequency we think it could well happen this month.

Additional development
We currently have only two full-time developers, but we have more development ideas than they can possibly achieve (in a reasonable timescale) on their own. We had a conference call today with Tom (press tab), the external developer of our class-leading MNPoS staking system regarding improvements to the Crown decentralised governance system. A couple of the key changes we would like to implement are on-chain voting and systemnode voting.

The current governance system is based on the early Dash governance system and is a fragile and temperamental beast. Our developers have already spent a lot of time working on stabilising and improving it. Much of the groundwork for on-chain voting has already been done, but was set aside in favour of higher priority work. We think that groundwork could be adapted to use the NFT framework to provide on-chain voting and systemnode voting at the same time.

Tom has agreed to review the not-yet activated code changes with a view to submitting a proposal for superblock payment to gradually build out the new functionality we would like to have, starting with on-chain and systemnode voting. Before even seeing the code he was able to give us (very rough) guestimates for the development effort/time required for several Crown platform enhancements.

Hopefully, following the review, he will be able to leverage the existing work done by Volodymyr and Artem and submit a proposal for 5k CRW per superblock, to be matched by community contributions. At this level of funding, and with the current CRW/BTC price, an 8-point estimate task could be paid for in about 2–3 months.

This level of funding is a drop in the ocean for many newer, ICO-funded, all fluff and no substance projects. It represents a much more significant commitment for an older, honest, hard-working project like Crown. We will be counting on the continued support of the Crown whales to make these platform enhancements possible.

There is a chance the first proposal will be ready in time for the next superblock (block 2462400, expected around 18th July 2019).
Would you like to know more?

There are bi-weekly development update calls which all community members are welcome to participate in. Details are available in the #development contributor channel in Discord.

Questions, comments and suggestions are always welcome. Crown is a community project and the more engagement we have, the stronger our kingdom is.

.. 
▄▄█▀▀▀▀▀▀▀█▄▄
▄█▀▀▀           ▀▀▀█▄
▄█▀▀                   ▀▀█▄
▄█▀                         ▀█▄
█▀                             ▀█
█▀               █               ▀█
█▀              ▄█▀                ▀█
      █▄▄▄  ▄▄█▀   ▀█▄▄  ▄▄▄█      █
       █▄▀▀▀▀         ▀▀▀▀▄█       █
        ▀█               █▀        █
█▄
        ▀█   ▄▄█▀▀█▄▄  █▀        ▄█
█▄
         ▀          ▀▀         ▄█
█▄                             ▄█
▀█▄                         ▄█▀
▀█▄▄
                   ▄▄█▀
▀█▄▄▄           ▄▄▄█▀
▀▀█▄▄▄▄▄▄▄█▀▀
  CROWN█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
  MERGE MINING            THRONES            CORE UPDATES
█████████████████████████████████████████   twitter  ██████████████████████ slack  ██████████████████████ ANN Thread  █████████████████████████████████████████
█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
Stabycroc
Member
**
Offline Offline

Activity: 358
Merit: 24


View Profile
July 06, 2019, 08:44:09 AM
 #5023

Sorry friends. You will soon be delisted by Bittrex and its sucker Litebit.eu too

Yip how to kill a great spec'ed coin ( old Og crw specs ) threw dev greed and bad mn governance and real bad new spec without showing total superblock amount ( to try hide dev greed ) and hide fake non productive mn proposals.....

im sure they will just do another superblock of crw to buy more play time at trex....premining cheats....Crw was never premine till greedy devs made it so.
Stabycroc
Member
**
Offline Offline

Activity: 358
Merit: 24


View Profile
July 07, 2019, 05:49:14 AM
 #5024

"Questions, comments and suggestions are always welcome. Crown is a community project and the more engagement we have, the stronger our kingdom is."'

Gave u ( miss do llil ) and OG dev's advice for years but "that was then and this is now" & u dont listen to pro crypto advice and dont give props to whome gave u that pr advice when u bring it in 6-12 after advised to do so.

Get rid of mn proposal system as its clearly done alot worse than good for crw price and long term holders ( clearly devs dont want to make CRW a long term coin like its was originally made to be, cuz they been advised abit this issues for years and still nothing done about it )..

MS-POs rewards should be enough for the masternode/systemnode holders & is another reason to get rid of Mn proposal system.
 
limit the amount of mn/system nodes to 50, if u think u need more than that your joking/got no clue and just another way if u dont that crw price will drop more and ability for the node system to be abused.

To the rest of the crw holders watch they will ignore me and in 6-12months will use my pro advice to try dig there way out of massive hole they dug.....

Ps i was 1 of the main CRW tanks in the old specs and held alot and still hold alot, never dumped when i controlled alot of the % of crw ...
i could of dumped years ago and made it go from 60k to 100sat but didnt to help project biuld but then to get raped by bad so called devs, i kind of wish i did and killed crw then and there.
 
Not threw MN proposal or superblock premine or mn reward i got them buying and sha mining....
I and other old guards of crypto tanked crw for the devs and now they rape and pillage the people that made CRW great for there own greed and for the greed of mn proposal makers that show nil returns for work done but even worse they just make price drop more and more..
devs not governing the proposal system like they should be and just letting it be a free for all

Da ja
Stabycroc ;_)>
Do_zzze
Newbie
*
Offline Offline

Activity: 59
Merit: 0


View Profile WWW
July 07, 2019, 07:50:11 AM
 #5025

Is it possible to do two masternodes on the same computer / wallet with crw? As repealed the addressing of port 9340? I know they did this on VIOG (evolution) and now it is possible to "patch" MN easily via windows and thus own several MN that can be used on the same workstation.

So is it possible to reduce system consumption and make it load the blockchain faster? I ask this because all this is already done on VIOG making loading very fast and the consumption of MN drastically divided. This could be an asset for your CRW Smiley

-.xXx.-
Newbie
*
Offline Offline

Activity: 54
Merit: 0


View Profile WWW
July 09, 2019, 01:34:49 AM
 #5026

nice is reloaded https://crwfaucet.com
crowncoin_knight
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500


View Profile WWW
July 09, 2019, 07:23:31 AM
Last edit: July 09, 2019, 10:15:59 AM by crowncoin_knight
 #5027

Is it possible to do two masternodes on the same computer / wallet with crw? As repealed the addressing of port 9340? I know they did this on VIOG (evolution) and now it is possible to "patch" MN easily via windows and thus own several MN that can be used on the same workstation.

So is it possible to reduce system consumption and make it load the blockchain faster? I ask this because all this is already done on VIOG making loading very fast and the consumption of MN drastically divided. This could be an asset for your CRW Smiley



It would be very easy to remove the port restriction but not a good idea from the network security perspective. If VIOG is so great you should stick to running VIOG.  Smiley

.. 
▄▄█▀▀▀▀▀▀▀█▄▄
▄█▀▀▀           ▀▀▀█▄
▄█▀▀                   ▀▀█▄
▄█▀                         ▀█▄
█▀                             ▀█
█▀               █               ▀█
█▀              ▄█▀                ▀█
      █▄▄▄  ▄▄█▀   ▀█▄▄  ▄▄▄█      █
       █▄▀▀▀▀         ▀▀▀▀▄█       █
        ▀█               █▀        █
█▄
        ▀█   ▄▄█▀▀█▄▄  █▀        ▄█
█▄
         ▀          ▀▀         ▄█
█▄                             ▄█
▀█▄                         ▄█▀
▀█▄▄
                   ▄▄█▀
▀█▄▄▄           ▄▄▄█▀
▀▀█▄▄▄▄▄▄▄█▀▀
  CROWN█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
  MERGE MINING            THRONES            CORE UPDATES
█████████████████████████████████████████   twitter  ██████████████████████ slack  ██████████████████████ ANN Thread  █████████████████████████████████████████
█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
Do_zzze
Newbie
*
Offline Offline

Activity: 59
Merit: 0


View Profile WWW
July 09, 2019, 11:50:34 AM
 #5028

Is it possible to do two masternodes on the same computer / wallet with crw? As repealed the addressing of port 9340? I know they did this on VIOG (evolution) and now it is possible to "patch" MN easily via windows and thus own several MN that can be used on the same workstation.

So is it possible to reduce system consumption and make it load the blockchain faster? I ask this because all this is already done on VIOG making loading very fast and the consumption of MN drastically divided. This could be an asset for your CRW Smiley



It would be very easy to remove the port restriction but not a good idea from the network security perspective. If VIOG is so great you should stick to running VIOG.  Smiley


It was just a suggestion to allow several MN and SYS or run at the same time. Security will not be affected either, as you know very well. Technically where does CRW go?  What is the purpose? Smart Contract, DEX, Multi Blockchains creations, swap....... ?
Mountain_Crew
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
July 09, 2019, 11:55:49 AM
 #5029

It was just a suggestion to allow several MN and SYS or run at the same time. Security will not be affected either, as you know very well. Technically where does CRW go?  What is the purpose? Smart Contract, DEX, Multi Blockchains creations, swap....... ?

I agree with this point.
Because right now crowncoin_knight seem to be in a trendy and blind Titanic.
crowncoin_knight
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500


View Profile WWW
July 09, 2019, 02:42:55 PM
 #5030

Is it possible to do two masternodes on the same computer / wallet with crw? As repealed the addressing of port 9340? I know they did this on VIOG (evolution) and now it is possible to "patch" MN easily via windows and thus own several MN that can be used on the same workstation.

So is it possible to reduce system consumption and make it load the blockchain faster? I ask this because all this is already done on VIOG making loading very fast and the consumption of MN drastically divided. This could be an asset for your CRW Smiley



It would be very easy to remove the port restriction but not a good idea from the network security perspective. If VIOG is so great you should stick to running VIOG.  Smiley


It was just a suggestion to allow several MN and SYS or run at the same time. Security will not be affected either, as you know very well. Technically where does CRW go?  What is the purpose? Smart Contract, DEX, Multi Blockchains creations, swap....... ?

I pasted your question in our discord chat where devs hang out and the answer from one of them was the above. In terms of where we going, maybe you should read the messages above - its all being pasted. After the implementation of MNPoS where nodes generate blocks https://medium.com/crownplatform/crown-masternode-and-sytemnode-proof-of-stake-consensus-system-mnpos-e6780ef534b3

the next step is NFT framework which is in testnet already and being tested by devs, join in if you are interested

https://medium.com/crownplatform/crown-platform-nft-framework-18d88f9db76

.. 
▄▄█▀▀▀▀▀▀▀█▄▄
▄█▀▀▀           ▀▀▀█▄
▄█▀▀                   ▀▀█▄
▄█▀                         ▀█▄
█▀                             ▀█
█▀               █               ▀█
█▀              ▄█▀                ▀█
      █▄▄▄  ▄▄█▀   ▀█▄▄  ▄▄▄█      █
       █▄▀▀▀▀         ▀▀▀▀▄█       █
        ▀█               █▀        █
█▄
        ▀█   ▄▄█▀▀█▄▄  █▀        ▄█
█▄
         ▀          ▀▀         ▄█
█▄                             ▄█
▀█▄                         ▄█▀
▀█▄▄
                   ▄▄█▀
▀█▄▄▄           ▄▄▄█▀
▀▀█▄▄▄▄▄▄▄█▀▀
  CROWN█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
  MERGE MINING            THRONES            CORE UPDATES
█████████████████████████████████████████   twitter  ██████████████████████ slack  ██████████████████████ ANN Thread  █████████████████████████████████████████
█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
crowncoin_knight
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500


View Profile WWW
July 09, 2019, 02:49:25 PM
 #5031

It was just a suggestion to allow several MN and SYS or run at the same time. Security will not be affected either, as you know very well. Technically where does CRW go?  What is the purpose? Smart Contract, DEX, Multi Blockchains creations, swap....... ?

I agree with this point.
Because right now crowncoin_knight seem to be in a trendy and blind Titanic.

sorry man, but I am just a small contributor nothing less and nothing more, just like dozens more who however hang out in our development rooms in discord. If you watched the Titanic story closely you would know that the ship was designed with a fault, Crown will celebrate its 5th birthday in October 2019 where the community of mostly volunteers was able to keep the blockchain going and will do so for many more.

thank you for your opinion  Smiley

.. 
▄▄█▀▀▀▀▀▀▀█▄▄
▄█▀▀▀           ▀▀▀█▄
▄█▀▀                   ▀▀█▄
▄█▀                         ▀█▄
█▀                             ▀█
█▀               █               ▀█
█▀              ▄█▀                ▀█
      █▄▄▄  ▄▄█▀   ▀█▄▄  ▄▄▄█      █
       █▄▀▀▀▀         ▀▀▀▀▄█       █
        ▀█               █▀        █
█▄
        ▀█   ▄▄█▀▀█▄▄  █▀        ▄█
█▄
         ▀          ▀▀         ▄█
█▄                             ▄█
▀█▄                         ▄█▀
▀█▄▄
                   ▄▄█▀
▀█▄▄▄           ▄▄▄█▀
▀▀█▄▄▄▄▄▄▄█▀▀
  CROWN█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
  MERGE MINING            THRONES            CORE UPDATES
█████████████████████████████████████████   twitter  ██████████████████████ slack  ██████████████████████ ANN Thread  █████████████████████████████████████████
█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
Do_zzze
Newbie
*
Offline Offline

Activity: 59
Merit: 0


View Profile WWW
July 09, 2019, 03:16:26 PM
 #5032

Your defective conception is probably your main structure, marketing, scaling up, adoption, business plan, new technology.... all this is non-existent. it is asked here what is the objective of CRW, evolutions, marketing... and you redirect me to an irrelevant instruction manual studied same result in 2014.

Quote
https://medium.com/crownplatform/crown-masternode-and-sytemnode-proof-of-stake-consensus-system-mnpos-e6780ef534b3

Crown Masternode and Sytemnode Proof of Stake Consensus System [MNPoS]
Technical specifications for Crown MNPoS
Go to the profile of J. Herranz
J. Herranz
Mar 28
The following is a detailed technical description of the Crown MNPoS consensus system. It explains the context of development, ellaborates on the solutions given to all detected conventional Proof of Stake vulnerabilities, and gives an overview of the system and its terminology. If you have any questions, please do not hesitate to join the Crown GitLab/social networks and ask them!


Crown MNPoS solves detected vulnerabilities in other PoS systems and ascends Masternodes and Systemnodes to consensus kings.
a) History

b) Traditional Proof of Stake Attack Vectors and Mitigation

1) Long Range
2) Nothing at Stake
3) Stake Grinding
4) Overcrowding / Undercrowding
5) Masternode Set Disagreement
c) Masternode Proof of Stake Consensus System Overview and Terminology

a) History
The Crown Masternode Proof of Stake system was commissioned in Summer 2018 and delivered in Spring 2019 in the Crown v0.13.0 ("Jade") release. It was designed to overcome known attack vectors in existing Proof of Stake consensus mechanisms, and to provide a unique cold staking solution.

b) Traditional Proof of Stake Attack Vectors and Mitigation
5 specific attack vectors were identified and mitigation techniques developed. Additionally, during development the much publicised "fake stake" attack vectors were addressed.

1. Long Range
Description
An attacker overtakes the main chain by producing a competing chain using past staking balances. For example, assume an attacker has a moderately large stake in the network then exchanges their stake for another cryptocurrency (or for fiat). They no longer have a stake in the network at the most recent block but their past stake is still viable from the perspective of some older blocks. This attacker may collude with other attackers who've followed the same steps until they reach 51% of the supply at that point in time. Now they have the ability to quickly generate a fork by forging previous time stamps until the height of the fork is equal to the height of the main chain. This can be done in such a way that the trust scores of the two chains are very close. Without additional safeguards, honest nodes would not be able to differentiate between the honest chain and the attacker's chain, thus potentially forcing a reorg.

Solution
A maximum reorganization depth completely mitigates long range attacks on online validating nodes. The issue still exists for inactive nodes who are re-syncing with the network and new nodes who are syncing for the first time. A fixed checkpointing system is used to prevent syncing nodes from syncing with the attacker's chain. This is done by either directly encoding checkpoints into the source code (long interval checkpointing) or broadcasting checkpoints from a trusted source (short interval checkpointing). Although these solutions may introduce other issues, they do drastically reduce the likelihood of a long range attack.

2. Nothing at Stake
Description
A distinction must be made between honest, rationally self interested, and malicious nodes. Honest nodes will always align their actions with what is best for the network. Rationally self interested nodes don't aim to compromise the network but their self interest may lead them in that direction if the incentive structure facilitates it. A malicious node's only goal is to compromise the network. Now imagine a chain with multiple competing forks. No node can be sure which fork will ultimately win, so in order to improve their expected value the rationally self interested nodes stake on every fork. This is an issue for two core reasons: 1. it can cause uncontrollable forking because the network can't reach a consensus on what the main chain is and 2. the stake threshold an attacker needs to launch a 51% attack is reduced because the rationally self interested nodes will effectively assist in the attack by staking on the attacker's chain.

Solution
The double-block protection mechanism allows for the cancellation of the top block for double stakes. This partially mitigates the risk of the nothing at stake attack being successful. Additionally, the rationally self interested nodes may have an incentive to stake on as many chains as possible to increase returns but they also have an incentive to help the network reach consensus in a timely manner. Otherwise, they run the risk of losing their entire deposit due to the dysfunctional network. When considering these positive factors, the likelihood of the nothing at stake problem occurring in reality is very low from both an economic and technical standpoint.

3. Stake Grinding
Description
Also known as a pre-computation attack. If there is no context based entropy included in the target calculation then the staker can calculate the future target values that their stake will produce. With this information the staker now has no incentive to remain online before they expect to successfully stake a block. This reduces the quantity of active verifying nodes and thus reduces the security of the network. If the nodes were unable to determine when they would successfully stake then they would have to remain online consistently. Another attack that is based on this same principle is pre-computing the outcome of different events and using the results of those computations to determine how to increase the likelihood of staking consecutive blocks. The act of computing all the possible outcomes is called Stake Grinding and essentially reduces proof of stake consensus to bitcoin's original proof of work consensus that proof of stake was meant to replace.

Solution
The process of including chain based entropy into the target hash calculation is known as stake modification. The more the stake modifier can obfuscate future target hashes, the more difficult it becomes to successfully launch a stake grinding attack. Different stake modification schemes provide different degrees of obfuscation so it's crucial to use the best one available. The most advanced stake modification schemes include deterministic sampling of entropy from previous blocks within the modifier interval and change significantly from block to block. This makes pre-computation attacks unfeasible for any realistic amount of computing power.

4. Overcrowding/Undercrowding
Description
In order for a node to be able to successfully stake a block they must provide the proof pointer to their most recent masternode or systemnode reward transaction. The proof pointer is only valid if the payment occurred at most some minimum number of blocks earlier in the chain. This proof pointer interval can be exploited under certain circumstances if not designed with enough flexibility. If the number of active masternodes increases substantially over time then the proportion of them who are able to stake may decrease. This essentially reduces the size of the validator node set and opens up the opportunity for an attacker who holds less than 51% stake in the network to launch an attack. This attack vector is called overcrowding.

It's also possible to have the opposite problem of a substantial decrease in active masternodes. Consider a masternode that goes offline immediately after their most recent masternode payment. They are still eligible to stake for some amount of time after they go offline. From an incentive structure point of view, it's important that a large proportion of the nodes staking are active masternodes. Otherwise, a node can act as a masternode for a short amount of time (until they receive their first reward) because there aren't many masternodes in the queue. Then, they deactivate the masternode but are able to continue staking for a long period of time. This attack vector is called undercrowding.

Solution
This issue necessitates a dynamic but deterministically generated proof pointer interval based on the network's current knowledge of the masternode set size. Because it requires knowledge of the masternode set size, this model assumes some minimum threshold of consistency across the network in terms of what each node perceives to be the active masternode set. To fulfil this requirement a large sampling interval can be chosen to determine the distribution of masternode rewards for specific public keys. This information can be used to construct the likely size of the set in a deterministic way. The size can then be used to update the proof pointer interval every n blocks.

5. Masternode Set Disagreement
Description
The issue of disagreeing on the state of the masternode set here is similar to the causes behind the overcrowding problem; except in this case it isn't just the size of the set that's important, it's also the ordering of masternodes within the queue. The order of the queue determines which masternode will receive a reward next, and any newly proposed block that does not include the correct masternode reward will be rejected by the network. This works as intended the majority of the time but if there's significant disagreement on the queue ordering then this validation requirement can cause uncontrollable forking. A hard fork is a good example of a situation that can lead to disagreement on the queue ordering and the composition of the masternode set.

Solution
The spork system can be utilized to temporarily change consensus rules during especially contentious periods on the network. Spork 8 in the existing spork system (MASTERNODE_PAYMENT_ENFORCEMENT) can be used to disable checks on the masternode payments included in blocks. This would eliminate the issue of uncontrollable forking. The problem is that if an attacker were able to stake many blocks during this period of disabled masternode payment enforcement, they can significantly influence the masternode reward distribution. The distribution is used to deterministically calculate the proof pointer interval so the attacker would be able to manipulate the future behaviour of the network. A couple of different strategies can be employed to mitigate this. One option is to reduce the amount of time the spork is disabled as much as possible so that an attacker wouldn't be able to cause a noticeable change in distribution. If this isn't possible then protocol level solutions need to be implemented. For example, a larger sampling interval would reduce the attacker's impact, but this may produce unwanted externalities under certain conditions. Another approach is to mark newly created blocks and ignore them in future sampling processes.

c) Crown Masternode Proof of Stake Consensus System Overview
The proof of stake consensus system for Crown allows both masternodes and systemnodes to create new blocks and add them to the blockchain. Users do not need to run hot wallets to participate in the staking process.


Staking Process and Terminology
Masternodes and systemnodes are required to have an amount of CRW “locked” (called node collateral) from use in order to be considered an active node and receive node rewards. In a traditional proof of stake consensus system a stake holder would consume their stake input (coins/UTXO) and be issued fresh coins that include the staking reward plus the value of the stake input that was consumed. Since being an active masternode or systemnode requires that node to keep their collateral untouched, this model is modified for Crown’s system.

Stake Pointers
Crown’s consensus system uses a new concept called stake pointers. A stake pointer can be thought of as a stakeable token that is given to masternodes and systemnodes, and is the input that is consumed by the proof of stake transaction. Stake pointers are “given” to masternodes and systemnodes when they receive masternode and systemnode rewards. Stake pointers are time sensitive (expire 2 days after being issued) and are what are used to determine whether a masternode or systemnode is at least "recently active". Since the list of active masternodes and systemnodes is not deterministic (not stored on the blockchain and is based on each peer’s interpretation of which have been validated) it means that simply checking if a node is considered active is something that could lead to unintentional forks because of disagreements from peers over which node may or may not be considered active. By using the stake pointer system, a peer is able to determine that the staking node was at least active within a recent period of time.

Stake pointers can only be used once. When a node stakes a block with their stake pointer, the pointer is marked as used, and the node will not be able to use that pointer again. If the node has multiple stake pointers, it will still be able to stake any of the unused pointers before they expire.

At the most technical level, a stake pointer is simply the transaction hash and the output position that a masternode or systemnode was paid their rewards in.

Stake Selection
Like traditional proof systems such as proof of work and most implementations of proof of stake, Crown uses a target difficulty for each block and the proof hash must be below the target value. A proof hash is done by hashing together the following inputs:

Stakepointer Hash: The transaction hash that the node reward was paid.
Stakepointer Output Index: The position in the vout vector that the reward was paid.
Stake Modifier: The block hash that is 100 blocks before the stakepointer.
Timestamp of Stakepointer: The time that the stakepointer was created.
Timestamp of the New Stake: The time that the new stake was created.

Proof Hash Generation
By hashing the above inputs, a 256 bit proof hash is created. The value of the proof hash is then compared to the difficulty target value multiplied by the value of collateral that the node is holding (10,000 for masternode, 500 for systemnode). If the proof hash is less than the new target, then the stake is considered valid and can be used to package a block and add it to the blockchain. By multiplying the target value by the collateral amount, this means that the target is easier to hit for masternodes than it is for systemnodes.

Finding a Valid Proof Hash (Stake Mining)
Every input that is in the proof hash, except for the timestamp of the new stake, is constant for a given stake pointer. What this means is that if someone had two different computers with identical wallets and stakepointers, it would give no advantage to their ability to find a valid proof hash because they would produce the exact same hashes. Given the same set of inputs and using the same timestamp for the stake that is being created, the proof hash will always come out the same. What this means is that each stakepointer can simply create a new proof hash for every second that passes, and see if it is less than the difficulty target. If the proof hash is less than the target, the stake is packaged into a block and the node has successfully staked. If the proof hash is more than the target, the node waits another second and then tries creating a new proof hash. This process is continually repeated while a node has valid stake pointers.


Bonus : https://www.youtube.com/watch?v=DNyKDI9pn0Q



So evolved that the resources are very important (too much) that it is not allowed to run a SYS and an MN together...  It is really a pity this limited vision. I now understand all this frustration that I've read before on CROWN and its ghost community.

Have Good delisting, dudes.
crowncoin_knight
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500


View Profile WWW
July 09, 2019, 07:36:20 PM
 #5033

Your defective conception is probably your main structure, marketing, scaling up, adoption, business plan, new technology.... all this is non-existent. it is asked here what is the objective of CRW, evolutions, marketing... and you redirect me to an irrelevant instruction manual studied same result in 2014.

Quote
https://medium.com/crownplatform/crown-masternode-and-sytemnode-proof-of-stake-consensus-system-mnpos-e6780ef534b3

Crown Masternode and Sytemnode Proof of Stake Consensus System [MNPoS]
Technical specifications for Crown MNPoS
Go to the profile of J. Herranz
J. Herranz
Mar 28
The following is a detailed technical description of the Crown MNPoS consensus system. It explains the context of development, ellaborates on the solutions given to all detected conventional Proof of Stake vulnerabilities, and gives an overview of the system and its terminology. If you have any questions, please do not hesitate to join the Crown GitLab/social networks and ask them!


Crown MNPoS solves detected vulnerabilities in other PoS systems and ascends Masternodes and Systemnodes to consensus kings.
a) History

b) Traditional Proof of Stake Attack Vectors and Mitigation

1) Long Range
2) Nothing at Stake
3) Stake Grinding
4) Overcrowding / Undercrowding
5) Masternode Set Disagreement
c) Masternode Proof of Stake Consensus System Overview and Terminology

a) History
The Crown Masternode Proof of Stake system was commissioned in Summer 2018 and delivered in Spring 2019 in the Crown v0.13.0 ("Jade") release. It was designed to overcome known attack vectors in existing Proof of Stake consensus mechanisms, and to provide a unique cold staking solution.

b) Traditional Proof of Stake Attack Vectors and Mitigation
5 specific attack vectors were identified and mitigation techniques developed. Additionally, during development the much publicised "fake stake" attack vectors were addressed.

1. Long Range
Description
An attacker overtakes the main chain by producing a competing chain using past staking balances. For example, assume an attacker has a moderately large stake in the network then exchanges their stake for another cryptocurrency (or for fiat). They no longer have a stake in the network at the most recent block but their past stake is still viable from the perspective of some older blocks. This attacker may collude with other attackers who've followed the same steps until they reach 51% of the supply at that point in time. Now they have the ability to quickly generate a fork by forging previous time stamps until the height of the fork is equal to the height of the main chain. This can be done in such a way that the trust scores of the two chains are very close. Without additional safeguards, honest nodes would not be able to differentiate between the honest chain and the attacker's chain, thus potentially forcing a reorg.

Solution
A maximum reorganization depth completely mitigates long range attacks on online validating nodes. The issue still exists for inactive nodes who are re-syncing with the network and new nodes who are syncing for the first time. A fixed checkpointing system is used to prevent syncing nodes from syncing with the attacker's chain. This is done by either directly encoding checkpoints into the source code (long interval checkpointing) or broadcasting checkpoints from a trusted source (short interval checkpointing). Although these solutions may introduce other issues, they do drastically reduce the likelihood of a long range attack.

2. Nothing at Stake
Description
A distinction must be made between honest, rationally self interested, and malicious nodes. Honest nodes will always align their actions with what is best for the network. Rationally self interested nodes don't aim to compromise the network but their self interest may lead them in that direction if the incentive structure facilitates it. A malicious node's only goal is to compromise the network. Now imagine a chain with multiple competing forks. No node can be sure which fork will ultimately win, so in order to improve their expected value the rationally self interested nodes stake on every fork. This is an issue for two core reasons: 1. it can cause uncontrollable forking because the network can't reach a consensus on what the main chain is and 2. the stake threshold an attacker needs to launch a 51% attack is reduced because the rationally self interested nodes will effectively assist in the attack by staking on the attacker's chain.

Solution
The double-block protection mechanism allows for the cancellation of the top block for double stakes. This partially mitigates the risk of the nothing at stake attack being successful. Additionally, the rationally self interested nodes may have an incentive to stake on as many chains as possible to increase returns but they also have an incentive to help the network reach consensus in a timely manner. Otherwise, they run the risk of losing their entire deposit due to the dysfunctional network. When considering these positive factors, the likelihood of the nothing at stake problem occurring in reality is very low from both an economic and technical standpoint.

3. Stake Grinding
Description
Also known as a pre-computation attack. If there is no context based entropy included in the target calculation then the staker can calculate the future target values that their stake will produce. With this information the staker now has no incentive to remain online before they expect to successfully stake a block. This reduces the quantity of active verifying nodes and thus reduces the security of the network. If the nodes were unable to determine when they would successfully stake then they would have to remain online consistently. Another attack that is based on this same principle is pre-computing the outcome of different events and using the results of those computations to determine how to increase the likelihood of staking consecutive blocks. The act of computing all the possible outcomes is called Stake Grinding and essentially reduces proof of stake consensus to bitcoin's original proof of work consensus that proof of stake was meant to replace.

Solution
The process of including chain based entropy into the target hash calculation is known as stake modification. The more the stake modifier can obfuscate future target hashes, the more difficult it becomes to successfully launch a stake grinding attack. Different stake modification schemes provide different degrees of obfuscation so it's crucial to use the best one available. The most advanced stake modification schemes include deterministic sampling of entropy from previous blocks within the modifier interval and change significantly from block to block. This makes pre-computation attacks unfeasible for any realistic amount of computing power.

4. Overcrowding/Undercrowding
Description
In order for a node to be able to successfully stake a block they must provide the proof pointer to their most recent masternode or systemnode reward transaction. The proof pointer is only valid if the payment occurred at most some minimum number of blocks earlier in the chain. This proof pointer interval can be exploited under certain circumstances if not designed with enough flexibility. If the number of active masternodes increases substantially over time then the proportion of them who are able to stake may decrease. This essentially reduces the size of the validator node set and opens up the opportunity for an attacker who holds less than 51% stake in the network to launch an attack. This attack vector is called overcrowding.

It's also possible to have the opposite problem of a substantial decrease in active masternodes. Consider a masternode that goes offline immediately after their most recent masternode payment. They are still eligible to stake for some amount of time after they go offline. From an incentive structure point of view, it's important that a large proportion of the nodes staking are active masternodes. Otherwise, a node can act as a masternode for a short amount of time (until they receive their first reward) because there aren't many masternodes in the queue. Then, they deactivate the masternode but are able to continue staking for a long period of time. This attack vector is called undercrowding.

Solution
This issue necessitates a dynamic but deterministically generated proof pointer interval based on the network's current knowledge of the masternode set size. Because it requires knowledge of the masternode set size, this model assumes some minimum threshold of consistency across the network in terms of what each node perceives to be the active masternode set. To fulfil this requirement a large sampling interval can be chosen to determine the distribution of masternode rewards for specific public keys. This information can be used to construct the likely size of the set in a deterministic way. The size can then be used to update the proof pointer interval every n blocks.

5. Masternode Set Disagreement
Description
The issue of disagreeing on the state of the masternode set here is similar to the causes behind the overcrowding problem; except in this case it isn't just the size of the set that's important, it's also the ordering of masternodes within the queue. The order of the queue determines which masternode will receive a reward next, and any newly proposed block that does not include the correct masternode reward will be rejected by the network. This works as intended the majority of the time but if there's significant disagreement on the queue ordering then this validation requirement can cause uncontrollable forking. A hard fork is a good example of a situation that can lead to disagreement on the queue ordering and the composition of the masternode set.

Solution
The spork system can be utilized to temporarily change consensus rules during especially contentious periods on the network. Spork 8 in the existing spork system (MASTERNODE_PAYMENT_ENFORCEMENT) can be used to disable checks on the masternode payments included in blocks. This would eliminate the issue of uncontrollable forking. The problem is that if an attacker were able to stake many blocks during this period of disabled masternode payment enforcement, they can significantly influence the masternode reward distribution. The distribution is used to deterministically calculate the proof pointer interval so the attacker would be able to manipulate the future behaviour of the network. A couple of different strategies can be employed to mitigate this. One option is to reduce the amount of time the spork is disabled as much as possible so that an attacker wouldn't be able to cause a noticeable change in distribution. If this isn't possible then protocol level solutions need to be implemented. For example, a larger sampling interval would reduce the attacker's impact, but this may produce unwanted externalities under certain conditions. Another approach is to mark newly created blocks and ignore them in future sampling processes.

c) Crown Masternode Proof of Stake Consensus System Overview
The proof of stake consensus system for Crown allows both masternodes and systemnodes to create new blocks and add them to the blockchain. Users do not need to run hot wallets to participate in the staking process.


Staking Process and Terminology
Masternodes and systemnodes are required to have an amount of CRW “locked” (called node collateral) from use in order to be considered an active node and receive node rewards. In a traditional proof of stake consensus system a stake holder would consume their stake input (coins/UTXO) and be issued fresh coins that include the staking reward plus the value of the stake input that was consumed. Since being an active masternode or systemnode requires that node to keep their collateral untouched, this model is modified for Crown’s system.

Stake Pointers
Crown’s consensus system uses a new concept called stake pointers. A stake pointer can be thought of as a stakeable token that is given to masternodes and systemnodes, and is the input that is consumed by the proof of stake transaction. Stake pointers are “given” to masternodes and systemnodes when they receive masternode and systemnode rewards. Stake pointers are time sensitive (expire 2 days after being issued) and are what are used to determine whether a masternode or systemnode is at least "recently active". Since the list of active masternodes and systemnodes is not deterministic (not stored on the blockchain and is based on each peer’s interpretation of which have been validated) it means that simply checking if a node is considered active is something that could lead to unintentional forks because of disagreements from peers over which node may or may not be considered active. By using the stake pointer system, a peer is able to determine that the staking node was at least active within a recent period of time.

Stake pointers can only be used once. When a node stakes a block with their stake pointer, the pointer is marked as used, and the node will not be able to use that pointer again. If the node has multiple stake pointers, it will still be able to stake any of the unused pointers before they expire.

At the most technical level, a stake pointer is simply the transaction hash and the output position that a masternode or systemnode was paid their rewards in.

Stake Selection
Like traditional proof systems such as proof of work and most implementations of proof of stake, Crown uses a target difficulty for each block and the proof hash must be below the target value. A proof hash is done by hashing together the following inputs:

Stakepointer Hash: The transaction hash that the node reward was paid.
Stakepointer Output Index: The position in the vout vector that the reward was paid.
Stake Modifier: The block hash that is 100 blocks before the stakepointer.
Timestamp of Stakepointer: The time that the stakepointer was created.
Timestamp of the New Stake: The time that the new stake was created.

Proof Hash Generation
By hashing the above inputs, a 256 bit proof hash is created. The value of the proof hash is then compared to the difficulty target value multiplied by the value of collateral that the node is holding (10,000 for masternode, 500 for systemnode). If the proof hash is less than the new target, then the stake is considered valid and can be used to package a block and add it to the blockchain. By multiplying the target value by the collateral amount, this means that the target is easier to hit for masternodes than it is for systemnodes.

Finding a Valid Proof Hash (Stake Mining)
Every input that is in the proof hash, except for the timestamp of the new stake, is constant for a given stake pointer. What this means is that if someone had two different computers with identical wallets and stakepointers, it would give no advantage to their ability to find a valid proof hash because they would produce the exact same hashes. Given the same set of inputs and using the same timestamp for the stake that is being created, the proof hash will always come out the same. What this means is that each stakepointer can simply create a new proof hash for every second that passes, and see if it is less than the difficulty target. If the proof hash is less than the target, the stake is packaged into a block and the node has successfully staked. If the proof hash is more than the target, the node waits another second and then tries creating a new proof hash. This process is continually repeated while a node has valid stake pointers.


Bonus : https://www.youtube.com/watch?v=DNyKDI9pn0Q



So evolved that the resources are very important (too much) that it is not allowed to run a SYS and an MN together...  It is really a pity this limited vision. I now understand all this frustration that I've read before on CROWN and its ghost community.

Have Good delisting, dudes.

you probably do not understand how the Crown community works. Ideas, visions, words coming from anybody are nice, but we work in a way that if you want something - get it done, make it happen, dont talk about it, words are empty - actions are what matters!. In Crown nobody will do it for you, there is no CEO, no team, just the code kept by contributors and the DAO

good luck to you in finding the right project dude, I think you will need it

.. 
▄▄█▀▀▀▀▀▀▀█▄▄
▄█▀▀▀           ▀▀▀█▄
▄█▀▀                   ▀▀█▄
▄█▀                         ▀█▄
█▀                             ▀█
█▀               █               ▀█
█▀              ▄█▀                ▀█
      █▄▄▄  ▄▄█▀   ▀█▄▄  ▄▄▄█      █
       █▄▀▀▀▀         ▀▀▀▀▄█       █
        ▀█               █▀        █
█▄
        ▀█   ▄▄█▀▀█▄▄  █▀        ▄█
█▄
         ▀          ▀▀         ▄█
█▄                             ▄█
▀█▄                         ▄█▀
▀█▄▄
                   ▄▄█▀
▀█▄▄▄           ▄▄▄█▀
▀▀█▄▄▄▄▄▄▄█▀▀
  CROWN█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
  MERGE MINING            THRONES            CORE UPDATES
█████████████████████████████████████████   twitter  ██████████████████████ slack  ██████████████████████ ANN Thread  █████████████████████████████████████████
█▄
███
███
███
 ▀█
▀▄
▄ ▀
 ▀▄

█▄
███
███
███
 ▀█
Mountain_Crew
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
July 10, 2019, 11:27:09 PM
 #5034


https://medium.com/crownplatform/development-update-july-2019-52410ddf09df

Development update July 2019

Slow is smooth. Smooth is fast.

Another month has flown by; it’ll be Christmas before you know it! In that time there have been some notable achievements on the Crown development fronts.

NFTs
Artem released technical documentation on the NFT framework on 20 June and v0.13.9 in testnet the next day. This is alpha software designed to foster collaborative development. There is enough functionality for developers to start developing applications and to identify problems, friction points and desirable changes or enhancements. Artem already has a list of next steps including NFT registration and trading but has spent most of the last couple of weeks working on the sandbox environment and a database corruption problem.

Crown contributor Andy D (defunctec) is working on a simple NFT generator addition to the https://crwwallet.net/ site to facilitate end-user experimentation. It will probably be available within the next few days and will allow less-technical users to create and experiment with NFTs without having to venture too close to a command line.

If you’d like to be more directly involved in testing and need any help getting started, please contact us in Discord.

Codebase update
Ashot has been ploughing through the thousands of commits which differentiate Bitcoin from Crown and carefully merging the two codebases together. He has also been working on the build environment. He has compiled all of the Bitcoin v0.17 depends but the main code compile is currently failing with Boost errors. This is very much a marathon rather than a sprint and it will be many more months before it is complete.

Most altcoins forked from Dash or PIVX or Bitcoin are forked from very old versions and very few are still under active development. Crown is here for the long term and we recognise the need to plan for the future by upgrading the existing codebase to something much more modern. This will bring security, speed and stability improvements, and allow for easier maintenance in the future.

Trezor
We are still waiting for Satoshi Labs to release the next Trezor wallet firmware upgrade. They don’t have a published timetable for doing so, but based on past update frequency we think it could well happen this month.

Additional development
We currently have only two full-time developers, but we have more development ideas than they can possibly achieve (in a reasonable timescale) on their own. We had a conference call today with Tom (press tab), the external developer of our class-leading MNPoS staking system regarding improvements to the Crown decentralised governance system. A couple of the key changes we would like to implement are on-chain voting and systemnode voting.

The current governance system is based on the early Dash governance system and is a fragile and temperamental beast. Our developers have already spent a lot of time working on stabilising and improving it. Much of the groundwork for on-chain voting has already been done, but was set aside in favour of higher priority work. We think that groundwork could be adapted to use the NFT framework to provide on-chain voting and systemnode voting at the same time.

Tom has agreed to review the not-yet activated code changes with a view to submitting a proposal for superblock payment to gradually build out the new functionality we would like to have, starting with on-chain and systemnode voting. Before even seeing the code he was able to give us (very rough) guestimates for the development effort/time required for several Crown platform enhancements.

Hopefully, following the review, he will be able to leverage the existing work done by Volodymyr and Artem and submit a proposal for 5k CRW per superblock, to be matched by community contributions. At this level of funding, and with the current CRW/BTC price, an 8-point estimate task could be paid for in about 2–3 months.

This level of funding is a drop in the ocean for many newer, ICO-funded, all fluff and no substance projects. It represents a much more significant commitment for an older, honest, hard-working project like Crown. We will be counting on the continued support of the Crown whales to make these platform enhancements possible.

There is a chance the first proposal will be ready in time for the next superblock (block 2462400, expected around 18th July 2019).
Would you like to know more?

There are bi-weekly development update calls which all community members are welcome to participate in. Details are available in the #development contributor channel in Discord.

Questions, comments and suggestions are always welcome. Crown is a community project and the more engagement we have, the stronger our kingdom is.





Binance listing is planned?
TropicalDog
Member
**
Offline Offline

Activity: 301
Merit: 12

Security and Privacy Features on the Blockchain


View Profile
July 11, 2019, 08:52:50 AM
 #5035

I did not see or hear announcement from CROWN team about potential listing on Binance, so I wait for answer of the team too. I simply think that if the Crown coin can be listed on Binance, it will create big effects on CROWN on exchanges. Days ago, Dogecoin rose more than 40 percent after listed on Binance. Just within a few minutes after been actively trading on Binance, it rose from 27 satoshis to above 40 satoshis. That's cool instant effects.

▄██▄▀█ ▐        PRIVIX        ▌    DISCORD  ●  TWITTER  ●  TELEGRAM  ●  LITEPAPER    ▌ █▀▄██▄
▄▄▄▄▄▄▄▄           Become part of a decentralized virtual private network           ▄▄▄▄▄▄▄▄
▄▄▄ ▄▄▄ ▄▄      based on masternodes and start earning money today      ▄▄ ▄▄▄ ▄▄▄
Stabycroc
Member
**
Offline Offline

Activity: 358
Merit: 24


View Profile
July 13, 2019, 06:01:48 AM
 #5036

"In Crown nobody will do it for you, there is no CEO, no team, just the code kept by contributors and the DAO"

Hmm so who does the superblocks go to  Roll Eyes Roll Eyes Cheesy
lil mis do lil, clearly not trained in legal/moral matters within crypto. like talking to old new holders or people looking to invest.

Its clear to any old guards ur just slowly bleeding crw price down threw Mn ponzi. ( from crw price 90k sat to 700sat clap clap )
Most devs try to make specs to make a coin grow in statue and price, not the other way around. 

devs dont even show total amount premined ( superblocks ) and total amounts for proposals paid out.
u know why there not showing it? work it out, its not rocket science  Cool

there alot of BLAH BLAH BLAH Superblock Blah BLah blah fake mn proposal snatch's and thats about it...

no real innovation or trying to limit supply to inc price/holders just copy/paste from other devs and real bad customer/holder relations.
semsyor
Member
**
Offline Offline

Activity: 363
Merit: 11

Invech


View Profile
July 14, 2019, 05:07:32 PM
 #5037

The Crown Platform Chronicles — PART II: Years 2016 and 2017 — The rise of the Star

The second part of the chronicles looks back in time to two decisive years in Crown history: implementation of Masternodes model in 2016 and strong community growth after the listing to Bittrex in early 2017. https://medium.com/crownplatform/the-crown-platform-chronicles-part-ii-years-2016-and-2017-the-rise-of-the-star-3f7fabb67f34

▁▁▁▁▁                 SECURE AND LICENSED CRYPTOCURRENCY EXCHANGE                 ▁▁▁▁▁
INVECH     WHITEPAPER | ANN THREAD | FACEBOOK | TWITTER | TELEGRAM | MEDIUM     INVECH
▔▔▔▔▔                   JOIN INVECH INITIAL EXCHANGE OFFERING NOW!                   ▔▔▔▔▔
Pages: « 1 ... 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 [252]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!