not 2-3 sentences
yeop, still not any clearer what exactly you are asking. Yeah...Hueristic, man, it wasn't/isn't very clear what you want. You express concern about the wire protocol, but then go back into cryptography in 0MQ? As for Curve25519, that is a birationally equivalent curve of what Monero *currently* uses for its crypto. It's one of the "safest" out there, Bruce's comments nothwithstanding. Write succinct questions instead of walls of text demanding answers to vague "questions" and sounding angry and entitled when they aren't forthcoming (sorry if you didn't mean to come off like that). |
|
|
|
fluffypony is going to be speaking about this in the upcoming missive, which should be out in the next week or so. |
|
|
|
.... then again, the reason minergate has so much hash is because they have a browser miner.... which, you know, is just weird.
...no. The performance of the web miner is something like 1-2 hash/sec. |
|
|
|
Hello! Can somebody explain me how hash target works on monero?
in cpu-miner.c see this
memset(work->target, 0xff, sizeof(work->target));
work->target[7] = rpc2_target;
i see this in scanhash
cryptonight_hash_ctx(hash, pdata, persistentctx);
if (unlikely(hash[7] < ptarget[7])) {
so we are only concerned for hash[7] and target[7] really.
the way I understand target is 0xffffffff/diff, so it should be 1 at current diff right?
what happens when diff is over 0xffffffff ? we also check hash[6] or what?
and it's not obvious where this hash appears in the blockhash (like if I browser an explorer). for satoshi it's obvious where this is.
and how does monero actually validate this. could someone point me to the code that does this in the daemon?
Thanks!
I think this might help https://cryptonote.org/cns/cns003.txtBut I'm not sure. Yes that is correct, specifically: 5. Calculation of Block Identifier
The identifier of a block is the result of hashing the following data
with Keccak:
- size of [block_header, Merkle root hash, and the number of
transactions] in bytes (varint)
- block_header,
- Merkle root hash,
- number of transactions (varint).
and
+---------------+------------------+--------------------------------+
| Field | Type | Content |
+---------------+------------------+--------------------------------+
| major_version | varint | Major block header version |
| | | (always 1) |
+---------------+------------------+--------------------------------+
| minor_version | varint | Minor block header version |
| | | |
+---------------+------------------+--------------------------------+
| timestamp | varint | Block creation time |
| | | (UNIX timestamp) |
+---------------+------------------+--------------------------------+
| prev_id | hash | Identifier of the previous |
| | | block |
+---------------+------------------+--------------------------------+
| nonce | 4 bytes | Any value which is used in the |
| | | network consensus algorithm |
+---------------+------------------+--------------------------------+
Table 4.1: Block header structure description
The quotes above are specifically for computing the block identifier (hash) with keccak. The POW hash input is exactly the same, minus the leading sizeof wrapper. EDIT (fixed link): CryptoNight web version available here: https://xmr.llcoins.net/slowhash.htmlSample block for you enjoyment: Block: 1,000,000 Hash: a886ef5149902d8342475fee9bb296341b891ac67c4842f47a833f23c00ed721 (hash the below with keccak_256 to get this) Identifier: 4c0102ad91a6b70509930781258c24007085a407703a6c34b2a560fef7d2c51879fb5622ff3c17d65edc0000eb4670d141a7474b07426c34f5cd0cb54dfd5bade712abdec5dbd9f8cf0fc95801 CryptoNight hash: 675f9c8d902e664c91b0bde794a4f3078947bc324c273ffd3cdc365c00000000 (hash above sans leading "4c" with CryptoNight) Decoded: size major minor timestamp (varint) previous block ID nonce (little endian) merkle root number of transactions (varint)
4c 01 02 ad91a6b705 09930781258c24007085a407703a6c34b2a560fef7d2c51879fb5622ff3c17d6 5edc0000 eb4670d141a7474b07426c34f5cd0cb54dfd5bade712abdec5dbd9f8cf0fc958 01
|
|
|
|
Nothing is wrong. Mymonero attaches a small fee for each transaction: https://mymonero.com/#/terms5. Fees
5.1. Company Fees. Access to the account is free, but the Company may charge fees for additional Services. Specifically, and at a minimum, the Company can and does charge a fee for every transaction that is sent. Any applicable fees will be displayed in each Service. That would make sense, the math just doesn't seem to add up to me. The amount+fee on chainradar in the transaction that was sent to ShapeShift adds up to 26.32, which is *larger* than the 26.29493623 amount+fee reported by MyMonero on the confirmation page. I'd think that it would be the other way around. Maybe someone can break down the math for me. It would also seem useful to have the confirmation page on MyMonero break it down into parts so that there's no confusion. Finally, is there a simple way to have MyMonero spend the contents of the entire wallet so that there's no need to manually figure out what amount to enter? Ah yeah, I forgot about the MyMonero added fee. Someone reminded me of this on IRC yesterday after I posted. The remaining contradiction may be a truncation thing. |
|
|
|
One other thing, has anyone noticed MyMonero stating a different payment and fee amount on the confirmation page than when you actually look up the Transaction ID? Once I get my other issue handled with ShapeShift, I'll post an example with the Transaction ID versus what MyMonero's output was.
Payment amount is probably due to change, which depends on what inputs are selected. The fee shouldn't be different though; I'd be interested to see that. |
|
|
|
Need some help with simplewallet here: I'm having an ongoing issue where outgoing XMR transfers do not make it into the next block, and sometimes not for several blocks. This wreaks havoc with ShapeShift because they cancel the transaction if your deposit if it's not confirmed in a block within 10 minutes. If Monero blocks are not nearly full like Bitcoin and miner fees are automatic, what else could it be? Example: [wallet]: transfer xxx........
Money successfully sent, transaction <xxx........>
[wallet]: bc_height
1085653
[wallet]: bc_height
1085654
[wallet]: bc_height
1085655
[wallet]: bc_height
1085656
Height 1085656, transaction <xxx........>, spent xxx........
Why didn't that xfer get included in block 1085654 or 1085655? Thanks for the help! I don't know how to answer the question but I had a tx in block 1085656, I wasn't paying much attention but I was surprised it took a few blocks to get confirmed. My only guess is with the rapid increase in activity and hashrate over the past couple days there seems to be a lot of variance at the moment...two blocks found within seconds then 10 minutes between blocks: http://moneroblocks.info/Notice the tx per block is higher than average: http://moneroblocks.info/statsI'm sorry to hear that Shapeshift is not recognizing the payment as soon as it hits the tx pool. Use xmr.to. I have communicated with a Shapeshift dev on how to get the payment id from the tx pool but I guess they are too busy or something... Just checking the payment ID isn't a good practice. Pulling and scanning (viewkey/normal wallet stuff) the mempool is fine; that's what xmr.to does AFAIK. |
|
|
|
Bitcoin loans are now very affordable and as ETH bubble seems to be bursting there are plenty of bitcoins available now for margin long positions.
If you believe the price will rise faster than you need to pay interest, you might want to take a small long position...?
i have a small leveraged long position but nothing fancy, just for the lulz  trading the swings with leverage can be helpful especially for the smaller traders. why risk 2.5 btc if i can have the same performance for 1 btc ? depending on the individual situation this can really make a lot of sense. The market risk is the same. If you mean exchange/counterparty risk, then it might make sense (balanced against the interest rate). Isn't the market risk marginally worse because of the borrowed interest rate ticking away? Plus you give away more information by interacting in the lending markets. tick...tick...tick...I think interest rate is separate from market risk. Giving more information away is probably valid. "Same" is a strong word; "very similar" might be more appropriate. |
|
|
|
I figured I would make a short post about this here given it is an item that has perplexed me a bit (not sure if I'm reading into it the wrong way or not).
The output index (local to the transaction and not the global index) when being written to a file given its type is of size_t is output in hex format.
The way I've known this is that if the real_output_index is 10 or higher it starts to utilize hex characters.
Like 10 = a, 11 = b, 12 = c, etc.
And I just found that odd that when I've written that value to a file or even output to the command line that it shows up in hex.
This is dealing with the portion of the code that does key_image generation.
What I found even more odd is a random loop variable like (for int i = 0...) when outputting i also gets output in hex as well.
Something that perplexed me as i is an integer and not type size_t. So I must be missing something.
I've kind of had to work around it when I run into indexes above 9 that get retrieved for key_image generation.
It's not a huge deal just an interesting oddity I never could figure out while writing the software for the physical coins I've recently released.
size_t is an (unsigned) integer as well. How are you outputting these to a file? ofstream Same result for std out as well. Would you mind sharing this section of your code on pastebin or somewhere? |
|
|
|
Monero is a digital cryptocurrency that could go from under $2 in the year 2016 to $1000 in the year 2020.
It is not a bad idea to hold 1% or more of this in a cryptocurrency portfolio.
Not many people can afford to invest 380000$ in a cryptocurrency, if i had millions of dollars i would invest now but i will personally wait and hope for a pricedrop. I actually think i will end up losing money by investing in monero, i am very cynicaö when it comes to investments. Advantages with monero -anonymious(i still does not not really understand how it works). -tail emission and adaptive blocksizd limit. -mostly mined before ASIC comes. Problems -the general problem with PoW(mining centralisation) unfortinatily this is probably impossibld to avoid. -transaction time not fast enoug to replace cash. -lack of special features(instant messaging, pegged assets, smart contracts, etc). I like this "smart mining" idea, currently mining on GPU is a hassle and requires special software. A lot of gamers(line me) have GPU:s that is unused most of the time, it is nice to make a few moneros from them(i rarely play games). I think he meant 1% of a generic crypto portfolio, not 1% of XMR. Personally 1% feels much too small, unless you are, say, 90%+ in Bitcoin and only want a tiny exposure to alts. |
|
|
|
Bitcoin loans are now very affordable and as ETH bubble seems to be bursting there are plenty of bitcoins available now for margin long positions.
If you believe the price will rise faster than you need to pay interest, you might want to take a small long position...?
i have a small leveraged long position but nothing fancy, just for the lulz trading the swings with leverage can be helpful especially for the smaller traders. why risk 2.5 btc if i can have the same performance for 1 btc ? depending on the individual situation this can really make a lot of sense. The market risk is the same. If you mean exchange/counterparty risk, then it might make sense (balanced against the interest rate). |
|
|
|
I figured I would make a short post about this here given it is an item that has perplexed me a bit (not sure if I'm reading into it the wrong way or not).
The output index (local to the transaction and not the global index) when being written to a file given its type is of size_t is output in hex format.
The way I've known this is that if the real_output_index is 10 or higher it starts to utilize hex characters.
Like 10 = a, 11 = b, 12 = c, etc.
And I just found that odd that when I've written that value to a file or even output to the command line that it shows up in hex.
This is dealing with the portion of the code that does key_image generation.
What I found even more odd is a random loop variable like (for int i = 0...) when outputting i also gets output in hex as well.
Something that perplexed me as i is an integer and not type size_t. So I must be missing something.
I've kind of had to work around it when I run into indexes above 9 that get retrieved for key_image generation.
It's not a huge deal just an interesting oddity I never could figure out while writing the software for the physical coins I've recently released.
size_t is an (unsigned) integer as well. How are you outputting these to a file? |
|
|
|
You can go in IRC and register on #monero-otc, hand to hand exchange.
This is how i bought my 200 first monero with paypal transaction.
How is this safe? If I don't see the Monero will Paypal refund me? Besides, do we really recommend paying Paypal their high fees? It's very unsafe from the seller's perspective, not that bad from the buyer's. The problem is Monero transactions are not reversible, while Paypal's definitely are. I would guess that finding a trading partner using Paypal as a newbie account is rather unlikely. If you can get Bitcoin (through Kraken like you mentioned or some other place), buying Monero with it should be rather easy. |
|
|
|
...
Buy low sell high. That's the way to make money with Monero.
That is not only true about Monero. It is true about any market. Many people however do one of the following: 1) Buy high, hoping to sell higher, and sell low. ... and my favorite when it comes to Monero 2) Sell low, hoping to buy lower, and buy high. I am pretty scared now and so should you. Scared about what? There is no need to fear. |
|
|
|
Error: refresh failed: no connection to daemon. Please make sure daemon is running.. Blocks received: 0 I get this error when trying to run a refresh on a new wallet. My daemon is running and fully synced. I can open other wallets and use them without error, just not a new one. Any ideas? OSX - 9.4.0-4d448a9 Are your simplewallet and daemon the same version? That looks like the error I got using a newer simplewallet, which wanted to use a new RPC method that doesn't exist in 9.4 daemon. |
|
|
|
Question regarding hash functions: In the mininero implementation, there is a reference to a , now is this equivalent to the reference Monero in the source? Also, this is SHA512 not SHA3-512 right, which is different. It is not equivalent, no. It seems to only be in the oldMiniNero.py file as well. SHA512 is the default for EdDSA, which Monero's crypto is based on (using Keccak for the hashing algorithm instead). So the "Hash_to_Scalar" function should use Keccak instead and not SHA512? I don't see a hash_to_scalar function that uses sha512 in that repo. Where are you seeing it? |
|
|
|
Question regarding hash functions: In the mininero implementation, there is a reference to a , now is this equivalent to the reference Monero in the source? Also, this is SHA512 not SHA3-512 right, which is different. It is not equivalent, no. It seems to only be in the oldMiniNero.py file as well. SHA512 is the default for EdDSA, which Monero's crypto is based on (using Keccak for the hashing algorithm instead). |
|
|
|
30 minutes! Edit: Auction over. Congrats to Lloydimiller4 on his second coin! |
|
|
|
DAO hacked, apparently using recursive calls to split (i.e. withdraw ETH). Interesting times ahead. Crypto never fails to disappoint.
DASH, ETH, and DAO just got the wake-up call Monero received a year ago thanks to the Troll Block Attack. That was almost two years ago.  |
|
|
|
|
Show Posts
