jwinterm
Legendary
Offline
Activity: 3136
Merit: 1116
|
|
December 03, 2015, 02:27:15 AM |
|
Anyone have working win32 binaries that they compiled? Is it really tricky to build Berkeley DB on windows?
Anyone tried building for ARM and running on a tablet or raspberry pi? Do you also need to use BDB there?
Can you build a simplewallet target without any database, LMDB or BDB, for win32 or ARM?
Also, is there (plans to implement) an RPC or 0MQ call to shutdown bitmonerod or simplewallet (gracefully)?
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
December 03, 2015, 02:30:14 AM |
|
Anyone tried building for ARM and running on a tablet or raspberry pi? Do you also need to use BDB there?
Yes and yes Also, is there (plans to implement) an RPC or 0MQ call to shutdown bitmonerod or simplewallet (gracefully)?
Pull requests accepted.
|
|
|
|
Hueristic
Legendary
Offline
Activity: 3976
Merit: 5411
Doomed to see the future and unable to prevent it
|
|
December 03, 2015, 06:10:35 AM |
|
THIS IS GENTLEMEN!
moneroblocks.eu now shows the participating outputs in each ring signature. Enjoy. Looks great! Anyone have an idea why there is such a large percentage of 7.8255 XMR sized transactions?
|
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
December 03, 2015, 06:14:07 AM |
|
Anyone have an idea why there is such a large percentage of 7.8255 XMR sized transactions?
That is approximately the size of the current block reward (coinbase). Although the transaction you included in your post had inputs so it wasn't a coinbase, it was probably a miner or pool moving one of their block rewards.
|
|
|
|
Hueristic
Legendary
Offline
Activity: 3976
Merit: 5411
Doomed to see the future and unable to prevent it
|
|
December 03, 2015, 06:19:43 AM |
|
Anyone have an idea why there is such a large percentage of 7.8255 XMR sized transactions?
That is approximately the size of the current block reward (coinbase). Although the transaction you included in your post had inputs so it wasn't a coinbase, it was probably a miner or pool moving one of their block rewards. W0w it's dropped that much! I thought it was in the 9's.
|
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
|
|
|
equipoise
|
|
December 03, 2015, 10:09:04 AM Last edit: December 03, 2015, 11:46:49 AM by equipoise |
|
//offtopic. I'll delete it if against the rules. We are raising donations for this campaign. There are already 351$ and 0.0403 BTC in donations for Bojia: "The 80 years old mother Bojia Bikova was accused of growing hemp by the Bulgarian police, who found a few uprooted sprigs of hemp in her field in the countryside. She was sentenced to pay about $1100 including court taxes. The monthly pension of old mother Bojia is $100. The amount she has to pay is close to the full amount of her pension for the whole year." You could watch a short video about her case here: https://www.youtube.com/watch?v=gqmGkti9uUQ. I created an XMR address for this campaign. Please support it. If in doubt about the validity of the address, I could ask our admin to add an OpenAlias XMR address to promena.org: 49bXbjMqAGmQCApWssWKMd9pnMq2AnExkUCrajnAeGM6dsJNagvwCd8VQxVWs3gamMQTxWirG9yrEeKpSocFyTGbH4TEvu4 //offtopic This may be the first non-governmental organization accepting Monero donations for its campaigns. We added OpenAlias xmr address to promena.org. It seems that the domain registrar is not adding TXT DNS records correctly with their GUI. They are adding "invisible spaces" like the space in the Monero address in bitcointalk (you could see the spaces here - type promena.org and select TXT record: http://manytools.org/network/query-dns-records-online). The result is that you can't add a valid OpenAlias address (or any valid long words TXT record). How many domain registrars are out there which are doing the same? The domain registrar fixed their bug and the OpenAlias address promena.org is now working for the "Bojia" campaign. My contribution is 20 XMR. I'll make sure the total sum of Monero donations is cited at the end of the campaign and I'm pretty sure a successful campaign will catch some media attention (Bulgarian media are already following the "Bojia" case). OpenAlias Monero address added to promena.org for the "Bojia" campaign. You could now send XMR to promena.org - there are 107 XMR in donations till now.
Donation of 25 XMR just sent Great. Thank you! We are at 371$ + 134 XMR + 0.0402 BTC. 12 days left till the end of the campaign. The Indiegogo campaign ended on on December 2, 2015 with $376 USD in donations. The bithope campaign is still on 0.0402 BTC and the XMR campaign is still on 134 XMR. Converted to Bulgarian Lev (that's what the fine should be paid in) on today's rate that makes 810 BGL (45% from the 1800 BGL needed for the fine). We are still accepting BTC and XMR donations and we'll soon decide what to do next.
|
|
|
|
Rias
|
|
December 03, 2015, 11:36:37 AM |
|
Hey everyone, Can anybody provide a quick update as to what's been up to Monero development recently and what the short/mid term goals are.
Thanks.
|
|
|
|
MoneroMooo
Legendary
Offline
Activity: 1276
Merit: 1001
|
|
December 03, 2015, 12:00:46 PM |
|
Also, is there (plans to implement) an RPC or 0MQ call to shutdown bitmonerod or simplewallet (gracefully)?
There is one for the daemon (stop_daemon), but not the wallet. I'll add that next time I hack on it, it's pretty simple.
|
|
|
|
GingerAle
Legendary
Offline
Activity: 1260
Merit: 1008
|
|
December 03, 2015, 12:17:22 PM |
|
Hey everyone, Can anybody provide a quick update as to what's been up to Monero development recently and what the short/mid term goals are.
Thanks.
I can provide a quick update, but I don't know if it will be a correct update The current push is to get the 0.9 binaries released, which include major improvements over the last release. In-line with the development priorities after the block 20612 attack ( https://bitcointalk.org/index.php?topic=583449.msg8677607#msg8677607), the primary improvements are in the underlying protocol. I can't give a full rundown of what these are, and its been listed somewhere before, but IMO a main improvement is the movement of the blockchain to an LMDB database. LMDB is quite an impressive database solution - it has dynamic memory usage, so if your system has the available RAM and bitmonerod needs it, then it will use it. However, once its done needing all of this ram (mostly during sync), the 0.9 binaries use about 50 MB of RAM. Furthermore, LMDB was built to withstand database corruption. So if you lose power, or your daemon exits uncleanly, your database is intact. This is in contrast to mostly all other cryptocurrencies that use bdb, which apparently requires re-indexing or something after not-so-uncommon events. Indeed, I find the fact that monero is the only cryptocurrency using LMDB kind of ridiculous, considering that the entire technology is based on a database. Currently with work with the database improvements is to ensure all of the failovers / other implementations are functioning properly... i.e., a bdb implementation is still necessary for 32 bit systems, and ARM systems also require a different solution than LMDB, so I think these are the final sanity checks before 0.9 is released. Another interesting improvement is change of the base cryptography to the actual standard, as opposed to the cryptonote version of the cryptography. The above two instances sort of exemplify the work thats been done leading up to the 0.9 release - the cryptonote codebase was a bit messy (apparently... im just regurgitating what I've been told because im no coder). Thus, in order to actually make the network stable, the underlying code had to be improved. Additionally, there are some pretty core changes in the protocol being implemented for an upcoming hardfork. Primarily, a minimum mixin will be required - this significantly enhances the privacy of the blockchain. For research in the minimum mixin and mixin 0 problem, check out one of the Monero Research Bulletins. Blocktimes will also be changed to 2 minutes in order to try and fix the amount of reorgs that occur. Finally, a lot of work has been done in simplewallet to increase the utility of actually using the monero protocol / blockchain / network. For instance, one can now use integrated payment IDs, instead of attaching a payment ID to a transaction. This also increases privacy because in the cryptonote implementations, payment IDs are unencrypted / unmasked etc.... essentially just plain text on the blockchain. Now only the sender and receiver can de-code the payment ID. There are also view-only wallets, providing users with some security knowing that intruders onto their hardware can't use their bins to spend their monero. Simplewallet sync times have also been improved. Thats the stuff that manifests most obvious to me, as a non-coder monero enthusiast that plays around with the software to beta test etc. This is probably a disservice to the coders that have worked on this, because there's probably a lot more. The next wave of work going into the next release will also be amazing. 0MQ is already implemented in the development branch, and its quirks are being worked out. i2p integrating is also going into the development branch. Ring-confidential transactions will also be in the development branch at some point, which means that now the amount of a transaction will also be private. The easy answer would be to point you here: https://getmonero.org/design-goals/Long story short, if I had more money I'd be buying more monero.
|
|
|
|
Rias
|
|
December 03, 2015, 01:11:10 PM |
|
Thank you for the update. LMDB seems interesting indeed. Primarily, a minimum mixin will be required - this significantly enhances the privacy of the blockchain. For research in the minimum mixin and mixin 0 problem, check out one of the Monero Research Bulletins. 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? 0MQ is already implemented in the development branch, and its quirks are being worked out. I'd appreciate a dev going more into why 0MQ is a better choice than RPC.
|
|
|
|
megges
|
|
December 03, 2015, 02:18:53 PM |
|
I'd appreciate a dev going more into why 0MQ is a better choice than RPC.
not an expert i 0MQ, but: RPC = remote procedure call 0MQ will still used as remote calls (aka RPC) 0MQ is more the underlying tech/lib/... which will handle the RPC requests, or am i wrong?
|
tip me! XtSrWch1U3BsTBFBHj7acTTzxFo1fy5BMa
|
|
|
onemorexmr
|
|
December 03, 2015, 03:17:21 PM |
|
I'd appreciate a dev going more into why 0MQ is a better choice than RPC.
not an expert i 0MQ, but: RPC = remote procedure call 0MQ will still used as remote calls (aka RPC) 0MQ is more the underlying tech/lib/... which will handle the RPC requests, or am i wrong? just a few benefits: - multiple calls over one tcp connection - loadbalancing - automatic retry handling (eg when server restarts) - reliable EDIT: 0mq is to http what tcp is to udp.. much more useable and less hassle for 3parties.
|
|
|
|
xa4
Member
Offline
Activity: 71
Merit: 10
|
|
December 03, 2015, 06:06:54 PM |
|
Hi GingerAle, Thanks for your summary. Two things I don't quite understand. Blocktimes will also be changed to 2 minutes in order to try and fix the amount of reorgs that occur. What are reorgs ? Ring-confidential transactions will also be in the development branch at some point, which means that now the amount of a transaction will also be private What do you mean it will be private ? Isn't it already private (with mixin) ? Am I wrong or are Confidential Transaction more obscure than current implementation ? Hey everyone, Can anybody provide a quick update as to what's been up to Monero development recently and what the short/mid term goals are.
Thanks.
I can provide a quick update, but I don't know if it will be a correct update The current push is to get the 0.9 binaries released, which include major improvements over the last release. In-line with the development priorities after the block 20612 attack ( https://bitcointalk.org/index.php?topic=583449.msg8677607#msg8677607), the primary improvements are in the underlying protocol. I can't give a full rundown of what these are, and its been listed somewhere before, but IMO a main improvement is the movement of the blockchain to an LMDB database. LMDB is quite an impressive database solution - it has dynamic memory usage, so if your system has the available RAM and bitmonerod needs it, then it will use it. However, once its done needing all of this ram (mostly during sync), the 0.9 binaries use about 50 MB of RAM. Furthermore, LMDB was built to withstand database corruption. So if you lose power, or your daemon exits uncleanly, your database is intact. This is in contrast to mostly all other cryptocurrencies that use bdb, which apparently requires re-indexing or something after not-so-uncommon events. Indeed, I find the fact that monero is the only cryptocurrency using LMDB kind of ridiculous, considering that the entire technology is based on a database. Currently with work with the database improvements is to ensure all of the failovers / other implementations are functioning properly... i.e., a bdb implementation is still necessary for 32 bit systems, and ARM systems also require a different solution than LMDB, so I think these are the final sanity checks before 0.9 is released. Another interesting improvement is change of the base cryptography to the actual standard, as opposed to the cryptonote version of the cryptography. The above two instances sort of exemplify the work thats been done leading up to the 0.9 release - the cryptonote codebase was a bit messy (apparently... im just regurgitating what I've been told because im no coder). Thus, in order to actually make the network stable, the underlying code had to be improved. Additionally, there are some pretty core changes in the protocol being implemented for an upcoming hardfork. Primarily, a minimum mixin will be required - this significantly enhances the privacy of the blockchain. For research in the minimum mixin and mixin 0 problem, check out one of the Monero Research Bulletins. Blocktimes will also be changed to 2 minutes in order to try and fix the amount of reorgs that occur. Finally, a lot of work has been done in simplewallet to increase the utility of actually using the monero protocol / blockchain / network. For instance, one can now use integrated payment IDs, instead of attaching a payment ID to a transaction. This also increases privacy because in the cryptonote implementations, payment IDs are unencrypted / unmasked etc.... essentially just plain text on the blockchain. Now only the sender and receiver can de-code the payment ID. There are also view-only wallets, providing users with some security knowing that intruders onto their hardware can't use their bins to spend their monero. Simplewallet sync times have also been improved. Thats the stuff that manifests most obvious to me, as a non-coder monero enthusiast that plays around with the software to beta test etc. This is probably a disservice to the coders that have worked on this, because there's probably a lot more. The next wave of work going into the next release will also be amazing. 0MQ is already implemented in the development branch, and its quirks are being worked out. i2p integrating is also going into the development branch. Ring-confidential transactions will also be in the development branch at some point, which means that now the amount of a transaction will also be private. The easy answer would be to point you here: https://getmonero.org/design-goals/Long story short, if I had more money I'd be buying more monero.
|
|
|
|
Hueristic
Legendary
Offline
Activity: 3976
Merit: 5411
Doomed to see the future and unable to prevent it
|
|
December 03, 2015, 07:45:51 PM |
|
Ring-confidential transactions will also be in the development branch at some point, which means that now the amount of a transaction will also be private What do you mean it will be private ? Isn't it already private (with mixin) ? Am I wrong or are Confidential Transaction more obscure than current implementation ? Amounts of transactions are not hidden. http://moneroblocks.eu/...
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?
|
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
December 03, 2015, 07:49:11 PM |
|
Ring-confidential transactions will also be in the development branch at some point, which means that now the amount of a transaction will also be private What do you mean it will be private ? Isn't it already private (with mixin) ? Am I wrong or are Confidential Transaction more obscure than current implementation ? Amounts of transactions are not hidden. http://moneroblocks.eu/Mixin doesn't hide amount of transactions, it hides the source. However, amounts are somewhat hidden by change. A small amount of work has been done to improve how the wallet constructs transactions to improve the ambiguity of amounts and some more work has been done to come up with methods to improve that. They may or may not be made obsolete by RingCT though.
|
|
|
|
Hueristic
Legendary
Offline
Activity: 3976
Merit: 5411
Doomed to see the future and unable to prevent it
|
|
December 03, 2015, 07:50:54 PM |
|
Ring-confidential transactions will also be in the development branch at some point, which means that now the amount of a transaction will also be private What do you mean it will be private ? Isn't it already private (with mixin) ? Am I wrong or are Confidential Transaction more obscure than current implementation ? Amounts of transactions are not hidden. http://moneroblocks.eu/Mixin doesn't hide amount of transactions, it hides the source. However, amounts are somewhat hidden by change. A small amount of work has been done to improve how the wallet constructs transactions to improve the ambiguity of amounts and some more work has been done to come up with methods to improve that. They may or may not be made obsolete by RingCT though. Thx for the more in depth explanation, I added to my post above. Maybe you could answer that for me?
|
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
|
|
|
dEBRUYNE
Legendary
Offline
Activity: 2268
Merit: 1141
|
|
December 03, 2015, 08:20:46 PM |
|
Ring-confidential transactions will also be in the development branch at some point, which means that now the amount of a transaction will also be private What do you mean it will be private ? Isn't it already private (with mixin) ? Am I wrong or are Confidential Transaction more obscure than current implementation ? Amounts of transactions are not hidden. http://moneroblocks.eu/...
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? See this particular commit -> https://github.com/monero-project/bitmonero/commit/0a4bc84b2f681dfd89b501648f65a951d876e2d8Basically, Shen Noether included the reference code used by Bernstein et. al. ( http://ed25519.cr.yp.to/ed25519-20110926.pdf)
|
|
|
|
dEBRUYNE
Legendary
Offline
Activity: 2268
Merit: 1141
|
|
December 03, 2015, 08:23:32 PM |
|
Hi GingerAle, Thanks for your summary. Two things I don't quite understand. Blocktimes will also be changed to 2 minutes in order to try and fix the amount of reorgs that occur. What are reorgs ? Ring-confidential transactions will also be in the development branch at some point, which means that now the amount of a transaction will also be private What do you mean it will be private ? Isn't it already private (with mixin) ? Am I wrong or are Confidential Transaction more obscure than current implementation ? Here is an ELI5 for if it's not clear for you after reading the other comments: ELI5: Next to hidden origins and destinations that are inherent to the Monero protocol (provided by ring signatures + stealth addresses), this will also hide amounts, while viewkeys will still work, and of course it will still be auditable.
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
December 03, 2015, 08:44:48 PM Last edit: December 03, 2015, 11:17:39 PM by smooth |
|
...
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.
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
December 03, 2015, 10:00:40 PM |
|
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".
|
|
|
|
|