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

It has been tricky to follow the various sub-threads here over the last couple of days, but here are a few points regarding development funding.

1) As a moderately large holder, I am planning to join MEW ASAP with a 100 XMR donation, half of which will go to the devs. Hopefully MEW will raise a fair chunk collectively.
2) As a miner, I'd be happy if more of the mining fees, and/or transaction fees went to the developers rather than miners directly. I do mine on a pool that donates to the devs.
3) I mine based not on the current value, but the potential future value of XMR (say 10x current value). Perhaps the devs could consider donations in the same light (assuming you're able to hold)?
4) I'm not in favour of changing the emission schedule at this stage.

Q

Are you trying to confuse me ?


tx{
  prefix= {
     input(a1(5 XMR),f1(5 XMR),f2(5 XMR),f3(5 XMR))
     output(r1(3 XMR),c1(1 XMR), keyimage(priv(a1)))
  }
  sign(tx_prefix,pub(a1),pub(f1),pub(f2),pub(f3),keyimage(priv(a1))
  sign(tx_prefix,pub(a1),pub(f1),pub(f2),pub(f3),keyimage(priv(f1))
  sign(tx_prefix,pub(a1),pub(f1),pub(f2),pub(f3),keyimage(priv(f2))
  sign(tx_prefix,pub(a1),pub(f1),pub(f2),pub(f3),keyimage(priv(f3))
}

I wasn't including an actual signature here at all. I thought we were discussing transaction fees.

The tranasction prefix -- which consists of what we normally think of as the tranasction (inputs and outputs) -- gets signed using public keys from a1,f1..f3 and a key image derived from the private key of a1

sign(tx_prefix,pub(a1),pub(f1),pub(f2),pub(f3),keyimage(priv(a1)) -> signature

There is one such signature for each input. These are then included in the transaction along with the transaction prefix.

Did you forgot to add  keyImage for a1 ? Or how can be this transaction verified ?

You can't do #2 with the the protocol works today. There is a modification from gmaxwell that allows using foreign outputs of different sizes but it isn't implemented anywhere AFAIK.

Your foreign ouputs need to be of the same size.

So we would have (borrowing some of your notation)

tx(input(ring(a1(5 XMR),f1(5 XMR),f2(5 XMR),f3(5 XMR)) -> output(r1(3 XMR),c1(1 XMR)))

a1 = our own upspent output
f1..f3 = foreign outputs of size equal to a1
r1 = output owned by recipient
c1 = change output owned by us

We could also include additional inputs (and generate more change) if we wanted to further obscure the amount of the transaction.

Please can you make example:
1) I have unspent output  5 XMR, I want to pay 3 XMR for goods and 1 XMR transaction fee.
2) I want obscure my payment with 1 foreign input what holds 6 XMR.

Okay well like I said, each input will have it own set of foreign outputs used for mixing. Such outputs will all be of the same size, so this doesn't change the amount of the transaction, just its possible funding sources. Perhaps you want to revise your example?

yes I want use "foreign output used for a ring sig" to obscure transaction. I'll pull it from block chain.
g1(I pay for god) and a3(my new address)  does not matter.

The ins and outs each have amounts, so you can add that up.


I'm not sure of your notation here Is 'random' a foreign output used for a ring sig? In that case, that's not how it works. Each input uses a separate ring sig, with other outputs of the same same.

And what does g1 (or a3 for that matter) denote on your output?

Assuming zero fees is a reasonable conceptual model whether or not anti-spam fees are replaced by proof-of-work or some other such non-monetary mechanism.


I found the inclusion of CZ to be bizarre, but given that it is multisig for approval of disbursements and not even voting, the effect of someone like CZ being included is likely that he wouldn't even pay attention to this at all, and the multisig would revert to being 5/8 instead of 5/9. That isn't a disaster and might even be a good thing in terms of tighter control on spending, but its a bit of a silly way to do that.

I'd prefer to have outside approvers who don't even have anything to do with Monero or any other coin development but are charged to keep an eye on us and make sure (as a condition for continuing to approve spending) we aren't stealing the funding or using it for parties. I don't have any specific suggestions though.


Before there is any formal proposal for crowdfunding or a post-mine or whatever there will definitely a specific list of tasks and priorities. There will also likely be some sort of statement about the need for flexibility and ability to adjust priorities in a changing environment, but that won't take the place of being explicit about what the funding is intended to be used for.

chill down with chillness lol

OrientA
to buy xmr with btc
you have to buy btc with money asd
so btc dont fall but may stabilize the price

I do not propose to make an exchange
XMR/USD or XMR/EUR
because then it could cause problems
to exchange
so if you use it in tune
btc and XMR
I think it's the best system
for maket in tor system
and at the same time
XMR will have a surge in the price

So miner(or anybody) knows sum of all spent inputs and outputs ?


Am I right ?

Transaction
input(a1=5 XMR, random=6 XMR) output( g1=3 XMR, a3=1 XMR, keyImage_a1 )
ringSing(pub a1, pub random and private a1)

using VER and LNK everybody can verify that a1 holds 5 XMR, so I'm able to spend 4 XMR and miner can take 1 XMR fee ?

implies a1 was used (because I can't spend random)
implies a1_priv * H_p(A1_pub) = keyImage_a1

Am I missing something ?

A miner here.

Currently I use Claymore's miner with AMD cards.  I pay a 5% dev fee, which I think is a bit too high, but I acknowledge that the dev deserves something for his/her efforts.

If XMR devs were to create an equivalent or better Windows64 AMD miner with a 4% fee going to the XMR devs I reckon that would be a win/win.


Something to think about.

I thought there was instructions for setting up the pool software. Anyone know?

If not we should create that.

I wonder if there is a detailed instruction to set up own pool using Windows.

Good observation. Please move your hash rate off these pools if you are using one of them. See OP for a list of other pools, especially ones that donate to development.

Any pool that pays out at least a few blocks per day is big enough to produce reasonably low variance.

If you are running a wallet/node consider turning on solo mining (start_mining command in either daemon or wallet). Every little bit helps.

Good thought. If you buy XMR with BTC and use XMR instead, then BTC price will fall, but not much as XMR market cap is not big.

There is no tx_fee stored in the transaction. tx_fee is computed as =(sum of inputs) - (sum of ouputs). If you are looking for that in the code and can't find it let me know and I'll point it out for you.

The hash rate is very concentrated.

Dwarf pool: 5.28 MH/s,
crypto-pool.fr: 3.5 MH/s.

So for those three total: 17.7MH/s, or 85% of total.

If those 3 were taken out, XMR is in trouble.