[UNOFFICIAL] [VNL] Vanillacoin 0.4.1 | Instant ▱ Incentivized ▱ Innovative

[CryptoClub]

Is there some code review planned for this coin ? It's probably pure genius but having official opinions from trusted crypto experts would be a must  

how 0 confirmation can be safely achieved ?
level of anonimity ?
etc...

most people can't understand how vnl works (me) and we need techy voices to explain it i think  

from memory there was a bitcoin core dev doing a review. You might have to get in contact with CryptoClub for more info.

Not sure if I mentioned it here, but a Bitcoin dev I know is doing a code review for Vanillacoin. Funny thing, he was commenting in my group about some other coin he didn't approve of code-wise, and I explained I can't really do code reviews and I just go on the fundamentals. Anyway, he want's to help out the crypto scene and is working on the code review for Vanillacoin. Super technical and it will be a paper, but what I know so far is it definitely isn't a scam based on sheer amount of work, and he agrees it "shines" compared to most alts. He had some pros and cons, and I tried to explain it was still in progress and being worked on. Anyway, it was good enough news that I bought more.

When it is done I will publish on my website cryptocollectorsclub.com, and in the group link at the bottom of my sig. I asked him to do SDC next just as I have always been curious how good or bad the code is on that as well.

I was excited about it but then it seems I should have just kept it to myself rather than sharing as soon as I had info. Main point is the dev and I both are 100% sure the work is way too in depth to be anything other than legit, and that was really why I asked him to look at it in the first place. If he ever actually gets it done I will certainly share it however.

[1714786730]

1714786730

[1714786730]

1714786730

[MemoryShock]

I was excited about it but then it seems I should have just kept it to myself rather than sharing as soon as I had info. Main point is the dev and I both are 100% sure the work is way too in depth to be anything other than legit, and that was really why I asked him to look at it in the first place. If he ever actually gets it done I will certainly share it however.

I saw it as hyping, myself, and agree that things like that need to be communicated after the fact and not as implied promises.  Not that I blame you for being excited...

That said, an implicit approval of the code is apparent in the fact that Poloniex lowered the number of confirmations.  Considering their move to legitimize their exchange by offering margins and registering with relevant entities, then I think that code review is substantial - they aren't just whimsical with their movements. 

[Belligerent Fool]

VanillaCoin Android wallet is so awesome

[MrSpace]

VanillaCoin Android wallet is so awesome

+1

I like how it uses hardly any of my phones CPU usage, if any, while staking.

[dedmaroz]

i have some ZTEX FPGA with Spartan 6. Can i mine with this board: http://www.ztex.de/usb-fpga-1/usb-fpga-1.15y.e.html

[MemoryShock]

i have some ZTEX FPGA with Spartan 6. Can i mine with this board: http://www.ztex.de/usb-fpga-1/usb-fpga-1.15y.e.html

I think that you would get a faster answer on IRC but with my understanding that should work (though I don't FPGA is ready for prime time just yet). 

[YarkoL]

I'm still perplexed over the 0/1-confirmation thing. The most
elaborate technical exposition of it that I've seen is this irc snippet:

May 07 07:24:05 <john-connor>   You cannot double spend with 1 confirmation. You almost cannot with zero as it stands.
May 07 07:24:09 <Mazznilla>     well next step is 0 conf lol
May 07 07:24:39 <gaagaa>        you can double spend with 10 confirms if things are not setup correct
May 07 07:25:04 <john-connor>   Not with VNL you can't.
May 07 07:25:15 <john-connor>   You’d have to own about 99% of the network.
May 07 07:25:35 <john-connor>   Even then you couldn’t do it because of the work required.
May 07 07:26:18 *       kondiomir (5b8635a1@gateway/web/cgi-irc/kiwiirc.com/ip.91.134.53.161) has joined
May 07 07:26:30 <john-connor>   Bitcoin is easy because the mempool sucks.
May 07 07:26:40 <john-connor>   It’s so not synchronized.
May 07 07:27:09 <john-connor>   So you can put TxA-B on mempools A, B and C and TxA-C on mempools D, E and F
May 07 07:27:16 <john-connor>   Success!
May 07 07:27:28 <john-connor>   With vanilla all is known which is instant failure for attacker.

But it seems to me that in the double-spend attack the contents
of mempool do not matter, only the transactions in the longest chain.

So attacker could prepare a private chain with a double spending transaction
and if she has enough hashing power, she can replace the "honest" chain
with the double-spending one.

In Meni Rosenfeld's statistical analysis of the double-spending attack
it is stated that (emphasis mine)

There is nothing special about the default, often-cited figure of 6 confirmations. It was
chosen based on the assumption that an attacker is unlikely to amass more than 10%
of the hashrate, and that a negligible risk of less than 0.1% is acceptable. Both these
figures are arbitrary, however; 6 confirmations are overkill for casual attackers, and at
the same time powerless against more dedicated attackers with much more than 10%
hashrate.

In other words, the number of required confirmations is an estimate based on the probability
of someone owning a certain percentage of hashrate, and this applies as far as I can see to all
proof-of-work coins.

According to Rosenfeld's analysis, presupposing only constant total network hashrate and
constant difficulty, the probability of attacker succeeding with 10% of hashrate is 20% after
single confirmation.

John-connor says above you'd need "about 99%" of hashing-power, but even if everyone
gets to see transactions at the same time, it is the transactions that are in blocks that do matter,
not those in temporary memory, and blocks in the longest chain matter the most. So far I have
failed to understand where that figure comes from.

[monsterer]

I'm also interested in hearing more about the 1 confirmation theory, and indeed about the POS consensus - the white paper was less than informative.

[MemoryShock]

I have posted an update regarding the UDP (Consensus, Storage and Routing) Layer: https://talk.vanillacoin.net/topic/3/udp-consensus-storage-and-routing-layer/4

Thank you for your support.

https://bitcointalk.org/index.php?topic=1064326.msg11578416#msg11578416

[john-connor]

I'm still perplexed over the 0/1-confirmation thing. The most
elaborate technical exposition of it that I've seen is this irc snippet:

May 07 07:24:05 <john-connor>   You cannot double spend with 1 confirmation. You almost cannot with zero as it stands.
May 07 07:24:09 <Mazznilla>     well next step is 0 conf lol
May 07 07:24:39 <gaagaa>        you can double spend with 10 confirms if things are not setup correct
May 07 07:25:04 <john-connor>   Not with VNL you can't.
May 07 07:25:15 <john-connor>   You’d have to own about 99% of the network.
May 07 07:25:35 <john-connor>   Even then you couldn’t do it because of the work required.
May 07 07:26:18 *       kondiomir (5b8635a1@gateway/web/cgi-irc/kiwiirc.com/ip.91.134.53.161) has joined
May 07 07:26:30 <john-connor>   Bitcoin is easy because the mempool sucks.
May 07 07:26:40 <john-connor>   It’s so not synchronized.
May 07 07:27:09 <john-connor>   So you can put TxA-B on mempools A, B and C and TxA-C on mempools D, E and F
May 07 07:27:16 <john-connor>   Success!
May 07 07:27:28 <john-connor>   With vanilla all is known which is instant failure for attacker.

But it seems to me that in the double-spend attack the contents
of mempool do not matter, only the transactions in the longest chain.

So attacker could prepare a private chain with a double spending transaction
and if she has enough hashing power, she can replace the "honest" chain
with the double-spending one.

In Meni Rosenfeld's statistical analysis of the double-spending attack
it is stated that (emphasis mine)

There is nothing special about the default, often-cited figure of 6 confirmations. It was
chosen based on the assumption that an attacker is unlikely to amass more than 10%
of the hashrate, and that a negligible risk of less than 0.1% is acceptable. Both these
figures are arbitrary, however; 6 confirmations are overkill for casual attackers, and at
the same time powerless against more dedicated attackers with much more than 10%
hashrate.

In other words, the number of required confirmations is an estimate based on the probability
of someone owning a certain percentage of hashrate, and this applies as far as I can see to all
proof-of-work coins.

According to Rosenfeld's analysis, presupposing only constant total network hashrate and
constant difficulty, the probability of attacker succeeding with 10% of hashrate is 20% after
single confirmation.

John-connor says above you'd need "about 99%" of hashing-power, but even if everyone
gets to see transactions at the same time, it is the transactions that are in blocks that do matter,
not those in temporary memory, and blocks in the longest chain matter the most. So far I have
failed to understand where that figure comes from.

If you disable a single line of code in the Bitcoin mempool source code the entire system would allow double-spends for all "off chain" transactions. This includes merchants, exchanges, dice games, etc. I assume by your quote however you are talking about "on chain" transactions instead which is a problem for Proof-of-Work crypto-currencies because an attacker can force a reorganization containing his "evil" transactions in his "longer chain" of blocks. That said, the mempool is what protects the network while blocks are waiting to be solved. If the global mempool is synchronised to a degree of ~99% then you must own ~99% of the network to cause a double-spend.

FYI, I rarely check this thread, the official thread is here: https://bitcointalk.org/index.php?topic=1064326.0

Thank you for your support.

[YarkoL]

If you disable a single line of code in the Bitcoin mempool source code the entire system would allow double-spends for all "off chain" transactions. This includes merchants, exchanges, dice games, etc. I assume by your quote however you are talking about "on chain" transactions instead which is a problem for Proof-of-Work crypto-currencies because an attacker can force a reorganization containing his "evil" transactions in his "longer chain" of blocks. That said, the mempool is what protects the network while blocks are waiting to be solved. If the global mempool is synchronised to a degree of ~99% then you must own ~99% of the network to cause a double-spend.

Sure, improving the sync of mempools across the network will reduce
the likelihood of fork occurring due to near-simultaneous transmission of
conflicting transactions , but to be clear, I was talking about the type of hashrate attack that is
discussed in Meni Rosenfeld's paper and in the Bitcoin whitepaper,
known rather misleadingly as majority attack.

The rationale that determines the number of confirmations that is deemed
safe is based on Satoshi calculating (p. 8 in the whitepaper)
that if attacker controls 10% of the total hashrate , five blocks (confirmations)
on top of the original transaction pushes down the odds of attacker succeeding
in building a longer chain (and reversing the original transaction) below 0.1%

This issue is especially relevant to altcoins with relatively modest network
hashrate. Attacks of this kind are very expensive, and arguably unlikely to
happen, but you can never tell...

FYI, I rarely check this thread, the official thread is here: https://bitcointalk.org/index.php?topic=1064326.0

I know, but there's more life here  

[john-connor]

If you disable a single line of code in the Bitcoin mempool source code the entire system would allow double-spends for all "off chain" transactions. This includes merchants, exchanges, dice games, etc. I assume by your quote however you are talking about "on chain" transactions instead which is a problem for Proof-of-Work crypto-currencies because an attacker can force a reorganization containing his "evil" transactions in his "longer chain" of blocks. That said, the mempool is what protects the network while blocks are waiting to be solved. If the global mempool is synchronised to a degree of ~99% then you must own ~99% of the network to cause a double-spend.

Sure, improving the sync of mempools across the network will reduce
the likelihood of fork occurring due to near-simultaneous transmission of
conflicting transactions , but to be clear, I was talking about the type of hashrate attack that is
discussed in Meni Rosenfeld's paper and in the Bitcoin whitepaper,
known rather misleadingly as majority attack.

The rationale that determines the number of confirmations that is deemed
safe is based on Satoshi calculating (p. 8 in the whitepaper)
that if attacker controls 10% of the total hashrate , five blocks (confirmations)
on top of the original transaction pushes down the odds of attacker succeeding
in building a longer chain (and reversing the original transaction) below 0.1%

This issue is especially relevant to altcoins with relatively modest network
hashrate. Attacks of this kind are very expensive, and arguably unlikely to
happen, but you can never tell...

FYI, I rarely check this thread, the official thread is here: https://bitcointalk.org/index.php?topic=1064326.0

I know, but there's more life here  

That rationale didn't take into consideration Proof-of-Stake blocks and only applies to a very specific scenario. Hashrate in regards to Vanillacoin can never consume as much as 33% of the entire blocks generated. Therefore the attacker is left in an impossible situation unless they also have 76% of all coins in circulation but then they would have to be able to produce stake blocks at will which is not possible due to the random nature of their generation. The higher the global mempool synchronization the more impossible this scenario becomes. The improved global mempool in Vanillacoin is the key to better protection of transactions which will reach ~99% synchronization with the deployment of the UDP based database making zero confirmations possible at zero-risk through autonomous consensus of the global transaction pool's state.

Thank you for your support.

[monsterer]

If the global mempool is synchronised to a degree of ~99% then you must own ~99% of the network to cause a double-spend.

That is just not the case. You only need to control enough hash power to produce a block to cause a double spend. If you want that double spend to persist, you need to produce the next subsequent block and so on. This is nowhere near 99%.

[bitspill]

If the global mempool is synchronised to a degree of ~99% then you must own ~99% of the network to cause a double-spend.

That is just not the case. You only need to control enough hash power to produce a block to cause a double spend. If you want that double spend to persist, you need to produce the next subsequent block and so on. This is nowhere near 99%.

I think the way john is implementing it is such that the offending block will never be mined because the original transaction in the mempool will cause that block to be rejected

[etoque]

hey here... what the roadmap.. what coming ? sell me your project   Chart are nice .

thanks

[monsterer]

I think the way john is implementing it is such that the offending block will never be mined because the original transaction in the mempool will cause that block to be rejected

Transactions leave the mempool once they get mined.

[liulby]

It's good news to list bittrex.com
https://www.bittrex.com/Market/Index?MarketName=BTC-VNL

[etoque]

there's a stake calculator ? How much time to stake ?

[Levole11]

there's a stake calculator ? How much time to stake ?

There's not a specific time I believe, it can take a few days, but it'll stake, dont worry

[john-connor]

I think the way john is implementing it is such that the offending block will never be mined because the original transaction in the mempool will cause that block to be rejected

Transactions leave the mempool once they get mined.

Transactions can stay in the global transaction pool for up to 72 hours before being completely removed. Even if it were to be removed both the sender and recipient rebroadcast it every 120 seconds until it is satisfied. Obviously since the subject block is conflicting with the global transaction pool it is rejected by all recipients. No amount of hash-power can obtain more than 1/3 of the consensus by design so the hash argument is moot here. The source code is freely available for inspection. Bitcoin doesn't to my knowledge do any of this extra protection.

Thank you for your support.