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

If you compress it will get much smaller. There is only about 4 gb of actual data in there.

Part of the issue is exchanges having trouble integrating with their usual systems, workflow, and support. That creates a higher barrier to them even supporting the coin at all. Needing to incorporate DNS into that mix will make the problem worse.

It's a good idea for a value-added feature but not as a basic integration.

Probably wait for someone trustworthy to upload the compressed data.mdb file, extract and drop into the lmdb data folder.

You can compile on your own, or try my compiled binaries posted above. Then run bitmonerod.exe

This will get you everything but the blockchain data file. This file will be posted tonight via mega, and there's some monerian i've been trying to get it to that will also host. Or u can get the current database from getmonero.org and try the converter.

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.

Oh, it's still syncing on my end... at around 270k blockheight so about half way in about a week.

Luckily, for whatever reason, the linux data.mdb works in windows, and the linux data.mdb shows up as ~6 gigs until the windows bitmonero accesses it, and then it turns into 16 gigs (due to what fluffypony called windows not liking sparse files). And then, magically, when either of them are compressed, they go to around 3.5 gigs or something.

Regardless, the best thing would be to sync from scratch, independent of how long it takes, because, you, decentralization nom nom nom.

I'd rather not know.  The Cryptonote Conspiracies' intrigues and mysteries are better left unresolved.   

I'd be more interested in the data file for syncing purposes although at 16gb, not sure who's willing to host.

I'll pbb download it when I get home gingy, thanks.

wow, no takers? I thought "the drooling masses" would be all over this.

I think the bestway to solve this is using openalias, its already decided that we should use payment_id on openalias for setting an payment_id, but its not implemented on simplewallet nor on most famouse webwallet (mymonero), after that implementation it would be east for an exchange like poloniex to create openalias for each user with theyr payment_id, for example, malmen.xmradd.poloniex.com, i can help to implement this (i already have the knowage with http://xmr.link ), but this implementation its needed on the client side first....

I wonder how it relates to the QT wallet that was part of Pebblecoin, does anyone know?

The cryptonote scammers came out with a reference QT GUI wallet

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


Instead of


It is the exact same thing in terms of checksums, validation, etc. except that the second is far more likely to lead to people forgetting it or not understanding it, and also fits worse with the usual workflow of a btc-style coin where people generate new addresses for each customer/invoice/etc., and has a higher support burden. With the first method, you have have the exact same kind of button in an exchange wallet window that says "generate new address" and it can go ahead and generate a new address that happens to share the same prefix, instead of needing something different for "payment-id coins".

We're suffering this unnecessary mismatch from the usual model and confusion because the cryptonote/BCN guys didn't see the need for a payment ID at all in their earlier design at all and threw the payment ID on there later as an extra thing instead of including it in addresses (there are commits in their repo when they added it, so it is clear it was an added patch). If it were part of the original design I bet something more like the prefix-suffix syntax would have been used.

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.

Add another 50.

adding 100XMR to that bounty   

It's relatively simple but there are some complications. For example, a single transaction can send to mulitple addresses but it can only have one payment ID. So that case (where the user specifies multiple compound addresses containing different payment IDs) would need to be detected and handled.

If someone is looking for a small project to get started with coding for Monero this could be a good one, especially with the bounty that is offered.

I'm not familiar enough with the codebase to do it myself, but if it's a simple task I'll throw 100 xmr to whoever can get it in.