[XMR] Monero Speculation

[medusa13]

I'm a small fish compared to a lot of you and it's also weird to see that my bids are >10% of the whole bid side, I try my best to increase the liquidity a bit and hopefully earning some BTC/XMR along the way, it would be great if more people would do this, even with small amounts.

in the past many of us did it, we parked every coin we didnt use on the bids. but then polo changed and many of us refused to register with their passports, so it became difficult to get bigger money out of polo.
ever tried to withdrawl 10k with a daily 2k limit? its not fun i tell you, i do not have time for this, so i dont do it at all. this is very sad, but it  does not exclude me as a buyer. i am just not able to support the bids like i was used to, but i still buy if price is right.

i am also sacred to deposit big amounts with my 2k withdrawl limit. maybe they will just freeze my account one day and wait for more info since they see me trading big amounts but only withdrawl 2k per day....no no no, way too risky i am sorry.

i do not trust them

[1714806462]

1714806462

[1714806462]

1714806462

[1714806462]

1714806462

[1714806462]

1714806462

[ArticMine]

The advantage that Monero currently has over virtually every POW coin and this includes Bitcoin, is that Monero has a current working solution to the scaling of blocksize question. One needs two things 1) Adaptive limits 2) A tail emission. Solving this problem without a tail emission is far from obvious, In fact I am not even convinced one can even create a viable fee market in the absence of an emission. There is a reason why there is so little progress with the blocksize debate in Bitcoin.

It sounds like you're saying that it's impossible to solve the blocksize limit without having a tail emission.  If that is what you're saying, will you elaborate please?  
  
I do understand that both of those are advantages that Monero has to bitcoin and I think they will play more of a factor going forward.  
  
Also, do you think that Satoshi believed bitcoin could work with transaction-fee only mining and as a deflationary asset... or was it intentionally crippled from the beginning?

I will elaborate on this.

The first question one needs to ask before even considering adaptive blocksize limits is: Can a fee market actually work in the absence of a base emission?

1) We first consider a blocksize large enough (or effectively infinite). In this scenario competition among miners will drive fees towards zero since there is no scarcity. This will in turn cause the difficulty and consequently the security of the crypto currency to collapse. We must keep in mind that orphan block based arguments will also fail since these are based on the presence of a base emission. This is in fact the very legitimate fear of the small block proponents.

2) In the second case we consider a fixed blocksize, where the blocksize is small enough to impact fees. In this scenario we have a potentially infinite demand with a fixed supply. In theory fees therefore would go to infinity. We must keep in mind that as the legitimate demand rises towards the fixed limit, It becomes economically attractive for miners with a even small percentage of the hash rate to spam the network in order to profit by raising the overall fees.  At this point only external competitive factors can stop the fees from rising to infinity. These take the form of fiat payment methods and other crypto currencies with the latter being not affected by a fixed blocksize limit. The impact of these external competitive factors is to reduce demand by devaluing the entire crypto currency. This will be delayed by miner spam, as miners will increase the spam in order to preserve the dwindling purchasing power of their fees until the system collapses to little or no transaction demand leading the first case above.

The problem as I see it is that the system is inherently unstable. Either the mining revenue collapses first or the purchasing power of the mining revenue collapses first. We now come to the next question. Can one create an adaptive blocksize limit formula that does not converge as time increases towards (1) or (2) above? My instinct tells me no, particularly since the network has no way to measure the key parameter namely the amount of fees collected per block due to out of bound payments to miners. Furthermore there have been many brilliant minds looking at this issue and they have not come up with a solution. Proving this negative, in a rigorous mathematical sense, is of course another matter entirely.

What the tail emission in Monero does is provide a stable anchor outside of the control of the miners on top of which an adaptive blocksize limit and a fee market can actually develop, by avoiding the instability above.

One final note. Why is this posted in the Monero speculation thread? The answer is very simple: Monero is the other crypto currency with the latter being not affected by a fixed blocksize limit above. In the collapsing valuation of (2) the valuation has to go somewhere and there a good possibility that Monero will capture some of this valuation.

[TrueCryptonaire]

I have purchased over 15 K XMR today.

If you start selling, I will intensify my buying.
I am working hard again to increase the market cap of Monero and to make it more appealing speculative asset. I hope there are others who think the same way and are also interested in making money rather than lose it.  

I have so many Moneros currently that it is in my best interest to increase the market cap. 

[Melbustus]

...
1) ... We must keep in mind that orphan block based arguments will also fail since these are based on the presence of a base emission.
...

As I noted a page or two ago, I see this result in Peter R's paper, but I don't intuitively understand it. Do you? Why is orphan risk any different whether the source of a miner's revenue is a coinbase transaction in a given block vs fees from transactions in a given block?

[smooth]

...
1) ... We must keep in mind that orphan block based arguments will also fail since these are based on the presence of a base emission.
...

As I noted a page or two ago, I see this result in Peter R's paper, but I don't intuitively understand it

It is easy to understand. The cost you incur for including another transaction and potentially having your block orphaned is losing the reward, measured against the benefit of another transaction fee. You can try to construct something based on the cost being losing the transaction fee but it becomes a snake eating its own tail.

Also, consider the very first transaction you might add to a block. There is absolutely no downside to adding it even if you gain nothing at all (no reward or previous transaction fees to lose). If a fee market works, it has to work for every single transaction in a block, including the first one.

[smooth]

Well, the two-birds-one-stone approach to this problem is the subject of my (hopefully forgivable) crusade - to prevent pool mining. If you stop pool mining, you remove the "mining without a node" option. So, miners *have* to run nodes. Thus, if you bring back true solo mining, you bring back incentivizing running a node. Indeed, this was the original model for supporting the network. Pool mining, IMO, is a tragedy of the unregulated commons.

Indeed, I agree. I don't really understand why no coin tried this before.
It wouldn't be that hard to implement I think. You just need to sign your mined block with your private key of the address to where you received the minted coins

Certainly easy in BTC. But also possible with XMR I think.

BBR's Wild Keccak PoW requires a copy of the blockchain, as random bits of it are used in the scratchpad.

That's a huge incentive to run a full node.  No node, no (solo) mining.

No you can just get a small incremental update to your scratchpad on each new block from the pool (that is actually what is done I think). The cost of doing that is so much lower than running a full node it does't provide a huge incentive, instead barely one at all.

[Melbustus]

...
1) ... We must keep in mind that orphan block based arguments will also fail since these are based on the presence of a base emission.
...

As I noted a page or two ago, I see this result in Peter R's paper, but I don't intuitively understand it

It is easy to understand. The cost you incur for including another transaction and potentially having your block orphaned is losing the reward, measured against the benefit of another transaction fee. You can try to construct something based on the cost being losing the transaction fee but it becomes a snake eating its own tail.

Still not seeing how it breaks with no coinbase tx and only fees. The cost of each tx is the extra orphan risk caused by the extra X bytes needed to describe the tx, multiplied by the tx fee included in the tx. How is that not the case?

Now with current block reward, and for the foreseeable future, coinbase rewards will be much higher than avg fees, so the cost of orphaning a block is mostly going to be associated with that coinbase tx. But ultimately, why is the above invalid? There's *still* some cost to adding a tx to a block, so a rational miner will not do so unless the tx includes enough fee to cover that cost (again, the delta on orphan risk due to the additional bytes).

Sorry if I'm being thick on this, but I haven't yet seen a sufficient explanation.

Also, consider the very first transaction you might add to a block. There is absolutely no downside to adding it (no reward or previous transaction fees). If a fee market works, it has to work for every single transaction in a block, including the first one.

Put yourself in the shoes of a bitcoin miner in the year 2141 (no block reward). There's demand for transaction confirmations, so you have a mempool with a bunch of transactions which include fees ranging from 0 to some positive number. It takes time for blocks to propagate, and orphan risk increases exponentially with the quantity of data you're transmitting. How do you select which transactions to include?

I'd chart orphan-risk per byte against the sets of transactions I can build and the resultant aggregate blocksizes and fees......Hmmm...that actually feels like it might an NP-complete problem (an instance of the knapsack problem?). Meh, will think about this later. Anyways, there are practical-enough solutions to those problems, even for largish N.

[smooth]

Put yourself in the shoes of a bitcoin miner in the year 2141 (no block reward). There's demand for transaction confirmations, so you have a mempool with a bunch of transactions which include fees ranging from 0 to some positive number. It takes time for blocks to propagate, and orphan risk increases exponentially with the quantity of data you're transmitting. How do you select which transactions to include?

There is no equilibrium where people pay a significant fee. Given a choice between mining an empty block (zero reward) and mining anything else any rational miner will choose "anything else" even if that is a 100 terabyte transaction paying a fee of one satoshi.

You can likewise view a total of one terabytes worth of multiple transactions paying a total fee of 1 satoshi the same way. There is no pricing pressure that would cause people creating transactions to want to pay more.

[TrueCryptonaire]

My fat fingers bought 648 XMR some time ago..... It was accident - I hoped just to nibble a bit and waite until there will be someone willing to sell me lower...

[Melbustus]

Put yourself in the shoes of a bitcoin miner in the year 2141 (no block reward). There's demand for transaction confirmations, so you have a mempool with a bunch of transactions which include fees ranging from 0 to some positive number. It takes time for blocks to propagate, and orphan risk increases exponentially with the quantity of data you're transmitting. How do you select which transactions to include?

There is no equilibrium where people pay a significant fee. Given a choice between mining an empty block (zero reward) and mining anything else any rational miner will choose "anything else" even if that is a 100 terabyte transaction paying a fee of one satoshi.

You can likewise view a total of one terabytes worth of multiple transactions paying a total fee of 1 satoshi the same way. There is no pricing pressure that would cause people creating transactions to want to pay more.

Only in that single edge case. So, ok, if there's basically zero demand for transactions the orphan-risk analysis breaks down. But if the mempool contains more than one fee-containing tx, the orphan risk analysis seems to holds.

So again, put yourself in the shoes of that miner. How would you select transactions? Seems unlikely that you, being rational, would just shove all the transactions in a giant block without making sure that your giant block has a good-enough (relative to the fee-rev you're earning) chance of not being orphaned.

[smooth]

Put yourself in the shoes of a bitcoin miner in the year 2141 (no block reward). There's demand for transaction confirmations, so you have a mempool with a bunch of transactions which include fees ranging from 0 to some positive number. It takes time for blocks to propagate, and orphan risk increases exponentially with the quantity of data you're transmitting. How do you select which transactions to include?

There is no equilibrium where people pay a significant fee. Given a choice between mining an empty block (zero reward) and mining anything else any rational miner will choose "anything else" even if that is a 100 terabyte transaction paying a fee of one satoshi.

You can likewise view a total of one terabytes worth of multiple transactions paying a total fee of 1 satoshi the same way. There is no pricing pressure that would cause people creating transactions to want to pay more.

Only in that single edge case. So, ok, if there's basically zero demand for transactions the orphan-risk analysis breaks down. But if the mempool contains more than one fee-containing tx, the orphan risk analysis seems to holds.

No the mempool doesn't matter, because you still need an incentive for people to pay a non-negligible fee. Let's say the most profitable transaction in the entire pool pays some negligible fee so you include it (better than nothing right?). Then the next transition need only compensate you for the potential loss of your infinitesimal profit on the first transaction, which in turn is even more infinitesimal. Everyone transacting understands this so they understand that the fee needed to get into a block is virtually nothing. Because the fee necessary to get into the block at all is so small, even the highest fee transaction in the entire mempool won't pay a lot (unless someone fat fingers of course). So this all collapses. That's what the math is telling you.

So again, put yourself in the shoes of that miner. How would you select transactions? Seems unlikely that you, being rational, would just shove all the transactions in a giant block without making sure that your giant block has a good-enough (relative to the fee-rev you're earning) chance of not being orphaned.

You're going to choose the combination that gives you the best outcome. People transacting know that and will only pay something extremely negligible, not something that allows you to make a profit and actually consume electricity hashing.

[hodlmybtc]

Was frontrunning Warz' bid, asked him to let me buy 5k first, wall now:



 

[TrueCryptonaire]

Monero looks pretty tight now.
A big sell and big buy wall only less than 5 % spread.

[rpietila]

No the mempool doesn't matter, because you still need an incentive for people to pay a non-negligible fee. Let's say the most profitable transaction in the entire pool pays some negligible fee so you include it (better than nothing right?). Then the next transition need only compensate you for the potential loss of  your infinitesimal profit on the first transaction, which in turn is even more infinitesimal. Everyone transacting understands this so they understand that the fee needed to get into a block is virtually nothing. They won't pay more. Because the fee necessary to get into the block at all is so small, even the highest fee transaction in the entire mempool won't pay a lot (unless someone fat fingers of course). So this all collapses. That's what the math is telling you.

N pirates are dividing the loot of M gold coins. They don't trust each other etc. and have the following rules (only):
- most senior one starts by proposing a distribution of the coins between robbers
- a vote is held whether this is accepted, ties are broken by the senior guy
- if it is rejected, the senior guy is hanged and new proposal by the second-in-command.

[smooth]

No the mempool doesn't matter, because you still need an incentive for people to pay a non-negligible fee. Let's say the most profitable transaction in the entire pool pays some negligible fee so you include it (better than nothing right?). Then the next transition need only compensate you for the potential loss of  your infinitesimal profit on the first transaction, which in turn is even more infinitesimal. Everyone transacting understands this so they understand that the fee needed to get into a block is virtually nothing. They won't pay more. Because the fee necessary to get into the block at all is so small, even the highest fee transaction in the entire mempool won't pay a lot (unless someone fat fingers of course). So this all collapses. That's what the math is telling you.

N pirates are dividing the loot of M gold coins. They don't trust each other etc. and have the following rules (only):
- most senior one starts by proposing a distribution of the coins between robbers
- a vote is held whether this is accepted, ties are broken by the senior guy
- if it is rejected, the senior guy is hanged and new proposal by the second-in-command.

You can't hang users (or miners) in Bitcoin, they are anonymous (for practical purposes here) and new entry is permissionless. In fact there isn't even a "most senior" miner or user at all. So this analogy doesn't apply.

It is an interesting puzzle though, although like most of these puzzles the correct solution can depend on subtle differences in interpretation of the problem statement. Another one like that being the Monte Hall problem.

[TrueCryptonaire]

Looks like nobody wants to buy or sell.
If you sell, you might end up selling too low as there is incentive to start building up higher walls.
If you buy only a small amounts of coins, there is a sell wall at 0.0023 waiting which might scare the traders not to execute any buys.

Interesting situation - we will see how this will play out.  

The good thing is, there is now finally a good number of buy orders.

[dEBRUYNE]

Looks like nobody wants to buy or sell.
If you sell, you might end up selling too low as there is incentive to start building up higher walls.
If you buy only a small amounts of coins, there is a sell wall at 0.0023 waiting which might scare the traders not to execute any buys.

Interesting situation - we will see how this will play out.  

The good thing is, there is now finally a good number of buy orders.

I think most XMR traders are used to big walls by now :-P Or at least the medium size (10-20k). Also, if someone nibbles a bit off that, the rest will follow.

[TrueCryptonaire]

Looks like nobody wants to buy or sell.
If you sell, you might end up selling too low as there is incentive to start building up higher walls.
If you buy only a small amounts of coins, there is a sell wall at 0.0023 waiting which might scare the traders not to execute any buys.

Interesting situation - we will see how this will play out.  

The good thing is, there is now finally a good number of buy orders.

I think most XMR traders are used to big walls by now :-P Or at least the medium size (10-20k). Also, if someone nibbles a bit off that, the rest will follow.

Yup, that's right.
The likelihood to go up is bigger than to go down since in order to go down you need to dump pretty much over 100 btc's worth of coins.
Try to rebuy such an amount for lower price taking account the competition there is around 0.002-0.0022 levels.
Therefore I think the wall at 0.0023 will eventually be eaten or pulled.

[dnaleor]

N pirates are dividing the loot of M gold coins. They don't trust each other etc. and have the following rules (only):
- most senior one starts by proposing a distribution of the coins between robbers
- a vote is held whether this is accepted, ties are broken by the senior guy
- if it is rejected, the senior guy is hanged and new proposal by the second-in-command.

solution: the 2 youngest always reject so they can divide the M coins between themselves?
The second youngest will probably end up with most of the coins, but the youngest will demand at least round_up(M/N) coins
that is my guess :p

edit:
this works if N = 3

Let me think...
If N = 4, the second oldest don't want to die I guess, so he will bribe the 2 youngest
so he gets zero, and the other 2 get N/2, oldest one dies

I need to think about this some more, very interesting puzzle!

---

edit2, very interesting...

N=1: (obvious)
=> P1 gets M

N=2: P1 breaks the ties, so he can just take it all
 => P1 gets M, P2 gets 0

N=3: P1 wants to live, so he need at least one of the pirates to accept his proposal.
The only way he can achieve that is by colluding with P2 or P3 and giving him all the coins.
No idea who would collude, but I am guessing P2 and P3 will start to lower their bid to make sure P1 picks them, it's a race to the bottom
I don't have a solution for this... Maybe P1 ends up with M-1 and P2 or P3 gets one coin
On the other hand, P2 can bribe P3 to hang P1 so he has a better chance to get some coins. He promises to give P2 some coins to collude with him so doesn't end up with zero coins (which would be the normal case for N=2)
But in that case, P1 will offer P3 all his coins, if he wants to live. It is also possible P1 offers P2 all of his coins, but this seems less likely, because P2 would get all the coins anyway for the case N=2, so he would demand additional coins or a service from P1.
=> It will be cheaper for P1 to just give all his coins to P3 (I think)

N=4: P1 wants to live, but P2, P3 and P4 can collude to take him out. they need all 3 votes though, so everybody needs to gain
P2 just doesn't want to die in N=3, so he will offer P3 and P4 an equal amount of coins (M/2), I think.
another option is that P4 bribes 2 other people to collude with him, possible P2 (because he would get zero coins in all other scenarios) and P3 or P4.
although I think in the end, P3 or P4 would again end up with all of the coins, because they think about the situation for N=3  and due to the same reasoning, I think P4 will end up with all the coins
=> P1 colludes with P2 and P4 to support him, P4 gets all the coins

same for N=5, 6, ...

So, I think that, as long as N =/= 2, the youngest will end up with all the coins and nobody dies
If N = 2 the oldest one gets them all


edit3:
found this on wikipedia:

The pirates do not trust each other, and will neither make nor honor any promises between pirates apart from a proposed distribution plan that gives a whole number of gold coins to each pirate.

This changes things a lot

[ArticMine]

We make the following assumptions:

1) That M > N
2) If there is an even number of pirates left the senior pirate votes twice once in the regular vote and once to break a tie if needed
3) The coins cannot be broken down into smaller pieces of gold
4) There is zero cost for the hangings (For example the cost of the rope is zero)
5) Each pirate acts strictly in his best financial interest.

The solution is the senior pirate distributes one coin to each priate, except the second most senior pirate gets no coins and he keeps M+2-N coins for himself.

We start with N=2. In this secnario the senior pirate keeps all the coins and uses his tie vote to outvote the junior pirate
N = 3 The senior pirate only needs the vote of one pirate. So he pays the cheapest cost by giving one coin to the most junior and keeping the rest etc.