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

Can I use foreign unspent output or this public keys are not known ?

We're starting the #Monero-Dev Fireside Chat #2 shortly, just a reminder for those that want to watch -

https://plus.google.com/b/101861896996947433029/events/c8094ts82ggh0mpkffu4ja5kohg

http://www.youtube.com/watch?v=s9gH2ndAAkE

Because I made an error (omission). The key images are indeed not included with the outputs, they are included with the inputs.

Corrected:
{

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

Different version with two inputs:

tx{
  prefix= {
     input(a1(5 XMR),f1(5 XMR),f2(5 XMR),f3(5 XMR),keyimage(priv(a1)))
     input(a2(4 XMR),f4(4 XMR),f5(4 XMR),f6(4 XMR),keyimage(priv(a2)))
     output(r1(3 XMR),c1(5 XMR)) ; fee 1 XMR
  }
  sign(tx_prefix,pub(a1),pub(f1),pub(f2),pub(f3),keyimage(priv(a1)))
  sign(tx_prefix,pub(a2),pub(f4),pub(f5),pub(f6),keyimage(priv(a2)))
}

In this case (key images are not included in the outputs), how do you want to prevent DOUBLE spend ?

whitepaper LNK

I will sign again and again same input.

No there is one signature for each input and the key images are not included in the outputs

That transaction above has one input (with a mix factor of 4), so it would have one sig. Some corrected examples:


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

Different version with two inputs:

tx{
  prefix= {
     input(a1(5 XMR),f1(5 XMR),f2(5 XMR),f3(5 XMR))
     input(a2(4 XMR),f4(4 XMR),f5(4 XMR),f6(4 XMR))
     output(r1(3 XMR),c1(5 XMR)) ; fee 1 XMR
  }
  sign(tx_prefix,pub(a1),pub(f1),pub(f2),pub(f3),keyimage(priv(a1))
  sign(tx_prefix,pub(a2),pub(f4),pub(f5),pub(f6),keyimage(priv(a2))
}

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.