Sure, but by the same token there are ways to deal with so-called orphan blocks and to reduce miner centralisation (eg. p2pool, Monero's Smart Mining), and improvements both on the hardware and software side are reducing latency on an ongoing basis. Thus your statement is orthogonal both to the point of the paper and to the point I was making. What perl said is factually incorrect and misleading, I corrected that.

Ah - I didn't realise it was a RPi II inside the BitSeed. Oh well.

If we group buy @ 100 units then it comes down to $120 each, which is somewhat more attractive, although I doubt we'd be able to do so before May 10 (for the free 250gb hard drive upgrade) so the units would have 160gb drives.

I'm torn, I actually think it might be quite cool, and I'd be in for 10 units, but whether we can drum up enough support to hit 100 units I dunno.

This might be a job for the FFS (forum funding system)...which, if all goes well, we're deploying tonight:)

You'll excuse me posting in English, but this is absolutely incorrect, nearly to the point of being purposely disingenuous.

Meni Rosenfeld's paper, "Analysis of hashrate-based double-spending", demonstrates that it is not the amount of clock time that has passed that makes it secure, but the number of consecutive blocks. To quote from section 5 of that paper:


So 30 confirmations is FAR, FAR more secure than 3 confirmations, regardless of the block time target, for an attacker that controls the same % of the hashrate for the respective coins he's attacking.

There are other arguments to be made for increasing our block time, the number of confirmations required for security isn't it.

If anyone wants to discuss this more I'll be speaking in Paris (in English;) in two weeks time: http://www.meetup.com/Paris-Bitcoin-Meetup/events/222290717/

The Mac thing is a little deeper/weirder than that. Here's what I mean:


[ ric->lmdb ]$ ruby
File.open('bigassfile_DELETE_ME', 'w') do |f|
    f.seek(1000000000)
    f.puts('l')
end
[ ric->lmdb ]$ ls -lh
total 14107248
-rw-r--r--  1 ric  staff   954M May  7 16:24 bigassfile_DELETE_ME
-rw-r--r--  1 ric  staff   5.8G May  7 16:23 data.mdb
-rw-r--r--  1 ric  staff   8.0K May  7 09:27 lock.mdb


In other words, the leading nulls in the 1gb file count as actual data (whereas ext2 and above would let you use that space and would only allocate blocks as needed). However, as you can see, the LMDB file doesn't have the full 16gb allocated, which (I would imagine) is the OS X VFS handling the sparse file abstraction.

So basically what happens is we let LMDB pre-allocate 16gb for the blockchain, and then we'll add in a function to automatically pre-allocate more as needed. This is great on every OS that has sparse file support, as the size on disk will only be like 5gb (ie. the bit with actual data). However, it appears that on some flavours of Windows, or some Windows environments, that it takes up the full 16gb on disk. We're currently working on a more efficient pre-allocation system that will preallocate an additional 1gb once there is < 500mb preallocation available, as that should be fast enough for the foreseeable future whilst solving the pre-allocation Windows issue.

It's not non-dev posts, my trollbeads post got removed too. I sent a message to the moderator of this section to find out why, and he pointed to this thread: https://bitcointalk.org/index.php?topic=703657.0

We're continuing to add functionality to the Monero forum (recently we added @username highlighting) so the conversation will evolve there.

We've been most successful with 1000 on Windows, which is probably what we'll set the default as.

Nobody said it would be merged into production last January, that would be impossible as Monero only launched last April. I think you might be confusing this with some other project?

At any rate, here is where it got merged into "production" (we call github "staging") - https://github.com/monero-project/bitmonero/pull/256

Your deep and everlasting affection for fluffy ponies?

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.

The "dev" who launched Monero is thankful_for_today: https://bitcointalk.org/index.php?action=profile;u=233561

Thankfully when we (the current Monero core team) found the purposefully obfuscated code we immediately fixed it and made the fix freely available to all. This is what smooth means when he describes the Monero launch as fair. As dga says, at most thankful_for_today would've had a week of advantageous mining, but as our difficulty retargetting worked just fine and we didn't have crazy high initial block rewards there was very little that the scammer thankful_for_today could've made off with.

Note that these are all facts, directly observable by comparing increases in difficulty (ie. network hash rate) with the improved hashing code submitted to github. It does not require trust, it does not require anyone to take our word that coins have been sold or distributed, it is not based on hope. It is absolute, truthful, factual, verifiable by all.

We could have kept the fix to ourselves and just mined away, amassing a fat stash of XMR. We were under no obligation to release the code for a faster miner, we weren't even in a position of stewardship of the Monero project, we were just a bunch of enthusiasts. If we'd mined for a year with the improved miner we could easily have controlled 90% of the hash rate between us (the improved miner was 12x faster than the original) and mined several million XMR. We could've thrown a flashy GUI together, made wild promises of all sorts of stuff we were going to create (with screenshots) and slowly dumped our stash on an overexcited market.

The 7 members of the Monero core team could be USD millionaires today if we had done that. If I had to throw some numbers out, we'd probably have been able to accumulate around 5.5 million XMR, so 785 000 XMR each. At the current spot price thats only $345 000 for each of us, but since we'd be pumping out screenshots and other flashy nonsense I'm sure we'd be trading over 0.01 BTC, which would put our stash at a cool $1.73 million for each of us (and the total stash would be worth $12 million).

Something to think about.

These are lies fabricated by the Pizzacoin dev. We are innocent in pizzagate! I did not have slices of that pizza, Margherita Lewinski.

It's always good to compare like-for-like, so let's look at the first 48 hours:

Did you seriously edit a stock vector art preview??

Inspired by Otoh's brave example, I also have decided to sell all my XMR. I use the Dark Theme on Poloniex because I'm cool. As you can see, this is me selling everything. As you can see from the screenshot I'm selling my 192382374923412.203874 XMR for 384782064260.56750488 BTC (around $86.19 trillion). Hopefully the market can sustain this dump.



In future I look forward to teleporting you all to my private island on the planet Neptune, where we can fly our hovercars around and laugh about the good ol' days.

Edit: fixed for the luigis

Not you, it's me - I don't know what I meant to put in brackets, but "an hour and a bit" wasn't what I meant:)

In any case it's nonsensical of me to compare block to block, as we have different block times. A better comparison is on the first 48 hours of launch.

The first 5 056 blocks of Dash bring us to the 48 hour mark. This means the average block time for that period was just over 34 seconds, vs. the 2.5 minutes it is today. At the end of the first two days 2 020 652 Dash had been mined. That's 38% of the total Dash in existence today, and 9.18% of all Dash that will ever exist.

The equivalent for Monero is the first 3 037 blocks, which brings us to the 48 hour mark. This means the average block time for that period was just 56.9 seconds, vs. the 60 seconds it is today. At the end of the first two days 53 350 Monero had been mined. That's 0.72% of the total Monero in existence today. As we have infinite tail emission it the actual % it represents tends towards zero, but if we want to take the initial 18 446 744 XMR as a base value (because minimum block reward takes 7.5 years to kick in) then it represents 0.29% of that initial emission.

Welcome to my ignore list! You are one of two people that has proved so bizarrely retarded that I can no longer stomach reading your puerile vomit without feeling quite ill.

By means of a direct comparison, where Dash's average block reward for the first 4500 blocks was 443 Dash, and 33.5 Dash on average thereafter, let's look at Monero's.

For the first 4500 blocks (like an hour and a bit) the block reward was 17.5 XMR. The average block reward for the 12+ months thereafter is 13.7 XMR.

Do you see the dichotomy?

Another thing I find interesting is that the average block reward for the first 4500 Dash blocks (ie. the first 32.8 hours) is 443 Dash.

The average block reward for the 70 000-odd blocks since then is 33.5 Dash. What an incredible difference!

Truly, the gods must have shined upon those miners, as they simultaneously punished those who perhaps fell ill and didn't check Bitcointalk for a day. It really is clear that this is just a happy accident.