Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1395. (Read 4671575 times)
September 24, 2014, 02:54:15 PM
Edit: never mind, seems this isn't to do with the ongoing attack threat and the devs are already on top of it.
September 24, 2014, 02:52:28 PM
thinks.
how long temporary security precaution？
how long temporary security precaution？
The initial announcement was for 24 hours. We're waiting for the developers to post more details if there's anything going on that would require it to be prolonged.
September 24, 2014, 02:51:53 PM
Hi folk,
I suspect some potential problem, so i would like to ask to contact me every exchange that trade CN (especially Polo, Bittrex and Bter).
If someone is in touch with exchange operators, please let them know.
Zoidberg
I suspect some potential problem, so i would like to ask to contact me every exchange that trade CN (especially Polo, Bittrex and Bter).
If someone is in touch with exchange operators, please let them know.
Zoidberg
X-posted from BBR thread. Seems an attack against Cryptonote coins may actually be underway?
Is there a link to actual post where crypto_zoidberg posted this?
September 24, 2014, 02: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?
September 24, 2014, 02:37:43 PM
bittrex.com
Disabled Monero Disabled XMR
？？？
wallet offline precaution at request of the devs
why?
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 want deposit xmr.
temporary security precaution
how long temporary security precaution？
September 24, 2014, 02:23:24 PM
Edit: never mind, seems this isn't to do with the ongoing attack threat and the devs are already on top of it.
September 24, 2014, 01:38:00 PM
bittrex.com
Disabled Monero Disabled XMR
？？？
wallet offline precaution at request of the devs
why?
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 want deposit xmr.
temporary security precaution
September 24, 2014, 01:36:13 PM
bittrex.com
Disabled Monero Disabled XMR
？？？
wallet offline precaution at request of the devs
why?
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 want deposit xmr.
September 24, 2014, 12:53:24 PM
bittrex.com
Disabled Monero Disabled XMR
？？？
wallet offline precaution at request of the devs
why?
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]
September 24, 2014, 12:39:00 PM
bittrex.com
Disabled Monero Disabled XMR
？？？
wallet offline precaution at request of the devs
why?
Disabled Monero Disabled XMR
？？？
wallet offline precaution at request of the devs
why?
September 24, 2014, 12: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:)
September 24, 2014, 12: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 
September 24, 2014, 11:22:03 AM
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
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
September 24, 2014, 10:35:20 AM
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!
September 24, 2014, 10:31:39 AM
... 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. September 24, 2014, 10:28:12 AM
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
September 24, 2014, 10:26:14 AM
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/155
With 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.
September 24, 2014, 10:18:14 AM
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/155
With 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.
September 24, 2014, 10:03:21 AM
[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
[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.
September 24, 2014, 09:52:57 AM
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.
Jump to: