ZeroLedger Chain Synchronisation and Transaction Confirmation's Video:
https://www.youtube.com/watch?v=IS51MXxQMZQ
And now Bitcoin's Blockstream Lightning Network requires Vcash SuperNode technology to function:
https://bitcoinmagazine.com/articles/exploring-the-centralization-risks-of-bitcoin-s-lightning-network-1462460852
Topic: First they spread fud, but now bitcoin core will copy Vcash code - page 5. (Read 9957 times)
Vcash is officially in Microsoft Azure
https://azure.microsoft.com/en-us/blog/azure-blockchain-update-8/
https://azure.microsoft.com/en-us/blog/azure-blockchain-update-8/
Glad it's official now. Thanks for the update.
Vcash is officially in Microsoft Azure
https://azure.microsoft.com/en-us/blog/azure-blockchain-update-8/
https://azure.microsoft.com/en-us/blog/azure-blockchain-update-8/
The only one iam aware of is Dash, but that requires a higher fee to use, while xvc's is the standard fee and through xvc's ZT txes, coins are respendable faster..
There might be other differences as well, but i have never really looked into Dash, there may be other differences as well..
Yeah I remember Dash demoed a vending machine showcasing the fast transaction. I guess VCash can also try to put it in demo
This surely is something for VCash. With regards to Zero confirmations creating fast transaction, aren't other altcoins having an instant transfer as well.
The only one iam aware of is Dash, but that requires a higher fee to use, while xvc's is the standard fee and through xvc's ZT txes, coins are respendable faster..
There might be other differences as well, but i have never really looked into Dash, there may be other differences as well..
Yeah I remember Dash demoed a vending machine showcasing the fast transaction. I guess VCash can also try to put it in demo
This surely is something for VCash. With regards to Zero confirmations creating fast transaction, aren't other altcoins having an instant transfer as well.
The only one iam aware of is Dash, but that requires a higher fee to use, while xvc's is the standard fee and through xvc's ZT txes, coins are respendable faster..
There might be other differences as well, but i have never really looked into Dash to be honest.
This surely is something for VCash. With regards to Zero confirmations creating fast transaction, aren't other altcoins having an instant transfer as well.
April 28, 2016, 05:52:34 PM
Speaking of Vcash code here's the Adaptive Block Size Algorithm video: https://www.youtube.com/watch?v=KxzxbNAvUZY
enjoy
enjoy
April 28, 2016, 01:14:33 PM
They aren't sitting on the sidelines because BTC isn't fast enough or truly anonymous.
that's why we need Vcash
April 27, 2016, 12:18:35 PM
The Monero coin already has the block size adaption. In fact, all the cryptnote coins have that feature. It is good for the bitcoin to adopt that.
pic
Monero team are bully, they cant code so they try to stay relevant by fudding other crypto project.
April 27, 2016, 06:15:09 AM
Not here to shit on Vcash or john-connor. I have no strong opinion on the coin and the man is clearly a very talented programmer. I just had to point out the absurdity of the statement "The ZeroLedger technology is alone worth a billion IMHO".
BTC and Vcash are competing digital currencies, not competing consumer goods. Currency and consumer goods do not derive their values from the same sources. A crypto-currency derives its value mainly from adoption, but john-connor speaks of ZeroLedger as if he is the Samsumg CEO speculating on the worth of their latest advancements in bendable touchscreens.
BTC is light-years ahead of everything else when it comes to current adoption, and this fact is further compounded by the effect of adoption begetting adoption. I can hear fanboys screaming, "technological advancements will drive adoption!". If you believe this, you live in a fantasy land that exists only in your dreams. In the real world, the majority of the population has absolutely zero interest in buying, owning, using, accepting, or investing in crypto-currency and never will. They want to swipe their Visa card and go about their day. They aren't sitting on the sidelines because BTC isn't fast enough or truly anonymous. john-connor goes on to state that zero confirmation will make crypto-currencies useful "in real time situations", which is utterly irrelevant because I have yet to see a compelling use case or demand of any significance for crypto-currency "in real time situations".
Visa, Mastercard, Paypal, and the legacy banking system are not frightened of BTC and blockchain technology. They will be watching the world of crypto-currencies and continually stealing the good parts from it to improve efficiency, lower costs, and improve their service. In the same way, BTC is not scared of altcoins. BTC will continually take advances pioneered by altcoins for itself, as this very thread vividly illustrates.
There are other use cases for blockchain technology besides as currency, and it remains to be seen whether currency is the so-called "killer app" of blockchain technology, but trying to compete with BTC when it comes to use as a currency is a fool's errand. BTC has already won, deal with it.
April 27, 2016, 01:04:56 AM
April 20, 2016, 01:45:32 AM
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.
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. 
Your work is great as always John. But there is a fine line between confident and cocky. I am glad you walk it though.
I believe Ghandi said it best:
First they ignore you,
then they laugh at you,
then they fight you,
then you win.
Dude, I'm not getting involved in the argument, but that Ghandi quotation only works when you apply it to civil disobedience, when you apply it to fights you not only started, but have continually maintained, and are more about market share than fighting an oppressive regime that is attempting to hold you down, it becomes a little absurd. If you had to fight to buy vanilla cash and that was an act that was actively attacked by some authority, then that quotation would be apt.
April 20, 2016, 01:31:40 AM
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.
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. Bravo!
April 19, 2016, 06:28:53 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.
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. Your work is great as always John. But there is a fine line between confident and cocky. I am glad you walk it though.
I believe Ghandi said it best:
First they ignore you,
then they laugh at you,
then they fight you,
then you win.
April 19, 2016, 05:29:15 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.
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. 
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.
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. 
Well definitely a character.
The product is nice too.
The product is nice too.
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 seems to love testing the waters on new developments, while being skilled enough to quickly implement them, and also quick enough to keep an eye on any changes needed to keep the working or to remove them if problems arise. we will see if his work pays off in the future.
Jump to: