Dogeshop_eu
Member
Offline
Activity: 148
Merit: 10
|
|
September 24, 2014, 02:10:22 PM |
|
I still cannot see bcxs agenda
1 - spread fud 2 - buy XMR 3 - pretend to attack 4 - buy XMR 5 - say that the flaw has been fixed by devs 6 - sell XMR 7 - repeat on an other coin 8 - ?? Hmm sounds like a businnessplan
|
|
|
|
xulescu
|
|
September 24, 2014, 02:38:55 PM |
|
[11:28:52] fluffypony: the best way to prevent this sort of attack is to have a very, very large network hashrate [11:29:01] fluffypony: ours is still relatively small [11:29:36] Myagui: yeah, which begs for more/better miner software - particularly opensource for AMD (of which I have none, btw) [11:29:57] fluffypony: attacking Monero now using brute hashrate alone is a cop-out, because our network isn't strong enough to be considered "safe" by decentralised standards [11:30:08] dnaleor_: Myagui, bitcoin solved this problem exactly like xmr: https://en.bitcoin.it/wiki/Checkpoint_Lockin[11:31:19] Myagui: dnaleor_: got it, but just as fluffypony and I were getting too, that's not really a "solution", it's mitigation (and requires babysitting) [11:31:29] fluffypony: Myagui: yes [11:31:41] fluffypony: remember, Monero isn't a decentralised cryptocurrency yet [11:31:54] fluffypony: it *can be* one in the future when the network is bigger / stronger [11:32:17] fluffypony: so anyone buying Monero now isn't buying it because it's a perfect example of a decentralised cryptocurrency [11:32:25] fluffypony: they're buying it because it can potentially be one in future Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.
|
|
|
|
OrientA
|
|
September 24, 2014, 02:51:30 PM |
|
Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.
Are we going to have nightly build of the wallet file? That is quite inconvenient.
|
|
|
|
ArticMine
Legendary
Offline
Activity: 2282
Merit: 1050
Monero Core Team
|
|
September 24, 2014, 02:52:57 PM Last edit: September 24, 2014, 03:17:08 PM by ArticMine |
|
Does checkpointing make XMR more like a centralized currency?
no Well, actually, to some degree it is a form of centralised control. I'll quote from IRC - [11:28:52] fluffypony: the best way to prevent this sort of attack is to have a very, very large network hashrate [11:29:01] fluffypony: ours is still relatively small [11:29:36] Myagui: yeah, which begs for more/better miner software - particularly opensource for AMD (of which I have none, btw) [11:29:57] fluffypony: attacking Monero now using brute hashrate alone is a cop-out, because our network isn't strong enough to be considered "safe" by decentralised standards [11:30:08] dnaleor_: Myagui, bitcoin solved this problem exactly like xmr: https://en.bitcoin.it/wiki/Checkpoint_Lockin [11:31:19] Myagui: dnaleor_: got it, but just as fluffypony and I were getting too, that's not really a "solution", it's mitigation (and requires babysitting) [11:31:29] fluffypony: Myagui: yes [11:31:41] fluffypony: remember, Monero isn't a decentralised cryptocurrency yet [11:31:54] fluffypony: it *can be* one in the future when the network is bigger / stronger [11:32:17] fluffypony: so anyone buying Monero now isn't buying it because it's a perfect example of a decentralised cryptocurrency [11:32:25] fluffypony: they're buying it because it can potentially be one in future
A poor use of "perfect", but you get the drift. It can be a form of centralised control but it does not have to be. If the location of checkpoints is left to the developers then checkpoints become trusting the developers over the longest chain. There is however no reason in principle why this has to be the case, if the function of deciding where the checkpoints are, is separated from that of implementing the checkpoints in code. A POW currency can function perfectly well with different users, miners etc., disagreeing on this point and implementing checkpoints at different locations in the chain. One must recognize that the only barrier preventing end users miners etc., from choosing the location of checkpoints independently of the developers is coding skills. I for example may choose to disagree with fluffypony on the appropriate location of checkpoints while trusting his coding skills in implementing them.
|
|
|
|
NewLiberty
Legendary
Offline
Activity: 1204
Merit: 1002
Gresham's Lawyer
|
|
September 24, 2014, 03:03:21 PM |
|
[11:28:52] fluffypony: the best way to prevent this sort of attack is to have a very, very large network hashrate [11:29:01] fluffypony: ours is still relatively small [11:29:36] Myagui: yeah, which begs for more/better miner software - particularly opensource for AMD (of which I have none, btw) [11:29:57] fluffypony: attacking Monero now using brute hashrate alone is a cop-out, because our network isn't strong enough to be considered "safe" by decentralised standards [11:30:08] dnaleor_: Myagui, bitcoin solved this problem exactly like xmr: https://en.bitcoin.it/wiki/Checkpoint_Lockin[11:31:19] Myagui: dnaleor_: got it, but just as fluffypony and I were getting too, that's not really a "solution", it's mitigation (and requires babysitting) [11:31:29] fluffypony: Myagui: yes [11:31:41] fluffypony: remember, Monero isn't a decentralised cryptocurrency yet [11:31:54] fluffypony: it *can be* one in the future when the network is bigger / stronger [11:32:17] fluffypony: so anyone buying Monero now isn't buying it because it's a perfect example of a decentralised cryptocurrency [11:32:25] fluffypony: they're buying it because it can potentially be one in future Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable. This is the germ of what I wrote up and offered to the devs last weekend after working through the ideas with ArticMine. The idea is the TW killer, a polymorphic perpetually self-checkpointing client However it brings other issues, the aging of the CP until when they are useful, and until when they are no longer useful. The integrity verifiability you mention is another, the CP frequency, dealing with error recovery, and other variables. It would be easy to get this wrong or render it useless or simply be redundant with the existing block chain. It isn't something that ought be implemented in 'forced evolution' mode, but there may be something really good here.
|
|
|
|
fluffypony
Donator
Legendary
Offline
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
|
|
September 24, 2014, 03:18:14 PM |
|
Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.
We had this discussion a little while ago. If we provide a reasonably fast way of deploying run-time checkpoints, should the application verify them as being from us (the core team) or not? If they're verifiably from us (on the app side) we're centralising "control". If they're not verified, then a malicious attacker could send his own checkpoints. But if a malicious attacker has access to your .bitmonero / %APPDATA%/bitmonero folder, or he can convince you to put a file there, why bother with fake checkpoints? He can give you a fake p2pstate.bin or a fake blockchain.bin, so this is a nonsensical attack vector. Plus open checkpoints evaluated at runtime allow us to disappear off the face of the earth and a new group could still deliver checkpoints (ie. a reduction in centralisation). Thus, flat-file checkpoints seem to answer the immediate need for on-demand checkpointing. There's still a bit of work to do to manage periodic updates, but we're almost there - https://github.com/monero-project/bitmonero/pull/155With regards to rapidly delivering emergency checkpoints (which is, frankly, a different use-case) we're working on a solution for that too. We expect all of these to be temporary solutions that last for a few years only, after which we can remove them.
|
|
|
|
ArticMine
Legendary
Offline
Activity: 2282
Merit: 1050
Monero Core Team
|
|
September 24, 2014, 03:26:14 PM |
|
Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.
We had this discussion a little while ago. If we provide a reasonably fast way of deploying run-time checkpoints, should the application verify them as being from us (the core team) or not? If they're verifiably from us (on the app side) we're centralising "control". If they're not verified, then a malicious attacker could send his own checkpoints. But if a malicious attacker has access to your .bitmonero / %APPDATA%/bitmonero folder, or he can convince you to put a file there, why bother with fake checkpoints? He can give you a fake p2pstate.bin or a fake blockchain.bin, so this is a nonsensical attack vector. Plus open checkpoints evaluated at runtime allow us to disappear off the face of the earth and a new group could still deliver checkpoints (ie. a reduction in centralisation). Thus, flat-file checkpoints seem to answer the immediate need for on-demand checkpointing. There's still a bit of work to do to manage periodic updates, but we're almost there - https://github.com/monero-project/bitmonero/pull/155With regards to rapidly delivering emergency checkpoints (which is, frankly, a different use-case) we're working on a solution for that too. We expect all of these to be temporary solutions that last for a few years only, after which we can remove them. Once could also give the end user the choice between requiring the application verify the checkpoints as being from the core team or not.
|
|
|
|
fluffypony
Donator
Legendary
Offline
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
|
|
September 24, 2014, 03:28:12 PM |
|
Once could also give the end user the choice between requiring the application verify the checkpoints as being from the core team or not.
Yes, but time is not on our side
|
|
|
|
xulescu
|
|
September 24, 2014, 03:31:39 PM |
|
... checkpoints ...
I think the best option is that each client could create checkpoints itself for blocks old enough. In this context, all the files in ~/.bitmonero or %APPDATA%/bitmonero should probably self-signed by the client on exit. Clients could generate their own keys but that opens up other problems.
|
|
|
|
infofront
Legendary
Offline
Activity: 2646
Merit: 2793
Shitcoin Minimalist
|
|
September 24, 2014, 03:35:20 PM |
|
Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.
Are we going to have nightly build of the wallet file? That is quite inconvenient. Man up solider!
|
|
|
|
argentinx
Member
Offline
Activity: 109
Merit: 10
|
|
September 24, 2014, 04:22:03 PM |
|
sorry for English but I'm using google translator
I do not know how it works the blockchain so I write what I think
if I understand correctly there are master nodes servers that are managed by the dev team with bitmonerod above
I understand it a timewarp attack should be a fork of blockchain in practice two blockchain at the same time that's right? the only problem that would would double spending or are there others?
you could not put in the code that whenever bitmonerod download a new block the comparisons with blocks of all the master node if there are two different blocks type 5 master node with a block and 3 with a different block "one of the two would be the fork"
wins the block that is on more master node and then automatically the client who understands that its not the block that won auto erase the blockchain and download once again the blockchain all lead to eliminate the fork would remain only a blockchain it would eliminate the problem instantly double spending
one thing I did not understand when there is this attack occurs against a master node? or a normal node if no you can enter in the source code that the only blockchain exact is present in the master node
if it brings other problems this type of attack In addition to double spending you could explain it? thanks
|
|
|
|
klee
Legendary
Offline
Activity: 1498
Merit: 1000
|
|
September 24, 2014, 05:16:47 PM |
|
OK, I'm thoroughly confused. But I do know that if XMR survives this thorough thrashing, it will rise like a Pheonix. I commend those who would protect the ring signatures from the time warp.
At least use bold text
|
|
|
|
fluffypony
Donator
Legendary
Offline
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
|
|
September 24, 2014, 05:31:01 PM |
|
It can literally become a war of attrition; however if the defence is in the process of developing a permanent fix then time is on the side of the defence. I compiled bitmonerod 4x over the last 24 hours on different computers. And thanks to whoever updated the makefile with the release-static target, as now I can just pull and build once on my main mac, and then copy the bitmonerod file around to my other macs that aren't setup to build but can still solo mine. That was me, I got frustrated with manually building static binaries...it's a pleasure:)
|
|
|
|
skygong
Newbie
Offline
Activity: 9
Merit: 0
|
|
September 24, 2014, 05:39:00 PM |
|
bittrex.com
Disabled Monero Disabled XMR
???
wallet offline precaution at request of the devs
why?
|
|
|
|
owlcatz
Legendary
Offline
Activity: 3766
Merit: 1973
|
|
September 24, 2014, 05:53:24 PM Last edit: September 24, 2014, 06:12:06 PM by owlcatz |
|
bittrex.com
Disabled Monero Disabled XMR
???
wallet offline precaution at request of the devs
why?
Here is the best and shortest write-up i've seen so far. btw, you should be able to buy/sell, just not withdraw or deposit. http://bullbearanalytics.com/2014/09/23/whats-going-monero/[edit - removed tracking info that i missed sorry]
|
. I C Λ R U S | | | | █████▄▄█████▄▄ ████████▀▀▀████ ██████▀█████▀███ ████████████████ ████████████████ ████████████████ ░▄█████████████████ ███████████████████ ███████████████████ ████████░░░▀▀▀▀▀▀▀▀ ████████▄▄▄████████ ███████████████████ █████████████████▀ | ░░░███ ▄▄▄███ ██████ ░░░███ ░░░███ ░░░███ ░░░███ ░░░███ ░░░███ ░░░███ ▄████████ ███▌░▐███ ████████▀ | | | | | █████████████████████ █████████████████████ █████████████████████ ██████▀▀▀▀████▀▀█████ █████░░▄▄░░██░░░█████ █████▄▄██░░███░░█████ █████▀▀▀▀░░▀██░░█████ ████░░░░▄▄▄▄█▀░░▀████ ████░░░░░░░░█░▀▀░████ █████████████████████ █████████████████████ █████████████████████ █████████████████████ | ████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ | ████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ | ████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ | | | | ████ ██
██ ████ | | ████ ██
██ ████ |
[/ce
|
|
|
skygong
Newbie
Offline
Activity: 9
Merit: 0
|
|
September 24, 2014, 06:36:13 PM |
|
bittrex.com
Disabled Monero Disabled XMR
???
wallet offline precaution at request of the devs
why?
Here is the best and shortest write-up i've seen so far. btw, you should be able to buy/sell, just not withdraw or deposit. http://bullbearanalytics.com/2014/09/23/whats-going-monero/[edit - removed tracking info that i missed sorry] thinks ,I not withdraw or deposit. why? I want deposit xmr.
|
|
|
|
infofront
Legendary
Offline
Activity: 2646
Merit: 2793
Shitcoin Minimalist
|
|
September 24, 2014, 06:38:00 PM |
|
bittrex.com
Disabled Monero Disabled XMR
???
wallet offline precaution at request of the devs
why?
Here is the best and shortest write-up i've seen so far. btw, you should be able to buy/sell, just not withdraw or deposit. http://bullbearanalytics.com/2014/09/23/whats-going-monero/[edit - removed tracking info that i missed sorry] thinks ,I not withdraw or deposit. why? I want deposit xmr. temporary security precaution
|
|
|
|
psterryl
Member
Offline
Activity: 87
Merit: 10
|
|
September 24, 2014, 07:23:24 PM Last edit: September 24, 2014, 08:11:06 PM by psterryl |
|
Edit: never mind, seems this isn't to do with the ongoing attack threat and the devs are already on top of it.
|
|
|
|
skygong
Newbie
Offline
Activity: 9
Merit: 0
|
|
September 24, 2014, 07:37:43 PM |
|
bittrex.com
Disabled Monero Disabled XMR
???
wallet offline precaution at request of the devs
why?
Here is the best and shortest write-up i've seen so far. btw, you should be able to buy/sell, just not withdraw or deposit. http://bullbearanalytics.com/2014/09/23/whats-going-monero/[edit - removed tracking info that i missed sorry] thinks ,I not withdraw or deposit. why? I want deposit xmr. temporary security precaution thinks. how long temporary security precaution?
|
|
|
|
25hashcoin
|
|
September 24, 2014, 07:51:42 PM |
|
I've never mined any coin in my life. I am interested in mining Monero. I run Ubuntu. Is there an easy/straightforward guide on how i can set this up?
|
Bitcoin - Peer to Peer Electronic CASH
|
|
|
|