|
|
nioc
Legendary
Offline
Activity: 1624
Merit: 1008
|
|
April 30, 2015, 04:52:46 PM |
|
WARNING - these are not "official", as in, someone from the core dev team didn't compile them and gave them the a-ok. I'm putting them here for testing purposes. I compiled following the instructions on the github. Perhaps they are static? Perhaps you can run the LMDB version of bitmonerod on your win 64 box and only use 50 megs of ram? https://mega.co.nz/#!5YNACDTJ!N0pIow27_Tfsx4dMfMq4HA11ZSlEt7L135HvYEOuBU8 perhaps you can swap in the relevant .exe files from the above into the /resources/software/ folder of MoneroX you can have a monero GUI on windows 64 that sips RAM like a fine wine? AGAIN - don't trust these. Test them until you trust them. Make sure they do everything they should do. I tested them on the box I compiled on and another windows 7 box. Hopefully someone will post the data.mdb download link. ( removed the converter thing) wow, no takers? I thought "the drooling masses" would be all over this. Did I hear my name? I'm on a break at work now but will be off for the next 2 days. If you will be available to help then you can experience first hand what being a member of the drooling masses truly is
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
April 30, 2015, 04:55:30 PM |
|
Maybe, I don't know. It's kind of a boring Bitcoin-Qt clone like every other coin cloned from Bitcoin/Litecoin has. Not sure how much value it adds when we already have MoneroX and a bunch of other GUIs. The rest of your post was off topic here. Please be respectful to forum users and don't do that.
|
|
|
|
GingerAle
Legendary
Offline
Activity: 1260
Merit: 1008
|
|
April 30, 2015, 05:00:26 PM |
|
Ok, now that I found it, I scanned the code of each the Cryptonote coin and the current monero core code, and it looks like one has some HTML-type stuff and the other is something else. Here, my knowledge of the interworkings fails me.
I know in the past it has been suggested that an HTML wallet is ,....... undesirable? I don't understand why. Perhaps this could be the focus of the next Missive.
Don't get me wrong - I'm glad to see cryptonote development in general (hooray opaque blockchains), im just curious.
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
April 30, 2015, 05:07:24 PM |
|
Ok, now that I found it, I scanned the code of each the Cryptonote coin and the current monero core code, and it looks like one has some HTML-type stuff and the other is something else. Here, my knowledge of the interworkings fails me.
I know in the past it has been suggested that an HTML wallet is ,....... undesirable? I don't understand why. Perhaps this could be the focus of the next Missive.
Don't get me wrong - I'm glad to see cryptonote development in general (hooray opaque blockchains), im just curious.
Boolberry has an html-based wallet. I don't know for sure, there might be other ones.
|
|
|
|
btc-mike
|
|
April 30, 2015, 05:13:25 PM |
|
Someone made a GUI for CryptoNote coins...
Well... Is CZ coding for the CN crew? He did all his development in OSX.
|
|
|
|
luigi1111
Legendary
Offline
Activity: 1105
Merit: 1000
|
|
April 30, 2015, 06:42:51 PM |
|
I don't remember who stated it above, but I do agree that the lack of exchange/merchant adoption might have something to do with the hassle of depending on users to include payment IDs.
Pay ID serialisation into the receiving address looks pretty far down on the roadmap. In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client? That would make it much easier for third parties to manage payments until "stealth" payment IDs eventually get implemented.
No checksum is one reason why this will potentially backfire. That and the payment ID space is unnecessarily huge. I'll take a look at my notes from the MRL meetup in November last year, we had some ideas about fixing the payment ID format and serialising it, there may be a quick win to be had whilst we chip away at the stealth payment IDs. I disagree that we need to do nothing while we work on something better (obviously one does not preclude the other at all). There is no checksum now. The length and valid characters are checked but that's it. The exact same thing can still be checked if the format is changed, slightly to something like Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em-e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac Instead of Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em
and use this payment ID
e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac
Adding the payment ID with checksum seems fairly simple. I went and created a test address just now: Standard Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byMUKoz6m Payment ID: feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed Integrated Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byXSb563RKvyBgorjsFGwyx9gorjsFGwyx9gorjsFGwyx9TpPbbCy What I did: Instead of the standard hex format - ('12' network byte) + (public spend key 64 digits) + (public view key 64 digits) + (checksum 8 digits) - I stripped the checksum and appended the payment ID, then recalculated and appended the new checksum. This creates a 101 byte address instead of the standard 69 byte, and 139 "Public Address" characters vs 95 standard. cnBase58 --> hex the above "Integrated Address" and you get (separated for clarity): 12 55a1e49673f5a8faa6ba4f942585695ceee5c7522496be6fc38d3f09905e3f8b ca6313deac11aff9a7241e7095863b0be3099d50d7a0cd11e0adbcf4990e64b5 feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed b1d0950e The code just needs to check for length to determine the type. Alternatively, (I don't know what all the other cryptonotes are using) the network byte could be changed to 0x13 or something for the "Integrated Address".
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
April 30, 2015, 06:50:23 PM |
|
I don't remember who stated it above, but I do agree that the lack of exchange/merchant adoption might have something to do with the hassle of depending on users to include payment IDs.
Pay ID serialisation into the receiving address looks pretty far down on the roadmap. In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client? That would make it much easier for third parties to manage payments until "stealth" payment IDs eventually get implemented.
No checksum is one reason why this will potentially backfire. That and the payment ID space is unnecessarily huge. I'll take a look at my notes from the MRL meetup in November last year, we had some ideas about fixing the payment ID format and serialising it, there may be a quick win to be had whilst we chip away at the stealth payment IDs. I disagree that we need to do nothing while we work on something better (obviously one does not preclude the other at all). There is no checksum now. The length and valid characters are checked but that's it. The exact same thing can still be checked if the format is changed, slightly to something like Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em-e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac Instead of Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em
and use this payment ID
e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac
Adding the payment ID with checksum seems fairly simple. I went and created a test address just now: Standard Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byMUKoz6m Payment ID: feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed Integrated Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byXSb563RKvyBgorjsFGwyx9gorjsFGwyx9gorjsFGwyx9TpPbbCy What I did: Instead of the standard hex format - ('12' network byte) + (public spend key 64 digits) + (public view key 64 digits) + (checksum 8 digits) - I stripped the checksum and appended the payment ID, then recalculated and appended the new checksum. This creates a 101 byte address instead of the standard 69 byte, and 139 "Public Address" characters vs 95 standard. cnBase58 --> hex the above "Integrated Address" and you get (separated for clarity): 12 55a1e49673f5a8faa6ba4f942585695ceee5c7522496be6fc38d3f09905e3f8b ca6313deac11aff9a7241e7095863b0be3099d50d7a0cd11e0adbcf4990e64b5 feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed b1d0950e The code just needs to check for length to determine the type. Alternatively, (I don't know what all the other cryptonotes are using) the network byte could be changed to 0x13 or something for the "Integrated Address". Looks very nice. Something like this seems like the way to go, especially in that it can be recognized as a different address type. You can shorten the pid (and the whole thing) by converting it to base58 instead of hex.
|
|
|
|
papa_lazzarou
|
|
April 30, 2015, 06:54:51 PM |
|
So, as a Windows user, what is my guidance on getting the database version going on my computer?
I will be downloading the database blockchain in its entirety.
Thanks.
Probably wait for someone trustworthy to upload the compressed data.mdb file, extract and drop into the lmdb data folder. Am I trustworthy? https://mega.nz/#!zoInGDjR!EDJaD6IxgdAfhtwFAnJ4BTlrRMOZ4vSYvxaFUcQfSiE This has 10GB gziped. It has been running for a while so its 16GB unpacked. Linux 64bit.
|
|
|
|
|
GingerAle
Legendary
Offline
Activity: 1260
Merit: 1008
|
|
April 30, 2015, 07:08:44 PM |
|
So, as a Windows user, what is my guidance on getting the database version going on my computer?
I will be downloading the database blockchain in its entirety.
Thanks.
Probably wait for someone trustworthy to upload the compressed data.mdb file, extract and drop into the lmdb data folder. Am I trustworthy? https://mega.nz/#!zoInGDjR!EDJaD6IxgdAfhtwFAnJ4BTlrRMOZ4vSYvxaFUcQfSiE This has 10GB gziped. It has been running for a while so its 16GB unpacked. Linux 64bit. This the LMDB or the in-memory? weird why its so big.
|
|
|
|
MalMen
Member
Offline
Activity: 95
Merit: 10
|
|
April 30, 2015, 07:34:08 PM |
|
This the LMDB or the in-memory? weird why its so big.
Should be the raw i think
|
|
|
|
othe
|
|
April 30, 2015, 07:51:57 PM |
|
Someone made a GUI for CryptoNote coins...
Well... Is CZ coding for the CN crew? He did all his development in OSX. No, It´s the Bitcoin-QT gui, just adapted, thats neither his style nor would he not even give credit to Bitcoin like they did. And Blockafett, there are already TONS of gui´s for monero, nfi why you are so obsessed with them tho... Oh even a Web/Mobile wallet - oh wait there´s no Web/Mobile wallet that supports darksend, nor do i think it´s even practical todo, maybe you should invest your time doing one? Because we are clearly already sorted here when it comes to that. heres another one for xmr. currently done by antanst.
|
|
|
|
papa_lazzarou
|
|
April 30, 2015, 08:17:32 PM |
|
So, as a Windows user, what is my guidance on getting the database version going on my computer?
I will be downloading the database blockchain in its entirety.
Thanks.
Probably wait for someone trustworthy to upload the compressed data.mdb file, extract and drop into the lmdb data folder. Am I trustworthy? https://mega.nz/#!zoInGDjR!EDJaD6IxgdAfhtwFAnJ4BTlrRMOZ4vSYvxaFUcQfSiE This has 10GB gziped. It has been running for a while so its 16GB unpacked. Linux 64bit. This the LMDB or the in-memory? weird why its so big. Its the lmdb data file. I dunno why it is so big. moneroblocks's data file is currently at 11GB for example. This one has been running for a longer time. Also, this is from tewinget's blockchain branch. I assume they are compatible.
|
|
|
|
luigi1111
Legendary
Offline
Activity: 1105
Merit: 1000
|
|
April 30, 2015, 08:18:16 PM |
|
I don't remember who stated it above, but I do agree that the lack of exchange/merchant adoption might have something to do with the hassle of depending on users to include payment IDs.
Pay ID serialisation into the receiving address looks pretty far down on the roadmap. In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client? That would make it much easier for third parties to manage payments until "stealth" payment IDs eventually get implemented.
No checksum is one reason why this will potentially backfire. That and the payment ID space is unnecessarily huge. I'll take a look at my notes from the MRL meetup in November last year, we had some ideas about fixing the payment ID format and serialising it, there may be a quick win to be had whilst we chip away at the stealth payment IDs. <snip> Adding the payment ID with checksum seems fairly simple. I went and created a test address just now: Standard Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byMUKoz6m Payment ID: feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed Integrated Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byXSb563RKvyBgorjsFGwyx9gorjsFGwyx9gorjsFGwyx9TpPbbCy What I did: Instead of the standard hex format - ('12' network byte) + (public spend key 64 digits) + (public view key 64 digits) + (checksum 8 digits) - I stripped the checksum and appended the payment ID, then recalculated and appended the new checksum. This creates a 101 byte address instead of the standard 69 byte, and 139 "Public Address" characters vs 95 standard. cnBase58 --> hex the above "Integrated Address" and you get (separated for clarity): 12 55a1e49673f5a8faa6ba4f942585695ceee5c7522496be6fc38d3f09905e3f8b ca6313deac11aff9a7241e7095863b0be3099d50d7a0cd11e0adbcf4990e64b5 feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed b1d0950e The code just needs to check for length to determine the type. Alternatively, (I don't know what all the other cryptonotes are using) the network byte could be changed to 0x13 or something for the "Integrated Address". Looks very nice. Something like this seems like the way to go, especially in that it can be recognized as a different address type. You can shorten the pid (and the whole thing) by converting it to base58 instead of hex. Thanks. On your last sentence, I'm not sure if I was clear: the base58 version is above in the code section "Integrated Address". That would be the version you'd actually use. The hex version at the bottom was for explanation only.
|
|
|
|
Johnny Mnemonic
|
|
April 30, 2015, 08:31:03 PM |
|
Adding the payment ID with checksum seems fairly simple. I went and created a test address just now: Standard Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byMUKoz6m Payment ID: feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed Integrated Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byXSb563RKvyBgorjsFGwyx9gorjsFGwyx9gorjsFGwyx9TpPbbCy What I did: Instead of the standard hex format - ('12' network byte) + (public spend key 64 digits) + (public view key 64 digits) + (checksum 8 digits) - I stripped the checksum and appended the payment ID, then recalculated and appended the new checksum. This creates a 101 byte address instead of the standard 69 byte, and 139 "Public Address" characters vs 95 standard. cnBase58 --> hex the above "Integrated Address" and you get (separated for clarity): 12 55a1e49673f5a8faa6ba4f942585695ceee5c7522496be6fc38d3f09905e3f8b ca6313deac11aff9a7241e7095863b0be3099d50d7a0cd11e0adbcf4990e64b5 feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed b1d0950e The code just needs to check for length to determine the type. Alternatively, (I don't know what all the other cryptonotes are using) the network byte could be changed to 0x13 or something for the "Integrated Address". That's awesome. I feel like address length wont matter much anyway with increased QR code usage.
|
|
|
|
oblox
Legendary
Offline
Activity: 1442
Merit: 1018
|
|
April 30, 2015, 09:02:03 PM |
|
I always chuckle with people trying to sell their domains on here, especially for outrages sums. Without any traffic, they're literally worth the $5-$12/ea. for registration. But good luck to the squatters.
|
|
|
|
GTO911
|
|
April 30, 2015, 09:04:53 PM |
|
$480 is not an outrageous sum, especially for xmr.in or Monero.in, you can easily make that money by starting an alias service
|
|
|
|
oblox
Legendary
Offline
Activity: 1442
Merit: 1018
|
|
April 30, 2015, 09:13:32 PM |
|
$480 is not an outrageous sum, especially for xmr.in or Monero.in, you can easily make that money by starting an alias service
Your group is more reasonable than some I see but still not worth the premium for no traffic generated and no services/content. Good luck selling them though.
|
|
|
|
|