(actually about 3.25x) I agree and think that's not a bad target short term. I'm trying to present it in opposition to the argument (whether anyone actually presented said argument directly) that LTC's daily influx could support much higher prices.

No you are correct on absolute numbers of coins emitted, I was referring to inflation figures (which ARE relevant, but we can argue HOW relevant ).

However, given LTC's numbers, it could only support an XMR price of about .014! 0.0105*(28,000/21,000)

Edit: forgive my fail formula (which smooth quoted next page). Number was correct, formula not.

Combining posts...

Basically the argument is that "bunch of coins mined over a few months to a year" = more participants than "bunch of coins mined in a few days", which should lead to better distribution as well as much better perception. It's only one piece of the distribution schedule, but it is largely responsible for public perception (and XMR can get negative perception as well for its defined curve, just that it didn't go way outside of what was defined like DRK did).


It's much much higher than LTC presently, but that's not really the point I guess. LTC isn't $100 after all.


This is kinda nonsense, as you are pretty apparently comparing to DRK (at 50% of current supply, which isn't even true anymore), but their community (of which I am a part as well) is quite big and active. They have the longest thread in the entire altcoin section. The other part of it is, absolutely some people got XMR at super cheap prices. I was one of them.

You are spot on about fast emission keeping price relatively low for early adopters/accumulators.

I think the price "hurts" longer, which arguably benefits accumulators more.

This definition could vary a bunch. DRK was obviously VERY fast (but only about 10% of the longer term supply), XMR is just "fast" with 50% in two years. Its supply will certainly outpace DRK's sometime next year.

So you could argue XMR's distribution is faster, however DRK has to contend with major accusations that never cease from those fateful first 24 hours. I think the present price would be much higher if that hadn't occurred.

Definitely something to consider. XMR does have a rather rapid, smooth (get it?) distribution, so inflation is constantly and rapidly slowing down.


So take the emission, imagine what you think daily influx could be, calculate expected price, and decide if it's attractive relative to current prices.

Right, it's just market prices, thus my confusion.

As for speculation, I think we're in the right place!

I agree with your conclusions, but I don't think we're using "my" numbers. I was trying to point out that a "mere" 1000x isn't hard to imagine. You provided the "wide adoption" numbers as far as I can tell (I somewhat implied 4x current BTC value would be the absolute baseline for such a thing, but am in agreement the real value would be much higher).

Bitcoin is not widely adopted and yet is 250x XMR. 1000x isn't hard at all to imagine given "wide adoption".

Nice sig.

I'm rather surprised the price isn't more pumped with all the interest it's been getting.

It seems to me to be a bigger rat race than even regular POW, so I'm not sure how I feel about it yet.

Do tell how a rich list would work in an untraceable currency?

That said, you have ~1.3% of current supply. I'd argue whale.

Am I missing something here? Where is such an "announcement" stored? A masternode can only sign its ping with its provided private key, which has no relation to a DRK address holding 1k except via signed message by the actual address giving authority for said masternode key to act on its behalf.

Perhaps the solution is to have additional space in the blockchain for storing these messages (this is what you were thinking all along, isn't it (you're a genius!))? They'd exist for all eternity unless pruned at some point in the future (though that would need some workaround to keep the blocks paying them in the past valid when the evidence of their being a masternode is removed), but I'm not sure that matters... You would actually be able to make a "list" of sorts then based on the messages in the blockchain, but it wouldn't vary at all from node to node! Assume the same address could initiate a stop command in a future block to not have his old MN clutter up the payments by never responding. However, I don't see any incentive for people to do this, so there needs to be some mechanism where the block finder can insert the stop message on behalf of the masternode. You might think the lingering nodes wouldn't be an issue, but something absolutely has to be able to issue a "stop" command in case the 1,000 DRK move. Unless you could possibly modify the protocol to have nodes reject any tx formed out of the 1,000 DRK input without a "masternode stop" command included in a prior block? If you allow for removal after X number of missed pings, you have the (tiny) vector of the block finder being able to remove a masternode if he found the right blocks, but I don't know of any incentive to do this.

Now we're just stuck with n block finder (that happens to have his node in the list of candidates) pretending he didn't get pings from some or all of the other candidates. Perhaps this vector is small enough to just discard.

This is actually sounding like a workable solution! Everyone give it up for baddw! (*crickets*, no one is listening to us banter)

I wrote most of this before fully comprehending what you wrote in your last paragraph, which is basically suggesting the same thing I'm going over, right?

Edit: by "list", I only mean abstractly in the form the blockchain provides/would provide..

Edit2: some typos, also sorry again thread for the huge mess this has become

Edit3: just noticed in a previous post (quoted above) I spelled "naught" as "naut". Subliminal coin advertising, anyone?

Oh. Sorry I wasn't clear. I don't support MS or Apple (support might be a loose term; I own not a single Apple product, but do own some MS products). FLOSS obviously is getting more and more use in all corners. I much prefer Android over iOS (I also don't get the "gaining on" unless you mean people's opinions of it? It is way more widely used than iOS.) and will probably do the same with a Linux flavor for PC in the future (have to support and use MS at work + I like PC games).

I was referring to them making 100s of billions of dollars.

Edit: (below) sorry for off-topic. Let's get back to altcoins.

1. It worked out WAY better for Microsoft and Apple.

2. Now we're talking about "true" worth? What does that even mean? [NTS] Stuff is worth what someone is willing to pay.

I like it. I'm curious how much junk it'd add to blocks with "alive pings", etc. If no MNs matched/pinged from the previous block(s), you could potentially pay a MN that had been offline for a while, but I think that's a relatively minor issue (you couldn't really code it out either, as requiring "re-pinging" would take an extra block, leaving you with no one to pay for the present block).

You still need the old MN list though, for accounting and verification purposes (hot/cold would also be impossible without it). The block finding node needs to verify all the pings are from acceptable masternodes before including them in his block. This seems like it could take us back to old sync problem, BUT since the list wouldn't need to keep track of whether or not the MNs were alive, only that they were capable of existing (i.e., signed message from DRK address with 1,000 input tx designating new MN pubkey), perhaps the sync issue would be mitigated?

That leaves us with the possible conundrum of verification discrepancies. The other nodes have to verify his block against the list or the block finder could include addresses that aren't MNs (his own made up addresses; it shouldn't be hard at all to generate on-the-fly addresses that fit the requirements with 5/1,000 expected to fit). Does the paying block finder (n+2 in your proposal I think) also verify his payee is in the list? He wouldn't need to if all the peers had verified the n block as being valid, but that could potentially bring us the forking problem again. I think he should, particularly if it's a "reused block", but his peers don't need to/shouldn't; more below (sorry this is getting kind of scattered).


I think there are compromises that could make it more than acceptable. Consider: what if there are "allowances" in the "ping" block to cover potential discrepancies in the list? Like 75% or so of the included pings must exist in the list or peers would reject it. Something like that should make potential forks from list discrepancies very rare at worst, non-existent at best. Then, at block n+2, the payer could again verify his payee is in the list (so he doesn't pay the "naughty" address the n finder included to try to pay himself), but his peers wouldn't (obviously payee must be from block n), avoiding forks over list discrepancies there! Additionally, in the case of a "rerun", the payer would be able to check his payee is still a valid node.

For this to work, the payee wouldn't be deterministic, but chosen at random from n by n+2 block finder. He could of course pay himself, but only if he was in the list to start with (so it seems very marginally beneficial to him). The other consideration is that if "Pool A" found both n and n+2, he could get away with paying whoever, but that seems minor to me again (others might disagree).


Thoughts? Perhaps an MN list without the "alive" state included would be stable enough so as to not cause many (if any) discrepancies and thus forks, and all my thinking is for naut? (It's fun following these trains of thought regardless though )

Edit: sorry for WoT folks; baddw and I are just out on the playground here.

1. This seems incredibly naive to me, to be a dev you must be all philanthropy? Nary a hope of supporting yourself with your work? People don't really donate in meaningful capacities here. Even XMR, the altcoin that has more "bitcoiners" interested than any other, is struggling for donations (the people doing the coding generally don't work for free). Check out miner developers: they make orders of magnitude more keeping their miners closed and/or private because no one donates anything meaningful.

Even if all they wanted to do was give away their time and "help people", it'd arguably be better for them to behave the same as before and donate their earnings to projects they feel are worthwhile, rather than giving it away for free to all the crypto-community and letting them keep the profits. Are you giving away your mining earnings? Market appreciation earnings?

2. Interesting sentiment. The market doesn't agree with you though.

Well as fate would have it, I didn't dream about this at all...

It seems to me that the distribution of masternode public keys is probably not very uniform, and therefore a (pseudo) random matching based on block hashes could result in rather uneven payments? It may be possible to mitigate this, though not 100% sure. Perhaps some additional variables in the matching algorithm could help. If it can be structured in a way to get a reasonably normal distribution, then it's actually rather elegant.
One other consideration is that it'd still be highly probable that producing an output not matching any MNs is possible. Do we just say "too bad" for those ineligible blocks?

Will think about this as I dream tonight, and respond in the morning!

1. I believe this should have been a fairly easy "enforcement" switch to code, but in reality wouldn't have done too much. I believe the cause of the forking to have been nodes thinking different MNs should be paid, and rejecting the blocks that paid, but didn't pay the "right" node. However, just making so 20% had to be split off or the block rejected would allow the miner to just pay themselves in a separate transaction.

I think you have an interesting idea in doing that PoSvc thing (which I believe "flare" has talked about at dct): you should be able to determine which masternode signed each denomination transaction included in the block.

It sounds very cool and elegant at first, but it too has vectors that must be considered. Nothing stops you from choosing a masternode; they just sit around waiting for inputs. So you could constantly denominate the smallest # of inputs (to minimize fees) using your own node, which would nearly guarantee its inclusion in every block for payment. This only wouldn't make sense if fees were higher than the payout.

Additionally, what happens if no denominate transaction occurs in a particular block? Is the mining node then able to keep the entire reward for himself? What then happens if he simply refused to include those transactions in his block (I'm not sure how you can force them to include transactions?).

Several other ideas are rolling around in my head, mostly in relation to masternodes somehow/sometimes having block minting authority. I need to think about it some more though.

I don't believe enforcement was ever difficult to implement, I think the problems resulted from the payment/election code sometimes causing different nodes to believe different masternodes should be paid. So when enforcement was switched on (via hard fork), little forks started emerging because there wasn't consensus.

That is what I understand to have been happening; could've been something else though.