First they spread fud, but now bitcoin core will copy Vcash code

[EmilioMann]

After GMaxwell spread fud against Vcash now blockstream will copy the Vcash adaptive block size! #SHAME

"Blockstream’s Johnny Dilley: We’ll Eventually Have an Adaptive Block Size Solution" 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


The truth about GMaxwell's fud against John Connor and Vcash""

[1714022644]

1714022644

[1714022644]

1714022644

[1714022644]

1714022644

[GTO911]

Lol Vcash guys

Lol John Connor

 

[EmilioMann]

Lol Vcash guys

Lol John Connor

 

Hey monero guy, how is the monero's blockchain bloat? Lol
How much time of life your coin still has?
Take a look at vcash's anon system. Fast, secure, decentralized and without masternodes.
 

https://www.youtube.com/watch?v=DfAab-bNoqY

[r0ach]

I would have to say it's kind of disingenuous to say that gmaxwell = bitcoincore.  It should really be called Wladimir & Pieter Wuille Coin, but Americans aren't very fond of strange Euro words (even worse when they put in umlauts or other ridiculous things), which explains why the name hasn't been changed yet.

[john-connor]

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

[r0ach]

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.

[bigfryguy]

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.

[BitcoinNational]

Well definitely a character.
The product is nice too.

[john-connor]

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. 

[redjedievolution]

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. 

[jimlite]

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.

[JamesOng]

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!

[generalizethis]

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.

[EmilioMann]

 



https://bitcointalk.org/index.php?topic=1442193.msg14668144#msg14668144

[SockPuppetAccount]

https://bitcointalk.org/index.php?topic=1442193.msg14668144#msg14668144

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.

[noobtrader]

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.   

[doremi]

https://bitcointalk.org/index.php?topic=1442193.msg14668144#msg14668144

 They aren't sitting on the sidelines because BTC isn't fast enough or truly anonymous. 

that's why we need Vcash

[I am the guy]

Speaking of Vcash code here's the Adaptive Block Size Algorithm video: https://www.youtube.com/watch?v=KxzxbNAvUZY
enjoy 

[Levole11]

Here's a vid of Zeroledger Chain synchronisation:


https://www.youtube.com/watch?v=adOv34vbl2w

[Dekker3D]

This surely is something for VCash. With regards to Zero confirmations creating fast transaction, aren't other altcoins having an instant transfer as well.