Author

Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 735. (Read 4671575 times)

legendary
Activity: 2968
Merit: 1198
something seems odd on moneroblocks.eu:

Height Size Tx Timestamp Block Hash
857514 172 0 2015-12-06 22:27:18 29a7fab8e70f7427e83369e376c703466d659e9e82970c53207efc26a76ac46f
857513 210 0 2015-12-06 22:30:52 0577cccde88d30305510f02d2de74831b0dad75a63a968809245fe6e79e8595c
857512 1609 2 2015-12-06 22:27:25 7828369138ec760bf96621a1f6f618bd4585602719460dbfae1cbca63e025bfe

in this example it shows block 857514 with a timestamp before block 857513 (and before 857512)

whats wrong?
(timestamp seems off on many blocks there, blockheight is higher but timestamp is earlier)

Timestamps are approximate. They are set by the miner but if the miner's computer clock is off, the timestamp will be off. They're still accepted by the network if within some range.


thanks

don't know what's used to determine if the timestamp (and so the block is in the required range), but i guess the last x blocks are used to get the "real" time, or is there some other way?
I can't guess anything else then it has to be determined on something (blocks) in the blockchain to get a consensus of the "real time".
If so, isn't this an network attack vector?

What if an bad acting miner gets lucky (or owns big hashing power) and finds for example 10 consecutive blocks (xxx1, xxx2, xxx3, xxx4, ..., xx10), if i get it right he is allowed to set the timestamp for the block by his local time, inside the time window, so if he is a bad player and there is a time window of lets say 30 min between each block couldn't he just change the timestamp to something like:
block xxx1 real time + 25min
block xxx2 real time + 50min
block xxx2 real time + 75min
...
block xx10 real time + 250min

so every other miner who will try to submit a block after block xx10 will then be rejected, because their blocks are not in the allowed time window after the last block was 250min "later" then the real timestamp?!
So in the end only the bad acting miner will be able to mine new blocks?!

Does this makes sense? How does the determination/consensus of the "time window" works?

There is a maximum time "ahead" of 120 minutes. No one else will accept the block if it is more than 120 minutes ahead of what they think the current time is. So the miner in your example could mine those blocks but the later ones would be rejected by everyone else for some time period, during which time others would be able to mine different blocks, likely causing the bad miner's effort to be wasted.

There are some potential vulnerabilities having to do with time (look in google for bitcoin time attack or something). Monero is in some ways less vulnerable than Bitcoin because "network time" was never implemented, so you can't mess with nodes' notion of time with a sybil attack on the p2p network.
sr. member
Activity: 371
Merit: 250
something seems odd on moneroblocks.eu:

Height Size Tx Timestamp Block Hash
857514 172 0 2015-12-06 22:27:18 29a7fab8e70f7427e83369e376c703466d659e9e82970c53207efc26a76ac46f
857513 210 0 2015-12-06 22:30:52 0577cccde88d30305510f02d2de74831b0dad75a63a968809245fe6e79e8595c
857512 1609 2 2015-12-06 22:27:25 7828369138ec760bf96621a1f6f618bd4585602719460dbfae1cbca63e025bfe

in this example it shows block 857514 with a timestamp before block 857513 (and before 857512)

whats wrong?
(timestamp seems off on many blocks there, blockheight is higher but timestamp is earlier)

Timestamps are approximate. They are set by the miner but if the miner's computer clock is off, the timestamp will be off. They're still accepted by the network if within some range.


thanks

don't know what's used to determine if the timestamp (and so the block is in the required range), but i guess the last x blocks are used to get the "real" time, or is there some other way?
I can't guess anything else then it has to be determined on something (blocks) in the blockchain to get a consensus of the "real time".
If so, isn't this an network attack vector?

What if an bad acting miner gets lucky (or owns big hashing power) and finds for example 10 consecutive blocks (xxx1, xxx2, xxx3, xxx4, ..., xx10), if i get it right he is allowed to set the timestamp for the block by his local time, inside the time window, so if he is a bad player and there is a time window of lets say 30 min between each block couldn't he just change the timestamp to something like:
block xxx1 real time + 25min
block xxx2 real time + 50min
block xxx2 real time + 75min
...
block xx10 real time + 250min

so every other miner who will try to submit a block after block xx10 will then be rejected, because their blocks are not in the allowed time window after the last block was 250min "later" then the real timestamp?!
So in the end only the bad acting miner will be able to mine new blocks?!

Does this makes sense? How does the determination/consensus of the "time window" works?
legendary
Activity: 2268
Merit: 1141
something seems odd on moneroblocks.eu:

Height Size Tx Timestamp Block Hash
857514 172 0 2015-12-06 22:27:18 29a7fab8e70f7427e83369e376c703466d659e9e82970c53207efc26a76ac46f
857513 210 0 2015-12-06 22:30:52 0577cccde88d30305510f02d2de74831b0dad75a63a968809245fe6e79e8595c
857512 1609 2 2015-12-06 22:27:25 7828369138ec760bf96621a1f6f618bd4585602719460dbfae1cbca63e025bfe

in this example it shows block 857514 with a timestamp before block 857513 (and before 857512)

whats wrong?
(timestamp seems off on many blocks there, blockheight is higher but timestamp is earlier)

Timestamps are approximate. They are set by the miner but if the miner's computer clock is off, the timestamp will be off. They're still accepted by the network if within some range.


FWIW: This has occured in Bitcoin as well -> https://bitcointalksearch.org/topic/block-chains-time-stamp-is-nonsequential-391388
legendary
Activity: 2968
Merit: 1198
something seems odd on moneroblocks.eu:

Height Size Tx Timestamp Block Hash
857514 172 0 2015-12-06 22:27:18 29a7fab8e70f7427e83369e376c703466d659e9e82970c53207efc26a76ac46f
857513 210 0 2015-12-06 22:30:52 0577cccde88d30305510f02d2de74831b0dad75a63a968809245fe6e79e8595c
857512 1609 2 2015-12-06 22:27:25 7828369138ec760bf96621a1f6f618bd4585602719460dbfae1cbca63e025bfe

in this example it shows block 857514 with a timestamp before block 857513 (and before 857512)

whats wrong?
(timestamp seems off on many blocks there, blockheight is higher but timestamp is earlier)

Timestamps are approximate. They are set by the miner but if the miner's computer clock is off, the timestamp will be off. They're still accepted by the network if within some range.
sr. member
Activity: 371
Merit: 250
something seems odd on moneroblocks.eu:

Height Size Tx Timestamp Block Hash
857514 172 0 2015-12-06 22:27:18 29a7fab8e70f7427e83369e376c703466d659e9e82970c53207efc26a76ac46f
857513 210 0 2015-12-06 22:30:52 0577cccde88d30305510f02d2de74831b0dad75a63a968809245fe6e79e8595c
857512 1609 2 2015-12-06 22:27:25 7828369138ec760bf96621a1f6f618bd4585602719460dbfae1cbca63e025bfe

in this example it shows block 857514 with a timestamp before block 857513 (and before 857512)

whats wrong?
(timestamp seems off on many blocks there, blockheight is higher but timestamp is earlier)
legendary
Activity: 1276
Merit: 1001
I want to exit bitmonerod v.08.8.6-release with the exit command, well nothing happens.
See the output form the terminal -> could you please advise what i can do?
Code:
2015-Dec-01 19:34:19.190466 [P2P8][192.241.219.6:18080 OUT] SYNCHRONIZED OK
2015-Dec-01 19:34:20.050032 [P2P2][80.71.13.55:18080 OUT] SYNCHRONIZED OK
2015-Dec-01 19:34:56.476377 [P2P8][184.166.185.230:18080 OUT] SYNCHRONIZED OK
save
2015-Dec-01 19:38:51.230558 Storing blockchain...
2015-Dec-01 19:41:34.489371 Blockchain stored OK.
exit
2015-Dec-01 19:41:39.634967 [node] Stop signal sent
^C2015-Dec-01 19:43:13.872076 [SRV_MAIN][node] Stop signal sent
exit
^C2015-Dec-01 19:46:29.085640 [SRV_MAIN][node] Stop signal sent
The CPU load returns to "normal" but the process does not store and exit....

I think I might have found one possible reason. Do you have a log for that time (~/.bitmonerod/bitmonerod.log) ? I'm after the lines between 19:34:56.476377 and 19:43:13.872076 on the 1st in that log, to see if it matches what I found.

Edit: nevermind, it can't have been that from your output.
sr. member
Activity: 414
Merit: 251
If I recall the proposal correctly, it imposes a new rule on outputs. They cannot be spent in the next transaction unless a minimum mixin is provided. Correct me if I'm wrong. But what about the case when certain inputs cannot be mixed due to absence of ringsig partners?

There is an exception for that.

Also, non-standard outputs can't be created any more, so they will eventually be "used up".


What would be the reason for an absence of ring sig partners? I thought there were large numbers of mixins available for all but the largest size transactions (amounts higher than 99% of us even own). I cant find the link but somewhere I saw a listing of avaible mixins but value and there were many. Available mixins only increase over time right?

There are outputs with uneven amounts such as 0.0002452113 that won't necessarily match any other outputs.

In the future every output will be a multiple 1-9 of a power of ten, and indeed there are only a limited number of those (roughly 150, though the number in common use will be much smaller) and all except the very largest amounts will have many available.


Thanks for the explanation. The power of 10 solution should work well:)
member
Activity: 88
Merit: 10


THIS IS GENTLEMEN! 

moneroblocks.eu now shows the participating outputs in each ring signature. Enjoy.


marvelous work!

now its blatantly obvious how opaque monero transactions really are. There'll be a tip coming your way!!!

This update help make easier to explain Monero transactions to beginners.
legendary
Activity: 2968
Merit: 1198
Would it be possible or desirable to create/construe customized blocks to tie up such loose ends, along with any possibly malignant 0 mixin leftovers?

No because they belong to many different people.


What about a script/utility for every wallet account owner to use for cleaning up the dust/0mixins under their control?

Yes, its called sweep_dust (already implemented).



I like that feature. Is there a technical definition I can read to define "dust"?

I guess just in the code. https://github.com/monero-project/bitmonero/blob/master/src/simplewallet/simplewallet.cpp#L1846
https://github.com/monero-project/bitmonero/blob/master/src/simplewallet/simplewallet.cpp#L1846 is not a technical definition.

You are correct, that is a URL
sr. member
Activity: 252
Merit: 250
Earn by Forex. Try our services
Would it be possible or desirable to create/construe customized blocks to tie up such loose ends, along with any possibly malignant 0 mixin leftovers?

No because they belong to many different people.


What about a script/utility for every wallet account owner to use for cleaning up the dust/0mixins under their control?

Yes, its called sweep_dust (already implemented).



I like that feature. Is there a technical definition I can read to define "dust"?

I guess just in the code. https://github.com/monero-project/bitmonero/blob/master/src/simplewallet/simplewallet.cpp#L1846
https://github.com/monero-project/bitmonero/blob/master/src/simplewallet/simplewallet.cpp#L1846 is not a technical definition.
legendary
Activity: 2968
Merit: 1198
Would it be possible or desirable to create/construe customized blocks to tie up such loose ends, along with any possibly malignant 0 mixin leftovers?

No because they belong to many different people.


What about a script/utility for every wallet account owner to use for cleaning up the dust/0mixins under their control?

Yes, its called sweep_dust (already implemented).



I like that feature. Is there a technical definition I can read to define "dust"?

I guess just in the code. https://github.com/monero-project/bitmonero/blob/master/src/simplewallet/simplewallet.cpp#L1846

To me it looks like just outputs of below a given size, currently 0.01.




hero member
Activity: 686
Merit: 500
Would it be possible or desirable to create/construe customized blocks to tie up such loose ends, along with any possibly malignant 0 mixin leftovers?

No because they belong to many different people.


What about a script/utility for every wallet account owner to use for cleaning up the dust/0mixins under their control?

Yes, its called sweep_dust (already implemented).



I like that feature. Is there a technical definition I can read to define "dust"?
legendary
Activity: 2968
Merit: 1198
Would it be possible or desirable to create/construe customized blocks to tie up such loose ends, along with any possibly malignant 0 mixin leftovers?

No because they belong to many different people.


What about a script/utility for every wallet account owner to use for cleaning up the dust/0mixins under their control?

Yes, its called sweep_dust (already implemented).

legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
Would it be possible or desirable to create/construe customized blocks to tie up such loose ends, along with any possibly malignant 0 mixin leftovers?

No because they belong to many different people.


What about a script/utility for every wallet account owner to use for cleaning up the dust/0mixins under their control?
legendary
Activity: 2968
Merit: 1198
If someone sends an outstandingly large amount of Monero, she may create the outputs of the uniquely large size that haven't been created before by anyone.

Yes if you do that you won't be able to mix when you spend it (obviously). You will still be able to spend it though.

Maybe we will add some kind of warning to the wallet, or an option to generate multiple smaller outputs. That is not done yet.

There is an exception for that.

Is it anything interesting, or simple rule checking? Will this exact output in a transaction be just excluded from the rule?

I don't understand what you mean about "this exact output".

The rule is somewhat complicated, and I don't even remember the details. There are some conditions about how mixable and non-mixable inputs can be combined. The idea is limit use of non-mixed inputs but also not prevent people from spending their coins. There is also a sweep_dust command in the wallet to help combine large amounts of dust into a mixable (and more usable) form easily.

sr. member
Activity: 373
Merit: 250
I thought CN/XMR already did the powers of ten thing.  Where did the fiddly bits come from?

Would it be possible or desirable to create/construe customized blocks to tie up such loose ends, along with any possibly malignant 0 mixin leftovers?

The most common case is dust as smooth mentioned. Although I'm unaware whether XMR has made any adjustments to what is defined as dust.

I might be incorrect, but I believe there's also another option. If someone sends an outstandingly large amount of Monero, she may create the outputs of the uniquely large size that haven't been created before by anyone.

There is an exception for that.

Is it anything interesting, or simple rule checking? Will this exact output in a transaction be just excluded from the rule?
legendary
Activity: 2968
Merit: 1198
If I recall the proposal correctly, it imposes a new rule on outputs. They cannot be spent in the next transaction unless a minimum mixin is provided. Correct me if I'm wrong. But what about the case when certain inputs cannot be mixed due to absence of ringsig partners?

There is an exception for that.

Also, non-standard outputs can't be created any more, so they will eventually be "used up".


What would be the reason for an absence of ring sig partners? I thought there were large numbers of mixins available for all but the largest size transactions (amounts higher than 99% of us even own). I cant find the link but somewhere I saw a listing of avaible mixins but value and there were many. Available mixins only increase over time right?

There are outputs with uneven amounts such as 0.0002452113 that won't necessarily match any other outputs.

In the future every output will be a multiple 1-9 of a power of ten, and indeed there are only a limited number of those (roughly 150, though the number in common use will be much smaller) and all except the very largest amounts will have many available.

I thought CN/XMR already did the powers of ten thing.  Where did the fiddly bits come from?

It wasn't enforced, and the power-of-ten denominations weren't used below a certain value threshold.

Quote
Would it be possible or desirable to create/construe customized blocks to tie up such loose ends, along with any possibly malignant 0 mixin leftovers?

No because they belong to many different people.
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
If I recall the proposal correctly, it imposes a new rule on outputs. They cannot be spent in the next transaction unless a minimum mixin is provided. Correct me if I'm wrong. But what about the case when certain inputs cannot be mixed due to absence of ringsig partners?

There is an exception for that.

Also, non-standard outputs can't be created any more, so they will eventually be "used up".


What would be the reason for an absence of ring sig partners? I thought there were large numbers of mixins available for all but the largest size transactions (amounts higher than 99% of us even own). I cant find the link but somewhere I saw a listing of avaible mixins but value and there were many. Available mixins only increase over time right?

There are outputs with uneven amounts such as 0.0002452113 that won't necessarily match any other outputs.

In the future every output will be a multiple 1-9 of a power of ten, and indeed there are only a limited number of those (roughly 150, though the number in common use will be much smaller) and all except the very largest amounts will have many available.

I thought CN/XMR already did the powers of ten thing.  Where did the fiddly bits come from?

Would it be possible or desirable to create/construe customized blocks to tie up such loose ends, along with any possibly malignant 0 mixin leftovers?
legendary
Activity: 2968
Merit: 1198
If I recall the proposal correctly, it imposes a new rule on outputs. They cannot be spent in the next transaction unless a minimum mixin is provided. Correct me if I'm wrong. But what about the case when certain inputs cannot be mixed due to absence of ringsig partners?

There is an exception for that.

Also, non-standard outputs can't be created any more, so they will eventually be "used up".


What would be the reason for an absence of ring sig partners? I thought there were large numbers of mixins available for all but the largest size transactions (amounts higher than 99% of us even own). I cant find the link but somewhere I saw a listing of avaible mixins but value and there were many. Available mixins only increase over time right?

There are outputs with uneven amounts such as 0.0002452113 that won't necessarily match any other outputs.

In the future every output will be a multiple 1-9 of a power of ten, and indeed there are only a limited number of those (roughly 150, though the number in common use will be much smaller) and all except the very largest amounts will have many available.


sr. member
Activity: 414
Merit: 251
If I recall the proposal correctly, it imposes a new rule on outputs. They cannot be spent in the next transaction unless a minimum mixin is provided. Correct me if I'm wrong. But what about the case when certain inputs cannot be mixed due to absence of ringsig partners?

There is an exception for that.

Also, non-standard outputs can't be created any more, so they will eventually be "used up".


What would be the reason for an absence of ring sig partners? I thought there were large numbers of mixins available for all but the largest size transactions (amounts higher than 99% of us even own). I cant find the link but somewhere I saw a listing of avaible mixins but value and there were many. Available mixins only increase over time right?
Jump to: