[XMR] Monero - A secure, private, untraceable cryptocurrency

[aerbax]

I remember reading a while back that 0MQ is in one of the developmental branches.  If I wanted to play around with that, which branch/repo should I clone?

[dEBRUYNE]

I remember reading a while back that 0MQ is in one of the developmental branches.  If I wanted to play around with that, which branch/repo should I clone?

If I recall correctly, this one -> https://github.com/monero-project/bitmonero/tree/development

[Hueristic]

...

Another interesting improvement is change of the base cryptography to the actual standard, as opposed to the cryptonote version of the cryptography. ...

Do you have a link for a more detailed explanation on this?

The original crypto code was taken from Daniel J. Bernstein's library without attribution, slightly modified (though the modifications have been reviewed and were not nefarious).

The copied/modified code has been replaced by the actual, original Danlel J. Bernstein crypto library, which makes more clear the source and integrity of the crypto library. It will also make it easier to incorporate upstream patches to the crypto library if any are released.

Thx

[LucyLovesCrypto]

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?

[smooth]

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.

[iCEBREAKER]

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?

[smooth]

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.

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.

[Rias]

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?

[smooth]

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.

[iCEBREAKER]

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?

[smooth]

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).

[newb4now]

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"?

[smooth]

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.

[DeathProxyX]

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.

[smooth]

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

[8XMR]

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.

[LucyLovesCrypto]

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:)

[MoneroMooo]

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.

[megges]

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)

[smooth]

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.