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.
Topic: [UNOFFICIAL] [VNL] Vanillacoin 0.4.1 | Instant ▱ Incentivized ▱ Innovative - page 220. (Read 433405 times)
June 10, 2015, 05:41:35 AM
Transactions leave the mempool once they get mined.
June 10, 2015, 03:45:25 AM
hey here... what the roadmap.. what coming ? sell me your project 
Chart are nice .
thanks
Chart are nice .thanks
June 10, 2015, 03:30:38 AM
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
June 10, 2015, 03:26:45 AM
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%.
June 10, 2015, 03:09:54 AM
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://bitcointalksearch.org/topic/--1064326
I know, but there's more life here
Thank you for your support.
June 10, 2015, 02:10:50 AM
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://bitcointalksearch.org/topic/--1064326
I know, but there's more life here
June 09, 2015, 10:02:17 PM
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:
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)
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. elaborate technical exposition of it that I've seen is this irc snippet:
Quote
May 07 07:24:05 You cannot double spend with 1 confirmation. You almost cannot with zero as it stands.
May 07 07:24:09 well next step is 0 conf lol
May 07 07:24:39 you can double spend with 10 confirms if things are not setup correct
May 07 07:25:04 Not with VNL you can't.
May 07 07:25:15 You’d have to own about 99% of the network.
May 07 07:25:35 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 Bitcoin is easy because the mempool sucks.
May 07 07:26:40 It’s so not synchronized.
May 07 07:27:09 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 Success!
May 07 07:27:28 With vanilla all is known which is instant failure for attacker.
May 07 07:24:09
May 07 07:24:39
May 07 07:25:04
May 07 07:25:15
May 07 07:25:35
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
May 07 07:26:40
May 07 07:27:09
May 07 07:27:16
May 07 07:27:28
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)
Quote
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.
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.
FYI, I rarely check this thread, the official thread is here: https://bitcointalksearch.org/topic/--1064326
Thank you for your support.
June 09, 2015, 09:22:11 PM
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://bitcointalksearch.org/topic/m.11578416 Thank you for your support.
June 09, 2015, 02:45:22 PM
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.
June 09, 2015, 11:22:44 AM
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:
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)
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.
elaborate technical exposition of it that I've seen is this irc snippet:
Quote
May 07 07:24:05 You cannot double spend with 1 confirmation. You almost cannot with zero as it stands.
May 07 07:24:09 well next step is 0 conf lol
May 07 07:24:39 you can double spend with 10 confirms if things are not setup correct
May 07 07:25:04 Not with VNL you can't.
May 07 07:25:15 You’d have to own about 99% of the network.
May 07 07:25:35 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 Bitcoin is easy because the mempool sucks.
May 07 07:26:40 It’s so not synchronized.
May 07 07:27:09 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 Success!
May 07 07:27:28 With vanilla all is known which is instant failure for attacker.
May 07 07:24:09
May 07 07:24:39
May 07 07:25:04
May 07 07:25:15
May 07 07:25:35
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
May 07 07:26:40
May 07 07:27:09
May 07 07:27:16
May 07 07:27:28
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)
Quote
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.
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.
June 09, 2015, 10:19:54 AM
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).
June 09, 2015, 02:59:21 AM
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
June 09, 2015, 02:33:20 AM
VanillaCoin Android wallet is so awesome
+1
I like how it uses hardly any of my phones CPU usage, if any, while staking.
June 09, 2015, 02:32:54 AM
VanillaCoin Android wallet is so awesome
June 08, 2015, 06:53:17 PM
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.
June 08, 2015, 06:23:16 PM
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
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.
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.
June 08, 2015, 04:33:18 PM
I feel the first post is confusing, inaccurate and not inline with the Vanillacoin project, therefore I have started an official topic here instead: https://bitcointalksearch.org/topic/--1064326
Not to mention that this thread is unmoderated
We already talked about this earlier in the thread. I fully respect John's decision and he let this thread live on after we discussed it.
June 08, 2015, 04:09:59 PM
John posted this on the official thread:
I have posted an update regarding Proof-of-Work resume: https://talk.vanillacoin.net/topic/143/temporary-proof-of-work-pause-at-block-117833/12
Thank you for your support.
Thank you for your support.
June 08, 2015, 02:47:21 PM
I feel the first post is confusing, inaccurate and not inline with the Vanillacoin project, therefore I have started an official topic here instead: https://bitcointalksearch.org/topic/--1064326
Not to mention that this thread is unmoderated
Not all opinions are equal and this applies specifically to Btctalk. So keeping a thread moderated is a reasonable choice.
June 08, 2015, 07:44:25 AM
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.
A code review might be useful if done by a panel of qualified experts with at least 20 years of professional distributed network programming experience, otherwise it is just an individual opinion. 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.
Thank you for your support.
Yes, it would just be an individual opinion and should only be taken as such. I think VNL is interesting enough that I asked him to look at it first though. So take that as a compliment.
Jump to: