Bitcoin Forum
May 09, 2024, 12:52:19 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
361  Alternate cryptocurrencies / Altcoin Discussion / Re: [XMR] Monero Technical Discussion on: July 31, 2015, 05:46:40 PM
Lots of posts deleted because they were not technical.

So pretty. I haven't any useful input on fees.

What do people think about serialized stealth payment IDs versus unique spend keys with single viewkey?

Edit: try to keep up! Cheesy

Edit2: maybe you should change title to "[XMR] Monero Improvement Technical Discussion" or something.

I don't understand .....'

good idea on the thread title change.

The new Bytecoin "breakthrough", where they're "depreciating" payment IDs. It is a potential solution, and I'd be really interested in seeing an actual cost analysis instead of generalities.

The idea is to have one view key with multiple spend keys. That gives you multiple public keys (addresses) where half is common and half is unique. This allows scanning for all of these addresses much more quickly than scanning for completely different addresses (for the use case of an exchange or web wallet where each user has his own address -- instead of the current practice of one exchange address plus payment IDs).



Yes indeed. Sorry, I didn't really mean to come across as snarky (not sure if I did).

Neither of these change any consensus rules in any way, they're just attempts to recommend standards for recipients to differentiate payments.

362  Alternate cryptocurrencies / Altcoin Discussion / Re: [XMR] Monero Technical Discussion on: July 31, 2015, 04:41:52 PM
Lots of posts deleted because they were not technical.

So pretty. I haven't any useful input on fees.

What do people think about serialized stealth payment IDs versus unique spend keys with single viewkey?

Edit: try to keep up! Cheesy

Edit2: maybe you should change title to "[XMR] Monero Improvement Technical Discussion" or something.

I don't understand .....'

good idea on the thread title change.

The new Bytecoin "breakthrough", where they're "depreciating" payment IDs. It is a potential solution, and I'd be really interested in seeing an actual cost analysis instead of generalities.
363  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 31, 2015, 04:15:53 PM
I don't think Monero is for me, I prefer transparant coins, imagine if the tax agency demands proof of your transactions for example...
If a tax agency demands proof of your transactions, you can provide your viewkeys (either for your address, or per-transactions), so you can decide what to reveal or not. There is the real power, it's private by default, but public on demand.
You probably didn't know viewkeys existed? You probably don't know much at all in fact.
Better read a bit before posting irrelevant "conclusions".

Not only view keys (which are kind of a blunt instrument because they reveal every payment, when proof of every payment might not be needed), but you provide other evidence (for example receipts) the same way you would do for cash or any other payment system that doesn't have a public ledger.

The idea that tax systems need all your transactions visible to the world in a public ledger like Bitcoin is absurd, since Bitcoin has only existed for 5 1/2 years. Tax systems (and public accounting generally) have existed a bit longer than that.

EDIT: It looks like there is discussion about having multiple view keys, so there could be more control here https://www.reddit.com/r/Monero/comments/3f9nej/i_want_more_viewkeys/

So much this.

"OMG, where did this cash that my customer used to buy a banana come from?!?" "How will I ever have a record of this sale without a public ledger keeping track of it?"
364  Alternate cryptocurrencies / Altcoin Discussion / Re: [XMR] Monero Technical Discussion on: July 31, 2015, 03:57:46 PM
Lots of posts deleted because they were not technical.

So pretty. I haven't any useful input on fees.

What do people think about serialized stealth payment IDs versus unique spend keys with single viewkey?

Edit: try to keep up! Cheesy

Edit2: maybe you should change title to "[XMR] Monero Improvement Technical Discussion" or something.
365  Alternate cryptocurrencies / Altcoin Discussion / Re: Why is Monero ignored by the public even though it has the best tech out there? on: July 30, 2015, 02:29:52 PM
--Monero's TPS is unbounded (currently 1,600 TPS).

Monero at 1,600 TPS would probably consume all of the whole world's internet bandwidth.

No that doesn't sound right.

I don't know what an "average" transaction's size is, nor what it'll be in the future if/when there's more use, but let's say 10kB just for fun (sample real TX that's probably larger than average: 30 inputs @ mixin 4, 5 outputs; size: 11481 bytes).

10 * 1,600 / 1024 * 8 = 125 Mbps

It's not trivial, that's for sure.

In addition all those 1,600 transactions are first received by you, then you broadcast them to all the peers you know, and then receive the block containing the same transactions, and later send those blocks to other peers downloading the blockchain. Total bandwidth usage is probably somewhere around 1 Gbps for every peer.

"are first received by you": yes, let's say you need 50 Mbps after my new math.
"then you broadcast them": on average it should be one time, I think.
"then you broadcast them": you shouldn't re-download data you already have (though it may work that way now).
"send those blocks to other peers downloading": this is a rather limited case that doesn't happen that often.

All told you might need 100-200 Mbps of bandwidth (synchronous).

No one is saying 1,600 TPS is practical *right now* (or at least, they shouldn't be saying that). The number was based only on i7 processing speeds.

One could instead say: TPS is limited in CN mostly by processing and bandwidth speeds, NOT the protocol. With BTC limited by the protocol to around 3 TPS, it's still a major distinction, whatever "practical" speeds CN can achieve on today's hardware and bandwidth.
366  Alternate cryptocurrencies / Altcoin Discussion / Re: Why is Monero ignored by the public even though it has the best tech out there? on: July 30, 2015, 01:59:55 PM
--Monero's TPS is unbounded (currently 1,600 TPS).

Monero at 1,600 TPS would probably consume all of the whole world's internet bandwidth.

No that doesn't sound right.

I don't know what an "average" transaction's size is, nor what it'll be in the future if/when there's more use, but let's say 10kB just for fun (sample real TX that's probably larger than average: 30 inputs @ mixin 4, 5 outputs; size: 11481 bytes).

10 * 1,600 / 1024 * 8 = 125 Mbps

It's not trivial, that's for sure.

Edit: after discussion with a dev, we decided on a better average tx size: 3kB (10 inputs @ mixin 3, 10 outputs approximately)

This makes the above change to 37.5 Mbps.
367  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 30, 2015, 04:43:59 AM
Hi guys!
We offer affordable translating services & follower attraction services for your social media accounts.
Check us out!
Cheers!

https://bitcointalk.org/index.php?topic=1137936

Oh yes, this looks very legit. Thanks.
368  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 29, 2015, 11:50:38 PM
What are basic instructions to derive viewkey for an address? Want to be able to keep an eye on cold storage.

It is literally impossible to derive the view key from an address since the address is a public key and a view key is a private key.

You need to extract the view key from a wallet that has the private key. One way to do this is to just write it down when the wallet is created. Another is with the viewkey wallet command.

I said FOR an address. Not FROM. Easy misread. Thanks for the answer. I don't have the client up and running so just was wondering if it was simply a command or what.

*If* your cold wallet is an offline standard XMR wallet.bin (or whatever name), then it's as mooo said: simply start simplewallet and type "viewkey" at the prompt. If you're planning on actually *using* it, the better approach would be "save_watch_only", then bring that wallet copy online.
369  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 29, 2015, 10:22:31 PM
A bit of confusion...

In mymonero there is a prompt: Account>
Upon mousing over, there is an option "Review login key", but upon choosing this option there is nothing displayed, but a picture of two overlapping files.
Upon clicking on those nothing happens.
Is there a way to see it (the login key)? Without this you have to enter three keys to access the account.
is it even proper to use the login key to access the account?

Hmm, maybe try clearing your browser cache or using a different browser? When I click that I see a 13-word login key.

Could you maybe screenshot it (if there's sensitive data displayed, remove that of course)?
370  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 29, 2015, 08:57:22 PM
What are basic instructions to derive viewkey for an address? Want to be able to keep an eye on cold storage.

If it's your own address, you can type "viewkey" in simplewallet.


If it's cold storage, he won't be able to do that.

Why not ?
That's kind of the point of this command: get the view key from the cold wallet, copy it to the less safe machine, and use it there.
Or did I misunderstand the question ?


Oh, I think the misunderstanding is mine. I was thinking of a paper wallet.
371  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 29, 2015, 08:48:07 PM
Once again, I'm try to build the RPi2 version (using the Berkeley DB) following this guide:

Quote
git clone https://github.com/monero-project/bitmonero.git bitmonero
cd bitmonero

vim Makefile

in the “release-all” section add this code:
-D NO_AES=ON (type “i” to edit) escape, then :x to save

cd src/blockchain_db/lmdb
vim db_lmdb.cpp
scroll to line 675 change “size_t mapsize = 1LL << 34;” to “size_t mapsize = 1LL << 30;” :x

cd
cd bitmonero
make release-all
cd build/release/bin
./bitmonerod --db-type berkeley

However, it is no longer possible to execute this as db_lmdb.cpp has been changed:

Quote
cd src/blockchain_db/lmdb
vim db_lmdb.cpp
scroll to line 675 change “size_t mapsize = 1LL << 34;” to “size_t mapsize = 1LL << 30;” :x

Could someone help me out here and update the guide?:
https://forum.getmonero.org/20/general-discussion/267/a-step-by-step-guide-to-running-a-full-node-on-raspberry-pi-2


There's a new thread I believe: https://forum.getmonero.org/5/support/360/bitmonerod-node-on-rpi2-working
372  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 29, 2015, 08:43:29 PM
What are basic instructions to derive viewkey for an address? Want to be able to keep an eye on cold storage.

If it's your own address, you can type "viewkey" in simplewallet.


If it's cold storage, he won't be able to do that.

I have the tools to do this in an easy way, but you'd want to pull the webpage and use it offline on a one-time install of some sort for maximum security (if using for "real" cold storage).

After you've gotten the viewkey, you should be able to import it into simplewallet to watch with --generate-from-view-key argument.

(PM me if you want to use the site; I don't want it too public yet)
373  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 28, 2015, 05:53:38 PM
Everyone please join
http://www.reddit.com/r/Monero/

and

https://forum.getmonero.org

Better organization of information and less trolling

Except that I can't reply in any threads on https://forum.getmonero.org

I used to be able to.  I can start threads, which I have to let it be known I am having issues.  Now waiting, it's all I can do.

I see your thread there; since you can't respond there, I'll ask here:

Have you tried a new user account or different PC? Those seem the most obvious isolation ideas.
374  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 27, 2015, 10:19:50 PM
My question isn't really answered yet:

how can a spectator know that the image key is associated with at least on of the inputs in the transaction?

See the whitepaper section 4.4, step VER.



thx, will reread it more carefully Smiley

Yes indeed, was going to point you there, but hadn't refreshed forum in a while (so smooth already answered).

edit2: the transaction private key is never used, am I right? It's only used to calculate the transaction public key?

It is used, but only by the transaction creator. It's how they create a "shared secret" with the receiver.

ECDH(receiverViewPub, txPriv) == ECDH(txPub, receiverViewSec)
375  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 27, 2015, 08:28:17 PM
just write a narrative of the diagram following the numbers. I've never tried this, here goes

1. from the blockchain, a transactions public key is mashed together with a random number
2. a specific output is used
3. bobs private key is used
4. the above three things are mashed together into a private key
5. another random number mashes with a public key
6. number 5 gets mashed with the following

and I got lost and im at work and peeps gettin coffee.

Well, no, that's not really how it works. Smiley

1. For the sender, a random transaction private key is chosen.
2. The sender does a ECDH with this private key and the receiver's public view key.
3. From that derivation and an output index, he is able to use the receiver's public spend key to create a one-time output public key for which only the receiver will be able to generate a private key.

To generate this private key:

1. The receiver does an ECDH with his private view key and the public transaction key (from tx extra)
2. From this derivation (which matches exactly that from step 2 above), the receiver does the same as step 3 above.
3. If his result matches, he knows he owns the output. He can then use his private spend key to generate the corresponding output private key (to actually spend the output).

I figured as much, but that was my point - the diagram is not very helpful for those of us that are all like "my compooter gone did done some mafs"

Thank you though! - the above is short and sweet, but dnaelor's actually matched up with the diagram numbers. And yes, one of those "floating hand draws and some guy talks" animation things would be cool

Yes, I was only covering the stealth address portion, which, IMO, is harder to "get" than the ring signature portion. dnaleor's covers the full transaction, but also isn't quite correct. Smiley

The graphic doesn't really explain stealth addresses at all, so the first part of this is basically inline, but I've added a bit to it anyway.
let me give it a try Smiley

Bob wants to spend XMR he received in his account and send it to Carol.
How does he compose the transaction?

A: Bob gets acces to his "real input" that was send to his "stealth address"
1. Bob needs the public key from the transaction that contains the output he received and wants to send - Bob needs to ECDH this key with his private view key
2. Bob also selects the exact number of the output from the transaction that contains the output he wants to send. The other output(s) in this transaction is/are change (Bob doesn't have the private key for those other outputs) Note: typically, due to auto-denomination, Bob will have more than one output per transaction that belongs to him.
3. Bob needs the "master" private key of his account - private spend key, to be precise
4. 1,2 and 3 are used to calculate the private key for the specific output he wants to send. (the public key for the transaction can be calculated from this private key - This is correct, but the public key is also stored on the blockchain.)

B: to protects Carol's identity, Bob will do the folowing to generate a "one time" public key for this transaction, making it impossible for others to link all transactions send to Carol to the same "stealth address"
5. Bob generates a random number scalar, this one isn't clear from the graphic at all
6. this random number is hashed into the transaction public key the transaction private key, and is scalar mult'd into the transaction public key
7. he selects the number associated with the outputs (due to auto-denom) that Carol will receive, the other output(s) is/are change that goes back to Bob.
8. he needs the "master" public key from Carol to be able to send it to her stealth address - Carol's public view key
9. 6,7 and 8 are used to calulate the public key for the specific outputs he wants to send

C: to "mix" the inputs, Bob creates a ring signature
10.  He selects the actual public key (+ that output's private key) from the output he wants to send, but he also adds other public keys into the mix.
11. to prevent double spending, Bob needs to send a valid "key image" together with the public keys of the outputs (or inputs if you prefer).
12. he signs the combination of inputs and the key image with his private key, prooving the key image is valid (Bob owns the private key associated with the key image) and that (somehow? I don't know how this works) one of the public keys is used to generate this key image, but as a spectator of the blockchain, we can't know which of the used outputs is "the real one that is being transferred". His private key and the other chosen public key(s) are used to create a ring signature; they'll be one signature for each input, collectively making a ring signature. The key image is an additional public key computed from the output private key (not public key) that's actually being spent.
13. This is the collection of outputs that is signed. He grabbed the "fake ones" from the blockchain. He doesn't need permission from the owners for that. This isn't quite right: those are the outputs that are doing the signing. A hash of the TX prefix is "what" is actually being signed.
14. This is the key image he signed. If Bob ever tries to send the same output again, the exact same key image will be generated and thus the double spend will be detected.
15. this "ring signature" is added to the transaction containing the publi keys that are used in the transaction and proving Bob's ownership of one of those inputs.



tell me if I was terribly wrong Wink


edit: damn it, luigiiii is faster than me Tongue
376  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 27, 2015, 06:52:16 PM
just write a narrative of the diagram following the numbers. I've never tried this, here goes

1. from the blockchain, a transactions public key is mashed together with a random number
2. a specific output is used
3. bobs private key is used
4. the above three things are mashed together into a private key
5. another random number mashes with a public key
6. number 5 gets mashed with the following

and I got lost and im at work and peeps gettin coffee.

Well, no, that's not really how it works. Smiley

1. For the sender, a random transaction private key is chosen.
2. The sender does a ECDH with this private key and the receiver's public view key.
3. From that derivation and an output index, he is able to use the receiver's public spend key to create a one-time output public key for which only the receiver will be able to generate a private key.

To generate this private key:

1. The receiver does an ECDH with his private view key and the public transaction key (from tx extra)
2. From this derivation (which matches exactly that from step 2 above), the receiver does the same as step 3 above.
3. If his result matches, he knows he owns the output. He can then use his private spend key to generate the corresponding output private key (to actually spend the output).

Edit: this is just stealth addresses, and has nothing in particular to do with the flowchart; I kinda missed that part of GingerAle's post.
377  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 27, 2015, 05:31:06 PM
hey i think you mix two differen things up:

he was asking for RPC documentation. This means he just want to see a place where he can see what parameters he has to give to a function and what he will be getting back. the best solution to do this IS looking inside the code, since even people that can not code could read it if they know what they are looking for.

the thing you are talking about is documentation about cryptonode internal functionallity like ring signatures, stealth addresses etc. i agree documentation on this things are not good enough for the common public, but this was not the right way to bring this issue up since smooths answer was the best one to give.

how to deal with it? the funding page needs more content anyway and people at monero forum are trying to define a work package for the "monero about" page (https://forum.getmonero.org/7/open-tasks/346/about-monero-page-content). this would be the right way to go if your intention to change this should bear fruits one day . maybe we could inculde it there ?

the problem is, there are not a lot people who really know how all this works. only the devs can make such graphs

I wouldn't say *only* the devs, as I'm not a "dev", but have a pretty decent understanding of how it all works.
378  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 27, 2015, 05:29:25 PM

Is there any RPC documentation for that is up to date? Before we always used the Bytecoin wiki, but it's rather outdated now - the devs added some RPC calls lately, right?

There have not been major changes recently, only a few minor ones. There has been work on revamping the RPCs but that is not in master yet.

There is not completely RPC documentation that is up to date, unfortunately. The best place to look is the code, which in that respect is quite readable.

https://github.com/monero-project/bitmonero/blob/master/src/wallet/wallet_rpc_server_commands_defs.h
https://github.com/monero-project/bitmonero/blob/master/src/rpc/core_rpc_server_commands_defs.h

As a matter of fact where can I get a list of all the code that is now "All quite readable"? I can't believe there isn't even a simple flowchart or block diagram available. I'm starting to think this project has forgotten what open source stands for. I under stand the inherited code was intentionally obfuscated but I am not seeing any efforts to remedy this in a "Open way", Or maybe I just don't have the skills to find this information as I stopped programming before Github existed and everyone thinks if it's there in any form then it is open. If I throw a pail of water into the ocean I can't say it's accessible.

As you can tell I'm getting a bit frustrated at these off the cuff comments "Go look at the code it's there". This is the shit that raised red flags. I understand the desire to keep information in the insiders club mentality, it's used in financial scams all day long but if this project is ever going to be adopted then these issues need addressing.

This is the only graphical representation I've been able to find and I'm not sure if it's correct.



Yes, that looks correct. It looks hard to parse if you don't already understand what's going on though (to me).

I'm not sure it's actually possible to put it together in an easy-to-understand way for "noobs".

Edit: and has nothing to do with RPC commands at all, as medusa13 points out.
379  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 24, 2015, 03:53:47 PM
Hold shift and right-click on folder and select "Open command window here".

A very useful trick that I can never remember when I need it. Maybe writing this will finally fix it in my mind..

It is very helpful for "cmd noobs" because they don't have to worry about finding the right directory, etc.

Nice, Never knew that. When was it added? I always added it to the right click menu.

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\CommandPrompt]
@=”Command Prompt:”
[HKEY_CLASSES_ROOT\Directory\shell\CommandPrompt\Command]
@=”cmd.exe /k cd %1″

At least since Vista. I don't feel like digging up an XP machine ATM, but I *think* it has it as well.
Never used vista, probably why I missed it. I'll check XP l8r. Thx. Smiley

Just checked, this is not an option for XP.

Well there ya go. Stop using old, no-longer-supported OSes. Smiley
380  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: July 23, 2015, 03:20:03 PM
Hold shift and right-click on folder and select "Open command window here".

A very useful trick that I can never remember when I need it. Maybe writing this will finally fix it in my mind..

It is very helpful for "cmd noobs" because they don't have to worry about finding the right directory, etc.

Nice, Never knew that. When was it added? I always added it to the right click menu.

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\CommandPrompt]
@=”Command Prompt:”
[HKEY_CLASSES_ROOT\Directory\shell\CommandPrompt\Command]
@=”cmd.exe /k cd %1″

At least since Vista. I don't feel like digging up an XP machine ATM, but I *think* it has it as well.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!