[XVC] Vcash (former [VNL] Vanillacoin) cryptocurrency unmoderated discussion

[smooth]

I'll start with this deleted post that was removed by one of their scam promoters claiming that Bitcoin is going "copy Vcash" by adding an adaptive blocksize. I pointed out that Monero (and previously Bytecoin) had such an adaptive blocksize almost a year before Vcash launched.

A reply of yours, quoted below, was deleted by the starter of a self-moderated topic. There are no rules of self-moderation, so this deletion cannot be appealed. Do not continue posting in this topic if the topic-starter has requested that you leave.

You can create a new topic if you are unsatisfied with this one. If the topic-starter is scamming, post about it in Scam Accusations.

Hey monero guy, how is the monero's blockchain bloat? Lol

Its adaptive blocksize that was launched in early 2014 is doing fine, thank you for asking.

Enjoy this open, neutral forum for discussion of Vcash/Vanillacoin as my gift to you.

Other resources from community members below. No endorsement implied.

Vcash


Welcome to the official community topic of Vcash. This topic is moderated by the Vcash community members.

Vcash is a cryptographic currency that is not a clone of any other project. It is designed to be innovative and forward-thinking. It prevents eavesdropping and censorship, promotes decentralized, energy efficient and fast network transactions by use of irrevocable contracts and provides opt-in client-side anonymity. It has no pre-mine, pre-sale, IPO, ICO or BS.

Specifications:

30.7 million coins.
Variable block time targeting 80-200 seconds.
128 coins per block initially.
Difficulty is retargeted every block.
Blake-256 Proof-of-Work algorithm.
0.7% interest rate by use of energy efficient Proof-of-Stake.
0.0005 coin per kilobyte transaction fee.

Whitepaper:

http://v.cash/papers/vanillacoin.pdf

Wallets:

http://v.cash/wallets.php

Exchanges:

Bittrex: https://www.bittrex.com/Market/Index?MarketName=BTC-XVC
Poloniex: https://poloniex.com/exchange#btc_xvc
RAWX: https://beta.rawx.io/#/markets/BTC:XVC

Projects:

https://github.com/john-connor/

Proof-of-Work Mining/Coin Distribution

http://pool.v.cash/
http://vcash.miningpoolhub.com/
http://xvc.maxminers.net/
http://xvc.suprnova.cc/

Ledger Explorer:
 
https://explorer.v.cash/
https://www.blockexperts.com/xvc/

Developer Announcements:

Development Team ANN: https://bitcointalk.org/index.php?topic=1064326.0

Social:

Twitter: https://twitter.com/vdotcash
Forum: https://v.cash/forum/
https://v.cash/slack/

Disclaimer: This project is considered "beta" and is in an ever-changing state. This said, it moves rapidly and keeping up with the evolution is not easy. The best channel for up-to-date information is through the "official" forums. Anything posted on BCT or elsewhere regarding changes to this project's current state should not be considered unless also confirmed through the "official" forums.

Thank you for your support




I'll add the official threads info here.  Please add this to the front page smooth.   If you really want this to be an unmoderated announcement page you should at least start it off with the appropriate information.

Just created an unofficial Vcash facebook fan group. Click below to join !!!

https://www.facebook.com/groups/1835848506633458/

[1715123950]

1715123950

[bigfryguy]

Vcash




Vcash is a cryptographic currency that is not a clone of any other project. It is designed to be innovative and forward-thinking. It prevents eavesdropping and censorship, promotes decentralized, energy efficient and fast network transactions by use of irrevocable contracts and provides opt-in client-side anonymity. It has no pre-mine, pre-sale, IPO, ICO or BS.

Specifications:

30.7 million coins.
Variable block time targeting 80-200 seconds.
128 coins per block initially.
Difficulty is retargeted every block.
Blake-256 Proof-of-Work algorithm.
0.7% interest rate by use of energy efficient Proof-of-Stake.
0.0005 coin per kilobyte transaction fee.

Whitepaper:

http://v.cash/papers/vanillacoin.pdf

Wallets:

http://v.cash/wallets.php

Exchanges:

Bittrex: https://www.bittrex.com/Market/Index?MarketName=BTC-XVC
Poloniex: https://poloniex.com/exchange#btc_xvc
RAWX: https://beta.rawx.io/#/markets/BTC:XVC

Projects:

https://github.com/john-connor/

Proof-of-Work Mining/Coin Distribution

http://pool.v.cash/
http://vcash.miningpoolhub.com/
http://xvc.maxminers.net/
http://xvc.suprnova.cc/

Ledger Explorer:
 
https://explorer.v.cash/
https://www.blockexperts.com/xvc/

Developer Announcements:

Development Team ANN: https://bitcointalk.org/index.php?topic=1064326.0

Social:

Twitter: https://twitter.com/vdotcash
Forum: https://v.cash/forum/
https://v.cash/slack/

Disclaimer: This project is considered "beta" and is in an ever-changing state. This said, it moves rapidly and keeping up with the evolution is not easy. The best channel for up-to-date information is through the "official" forums. Anything posted on BCT or elsewhere regarding changes to this project's current state should not be considered unless also confirmed through the "official" forums.

Thank you for your support
thanks smooth!! not sure if you are doing this as a jest or because you woud like an umoderated discussion...  I will try to post updates as they come about.

here is the latest weekly update/release for Vcash

"Mon, 18 Apr 2016 17:39:24 GMT
Support for BIP-0037.
Deployed 0.4.5 RC3 (not sure if I like this, but rewards will halve at block 385k)
Drafted and Integrated RewardV3 Algorithm"
Bug Fixes
 
also RC3 v.5

"has
233 Mb on Win 7 64 bit

..RC2 didn't use more than 300Mb after 3 days or so. RC3 seems to use even a bit less. :cool:
Much better but still room for improvement. One of our engineers rewrote the entire block index structure of the codebase (over 6000 lines) which resulted in 30 MB less overhead and less slow memory growth with each new block. Additionally this resulted in a 300% speedup in the code-base due to the complete lack of object copying, referencing, etc. Hopefully QA will approve and we will deploy it into the next release."

both posts from Vcash forum

hard to call a forum neutral when it is made by an XMR developer, but we will see.

[smooth]

hard to call a forum neutral when it is made by an XMR developer, but we will see.

Since it is not self-moderated I have no more control over it than anybody else (excluding forum mods). The only thing I could do is lock it, which I do not plan to do.

[bigfryguy]

Smooth, how much resources do most nodes of coins need to run in comparison to VCash?

[smooth]

Smooth, how much resources do most nodes of coins need to run in comparison to VCash?

I don't know. Why don't you tell us about how Vcash nodes are different from other coins'  nodes?

[bigfryguy]

Smooth, how much resources do most nodes of coins need to run in comparison to VCash?

I don't know. Why don't you tell us about how Vcash nodes are different from other coins'  nodes?

you are the OP why dont you tell me.

[TPTB_need_war]

The brilliant, anonymous, plagiarist Vcash lead developer:

How does Monero propose to resolve the fact that it's blockchain is growing faster than Moores Law and pruning is so limited?

Human populations don't grow faster than Moore's law. Duh.

Disk arrays scale to anything we can fathom.

The issue is that no block chain consensus can maintain decentralization of validation, not because of scaling problems but because of the fundamental economic reality that not every miner can have an equal share of the hashrate, thus verification costs are not shared equally. The creates an asymmetry where economies-of-scale will maximize profit and grow hashrate the fastest thus centralizing mining.

The solution requires some clever innovation on proof-of-work.

[EmilioMann]

Here is the thread without smooth's manipulation and lies:


"First they spreading fud, but now bitcoin core will copy Vcash code"
https://bitcointalk.org/index.php?topic=1441929.0

[smooth]

Here is the official thread without smooth's manipulation and lies:


"First they spreading fud, but now bitcoin core will copy Vcash code"
https://bitcointalk.org/index.php?topic=1441929.0

Lies? I posted exactly the message I got from the forum bot when you deleted my post, which was not at all a lie. It was 100% factual.

Good thing is, we don't need to argue about your scammy agenda-driven self-moderation any more, anyone who would like to discuss discuss things can do so here on this nice unmoderated thread. Enjoy!

[Gillette]

Vcash (former VanillaCoin) shut down both unmoderated  threads in Announcement section.

All the treads they open here (Altcoin discussion) are heavily moderated and they delete all critics.

So be very careful with Vcash - former Vanillacoin.

[bitcoin carpenter]

XMR dev creates an unmoderated thread about another coin...

XMR shills pile in to prove how shitty bitcointalk has become..

There are already other unmoderated forums that aren't on bitcointalk, and although I would rather discuss things here, you guys really show me why it has moved.


I mean really doesn't the XMR shill army have enough places for them to wag their tongues by now... 

Oh well that's my rant, from now on I'll just come in to add weekly updates.  Have fun running an XMR thread about XVC.

[ArticMine]

I read Stephen Pair's proposal and it is basically the Cryptonote adaptive blocksize limit in Monero without the penalty function. It relies only on the probability of orphan blocks to set fees. My take is that this will suffer the same fate as a Cryptonote adaptive blocksize limit without a tail emission, such as is the case in Bytecoin. It will fail once the emission runs out, with the hashrate collapsing and the coin becoming insecure  At best one would see the type of cartel that TPTB_need_war  has suggested; however my take is that this kind of cartel would only last for a short time before collapsing. Just witness what is currently happening in the crude oil market.

Edit: https://medium.com/@spair/a-simple-adaptive-block-size-limit-748f7cbcfb75#.muot131pa

[TPTB_need_war]

Regarding the future of Bitcoin and its Tragedy of the Commons economic design:

At best one would see the type of cartel that TPTB_need_war  has suggested; however my take is that this kind of cartel would only last for a short time before collapsing. Just witness what is currently happening in the crude oil market.

Cartels form in power vacuums. They must align with the greater power vacuums in order to sustain their market inefficiency (top-down control can't anneal maximum fitness). So the only way such a cartel would not fail, would be to become a fiat of the world government and be sustained by the Iron Law on Political Economics which is the perennial, inimitable power vacuum.

[bitcoin carpenter]

Quote from: r0ach on April 18, 2016, 08:36:11 PM
Wasn't the Bitpay solution the one where there's no negative incentive for continuously inflating the block size over time?  I haven't really spent any time examining any of the adaptive block size proposals, but it's obviously not as simple as just coding up something that sounds logical if you're unable to identify all the various game theory and attack vectors involved.

John's answer

I've never seen a proposal other than mine that had working code. Fixed block sizes "by design" are attack vectors. You cannot keep growing the block size, this does not work as it is nothing more than a "fixed variable" since it only grows. If transaction's grind to a halt you end up with 100 MB blocks that could be targeted. I've solved the problem in a deterministic way that does not break consensus rules and XVC is moving forward with it so we never have to think about it again.  Shocked
Report to moderator 
John Connor
Vcash Chief Architect
Website - Offical ANN

[TPTB_need_war]

The solution to the block size problem has nothing to do with controlling the size of the blocks. It requires a different design where transaction fees trend near to costs but not to costs, thus not making the nodes of the system bankrupt.

[EmilioMann]

The solution to the block size problem has nothing to do with controlling the size of the blocks.
blah blah blah shit blah blah

"Blockstream’s Johnny Dilley: We’ll Eventually Have an Adaptive Block Size Solution (From Vcash)" https://bitcoinmagazine.com/articles/blockstream-s-johnny-dilley-we-ll-eventually-have-an-adaptive-block-size-solution-1460997499?utm_content=buffer36b7c&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

[ArticMine]

The solution to the block size problem has nothing to do with controlling the size of the blocks. It requires a different design where transaction fees trend near to costs but not to costs, thus not making the nodes of the system bankrupt.

This brings us back to the Cryptonote adaptive blocksize limit combined with a tail emission found in Monero where:
1) The cost of mining a block is set by the block subsidy
2) The total amount in fees per block has to rise to a number comparable to, but most of the time smaller, than the block subsidy.

[smooth]

Quote from: r0ach on April 18, 2016, 08:36:11 PM
Wasn't the Bitpay solution the one where there's no negative incentive for continuously inflating the block size over time?  I haven't really spent any time examining any of the adaptive block size proposals, but it's obviously not as simple as just coding up something that sounds logical if you're unable to identify all the various game theory and attack vectors involved.

John's answer

I've never seen a proposal other than mine that had working code

Monero and prior to that Bytecoin has had working dynamic block size code since early 2014. It has been proven in the wild against three at least spam environments, one due to poorly-written pool code and twice against malicious attacks.

[EmilioMann]

Quote from: r0ach on April 18, 2016, 08:36:11 PM
Wasn't the Bitpay solution the one where there's no negative incentive for continuously inflating the block size over time?  I haven't really spent any time examining any of the adaptive block size proposals, but it's obviously not as simple as just coding up something that sounds logical if you're unable to identify all the various game theory and attack vectors involved.

John's answer

 I've never seen a proposal other than mine that had working code. Fixed block sizes "by design" are attack vectors. You cannot keep growing the block size, this does not work as it is nothing more than a "fixed variable" since it only grows. If transaction's grind to a halt you end up with 100 MB blocks that could be targeted. I've solved the problem in a deterministic way that does not break consensus rules and XVC is moving forward with it so we never have to think about it again.  Shocked
Report to moderator  
John Connor
Vcash Chief Architect
Website - Offical ANN
 

Monero and prior to that Bytecoin has had working dynamic block size code since early 2014. It has been proven in the wild against three at least spam environments, one due to poorly-written pool code and twice against malicious attacks.

every body knows that monero copy&paste bytecoin code.
The proof is right here on bitcointalk, just look at the release date of coins

I'd like to remind people that my algorithm(s) for adaptive block size generation are Bitcoin/Peercoin protocol specific. After a year of reviewing the Cryptonote source code I no longer take any of it's derived projects seriously so it does not pertain. To get back on topic, my simple algorithm adapts to traffic influx while simultaneously preventing "arbitrary block size" DoS attacks, lastly it is highly configurable, adaptive yet simple while scaling to ∞ TPS.

Blockstream has no authority to make this wild claim that Bitcoin will ever have an adaptive block sizing solution because they are no authority figure over Bitcoin. Stephen Pair of BitPay came up with a written solution here: https://medium.com/@spair/a-simple-adaptive-block-size-limit-748f7cbcfb75#.pb5cyk56m using a common sense and simple approach but he only touched on the subject and did not produce any code to prove his theory so while possibly good it doesn't help us today. That said, you have a simple and adaptive solution that can be deployed "today" to any Bitcoin or Peercoin based crypto-currency:

https://gist.github.com/john-connor/c1e131771cfcca02ac9e7a14a4f08caf

Peace and Love

[smooth]

Quote from: r0ach on April 18, 2016, 08:36:11 PM
Wasn't the Bitpay solution the one where there's no negative incentive for continuously inflating the block size over time?  I haven't really spent any time examining any of the adaptive block size proposals, but it's obviously not as simple as just coding up something that sounds logical if you're unable to identify all the various game theory and attack vectors involved.

John's answer

 I've never seen a proposal other than mine that had working code. Fixed block sizes "by design" are attack vectors. You cannot keep growing the block size, this does not work as it is nothing more than a "fixed variable" since it only grows. If transaction's grind to a halt you end up with 100 MB blocks that could be targeted. I've solved the problem in a deterministic way that does not break consensus rules and XVC is moving forward with it so we never have to think about it again.  Shocked
Report to moderator 
John Connor
Vcash Chief Architect
Website - Offical ANN
 

Monero and prior to that Bytecoin has had working dynamic block size code since early 2014. It has been proven in the wild against three at least spam environments, one due to poorly-written pool code and twice against malicious attacks.

every body knows that monero copy&paste bytecoin code.

Whichever you prefer, debating between BCN and XMR is obviously off topic here. Either way the claim that there is no prior working code is wrong.