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

After updating to 8.8.4 and receiving no error messages I woke up to the following.  I just checked the log and it started over an hour ago.

Before going to sleep I sent another small donation.


2014-Sep-17 11:08:37.602952 [P2P7]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:08:37.612959 [P2P7]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:08:48.546157 [P2P4]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:08:48.599194 [P2P4]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:09:07.189484 [P2P5]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:09:07.199491 [P2P5]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:09:49.791634 [P2P9]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
2014-Sep-17 11:09:49.832649 [P2P9]ERROR c:\users\ric_000\desktop\bitmonero\contr
ib\epee\include\net\abstract_tcp_server2.inl:307 send que size is more than ABST
RACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection

At present, we mine about 20k XMR a day, 1% of that is 200 XMR or about $400. Can we make the the block reward to pay 1% of coins to a wallet controlled by developer? As the value of XMR increases, the reward will also decrease, making the payment almost constant or higher if XMR appreciate faster.

I guess ill go ahead and bring up my idea of crowd funding again. Tell us how much it will cost to have the database finished. Tell us when it will be completed if you do raise the funds. Then I will hold peoples funds in escrow until enough is raised. The moment the funding goal is reached i will deliver the funds to the devs as per the arrangement. If the funding goal is not reached than I will refund everyone’s money.

See rep thread in signature if you are concerned about whether I am qualified for this task.

Amusing as that thought is, it's not a permanently viable solution. I will add my share to the fund in BTC (not exactly now, I'm a bit short for that), but I hope there are some plans to accompany meeting one of the larger goals (official GUI release, for example) with a more concerted fundraiser. Yes?

It's kind of sad... Monero has attracted some of the smartest minds I've seen in cryptocurrencies and cryptography, but we don't have enough money to pay to developed even 1/4 of the things we need to. It costs about $100-150 an hour to contract a decent programmer to hack (and please don't start on the value of third world programmers, if you're talking about that you've probably never used them), or $800-1200 a day. I would estimate that ByteCoin put in about a half million USD to get their project off the ground, which is probably why they've been trolling us so hard. But, the fact of the matter is, we're either paying out of pocket or (like me) working completely for free.

Monero is about a lot more than pumping and dumping -- it uses many of the features that have been desired from core devs over time like privacy and faster/more secure EdDSA (which uses Schnorr signatures). But there are major, major architectural overhauls to the core code that need to be done to give it even a fraction of the usability of BTC, and I fear we won't be able to afford that. I suspect we need at least 0.25-0.50M USD per year to keep things moving along smoothly, and we're not getting close to $21K USD a month in donations.

the updated version may be being blocked.

Yes - rates are at-the-time that the expense needs to be paid, so obviously donations took a beating when the exchange rate was quite a bit lower.


It is kinda frustrating to see other projects raise hundreds and thousands of BTC based on a whim and a promise...but then again, it does change the dynamic as respects the integrity of the project. If we're perpetually in the negative there's nobody's money we can run away with:-P

For whatever it's worth ...

I'll dedicate 5-10% of my holdings towards dev fund.  May be a few days & not a lot.

I did notice adding up all the XMR donations in the thread rptellia created was quite a bit more than 25 BTC (more like 40?) so I guess you must've exchanged them at lower rates to pay for expenses?

I think it would be a great PR move to somehow make how much "in the hole" the project is as far as what the devteam has spent on what more visible.  I know it's a labor of love but in my opinion it should be fully funded.  Maybe making it visible that the people doing the technical work are also pulling the financial load will help resolve that. 

Or maybe not too.  People are greedy to the point of hurting themselves.

Golden.

I did the upgrade to latest on windows and it works fine.

I'd say:
- either some files are not OK for linux
- either your daemon was working when you did the upgrade and you actually have the old daemon.

Please don't throw stones on me if I'm wrong!

Check your firewall, the updated version may be being blocked.

Same problem here. Even after "SYNCHRONIZED OK" message.

You have to launch bitmonerod.exe and sync it. Wallet will connect to daemon and scan blockchain.

Error: refresh failed: no connection to daemon. Please, make sure daemon is running. Blocks received 0

Updated to new wallet from the OP
Wtf is this error and how to fix it ?

 I put things in poems so I can understand them better; is this close:

Most coins leave a trail of wallets
Where each man has spent his bling
Monero has gone and solved this
By making his wallet into a ring
That's melted--cooled--put in a pouch
Each piece is spread the world  around
The wealth is spread from house to house
So the senders ring is never found

Medal of Freedom.  It seems more apt in any case.

Personally, I would pawn it.

A monero, OTOH (back on topic) I would keep.

This is better suited to the speculation thread.  The USD price has been trending about 10 bp/day north of the difficulty trend, which is itself about 60 bp/day since June.  It is unlikely to hold for an entire year however.  There will be lower-order jumps, and they will probably be adverse (mean reverting). In the absence of adverse jumps a 70 bp/day price trend would give us XMR\USD 6.

Looking at those words, I find it difficult to believe that XMR will be that cheap in a year.  BTC will probably have another hype cycle in that time, and XMR will probably get lifted with BTC, perhaps to a larger degree (levered play).  The size of the BTC hype cycle depends largely on the bandwidth available for fiat to flow into BTC, when it happens.  Still, in the absence of informative priors, ceteris paribus, the standardized expectation would be distributed according to the constraints mentioned above.  The central tendency of everything under the no-arbitrage assumption is always the risk-free rate.  Either you reject that assumption for a particular case, on grounds of differential information, or you limit your discussion to the shape of the distribution.

All of which is just another way of saying I think I have differential information, to the effect that favorable jumps will dominate, and the momentum trend will extend, rather than adverse (mean-reverting) ones, during the coming year.  I think the central tendency is better placed north of $6.  The distribution is very disperse, so that it contains relatively little information. Any attempt to plan financially based on such a distribution is subject to catastrophic failure.

Tough to say, many influencing factors. I would suggest to do your due diligince and then decide if you want to invest or not. There is no one here that precisely can say what the price is within a year.

EDIT: Maybe interesting to read this: https://bitcointalksearch.org/topic/m.8477489 . Also keep in mind, privacy is a big niche that can be filled by monero.

i say not less than 2$ but not more than 4$

I'll take a stab at it. I'll just take the whitepaper and try to cut out anything that isnt absolutely necessary for satisfying your request. Maybe we can bounce it around and crowd edit/redraft it. Ok so thats just a super rough draft. Please be tactful.

Monero in a nutshell

Inorder for an electronic cash to be private and anonymous it must satisfy two requirements. Untraceability: for each incoming transaction all possible senders are equiprobable. Unlinkability: for any two outgoing transactions it is impossible to prove they were sent to the same person.

Unfortunately, Bitcoin does not satisfy the untraceability requirement since all the transactions that take place between the network's participants are public. It is also suspected that Bitcoin does not satisfy the second property. A careful blockchain analysis may reveal connections between the users of the Bitcoin network and their transactions thus it fails the unlinkability requirement as well. We offer a solution that fully satisfies both untraceability and unlinkability conditions.

Inorder to satisfy the requirement of untracability, monero utilizes the concept of one time ring signatures. After signing a transaction the user provides, for the purpose of verification, not his own single public key, but the keys of all of the members of a group of users. An observer is able to then verify that the real signer is a member of the group, but cannot exclusively identify the signer. So long as all of the other participants in your group are valid signatures, and linked to valid ring signature groups, and all of the participants in those transactions are valid and link back to still valid ring signature groups... ect all the way back to the genesis block, than no doublespend is possible because for each and every ring signature group in the signatures progeny there is an equal number of inputs and outputs. All of this is accomplished without any need for trust, without any denial of service attack vectors, and without the need for any form of centralization. All members of a ring signature group are equal.

Inorder to satisfy the requirement of unlinkability monero utilizes a scheme which allows a user to publish a single address from which, in addition to some random data from the sender, a one time use public keys may be derived. Hence, there is no such issue as "address reuse" by design and no observer can determine if any transactions were sent to a specific address or link two addresses together.