Hey, so I was doing some thinking. If we just maximize the size of every block by moving a lot of money around .... would that fend off botnets by creating low subsidies?

Or would it be counterproductive because it would leave us w/ a high difficulty?

Thoughts?

Several commits have been pushed to master (thanks NoodleDoodle)

- Fix for merged mined block transactions throwing errors in wallet
https://github.com/monero-project/bitmonero/commit/5c820f902bddeb2eb7cf67f216481f4860c46f84
https://github.com/monero-project/bitmonero/commit/73158c7edccbc456c7dd8507eb4800284789c51f

- Added command "diff" to daemon
https://github.com/monero-project/bitmonero/commit/0217572cb289d52922612e0f46497c7051b203b2

I have a question - on the setup video on monero.cc it says you choose your wallet name? How is it I then see 95 character addresses?

so this is the command i used

wget -o blockchain.bin https://drive.google.com/uc?id=0B7RQILpPGrQbUGthNmVJM3RCNDQ&export=download

and this is the error im getting

 wget: blockchain.bin: Permission denied
JM3RCNDQ&export=downloaduc?id=0B7RQILpPGrQbUGthNmV


thats what it looks like??  any ideas

It's a non-problem.  The market will fix it.  Miners will mine the txns with the best fees.  Don't worry about prices.  The market sets them. They are never what payers want them to be anyhow.

Has anyone considered the practicalities of doing side-chains in MRO?  Moving mining to side-chains can help deter centralization of control in the hands of a single pool operator.  I'd been given short shrift for this notion as applied to BTC, but I think my critics are simply not thinking it through:  The idea is to mine on a dedicated side-chain, and merge-mine the main chain.  If you want to insure that there are a minimum of 100 pools, you can mine on 100 side-chains simultaneously, round-robin to insure fractioning the hashpower.  I haven't considered how this would be implemented in MRO, however.

Regarding chain bloat, garbage-collecting the chain would be a big splash, and get some attention.  Define a minimum balance, and let miners reap dust.  That number can change over time.  The block chain only needs to contain an effective record of the current assignment of non-zero (greater than dust threshold) balances.  Historical data is not required to maintain accounts.  It is currently used to compute hashes, but does not need to be:  The most up-to-date assignment ledger state can be used and old stuff discarded.  This will improve privacy to a small degree as well, although obviously its not in any sense a protection against evesdropping history maintainers.  If the chain is garbage collected, then there is precious little reason not to require a minimum mix.  The requirement to garbage collect the chain insures that mining is done by CPUs -- and it's not make-work, but actual useful work.

I've been trying to raise awareness of this issue. The typical response seems to be, "when Bitcoin addresses the problem, so will we." To me this means it will never be addressed.  The obvious solution is to perpetually increase the money supply, always rewarding miners with new coins.

Tacotime mentioned a hard fork proposal to never let the block reward drop below 1 coin:


I assume this is merely delaying the problem, however. I proposed a fixed annual debasement (say 2%) with a tx fee cap of like 0.001% of the current block reward (or whatever sounds reasonable). That way we still get the spam protection without worrying about fee escalation down the road.

Any solution involving debasement, however, will be met with harsh criticism, because "inflation is bad" and stuff.

So I would respectfully request that you guys take it over to the Economics subforum or somewhere else a bit more focused. There are MRO-specific topics to discuss here.

I raised similar issues last year as follows.

Transactions Withholding Attack

"Spiraling Transaction Fees Destruction" of bitcoin (Transactions fees are a Tragedy of the Commons)

I would imagine it to be aimed at something much more main-stream than a cryptocurrency. Like an email system or some other sort of messaging system would seem a much more valid proof of concept

While there is no way to share a secret code in an invisible email, there is a way to share it in an encrypted email that would destroy itself if viewed by an outsider. Using quantum encryption, you could send a message between two parties containing the deciphering key and that message, while detectable, would also be unhackable.

University of Oxford quantum physicist Artur Ekert calls quantum encryption the ultimate physical limits of privacy. Other key distribution schemes such as the Diffie Hellman scheme, rely on the difficulty of mathematical problems to work, whereas quantum encryption does not. According to Heisenberg’s uncertainty principle, objects viewed on the atomically small quantum scale change their behavior when viewed. Quantum encryption offers the possibility of a message so secure that any attempt to read it without authorization will destroy it, not because of some programmer’s whim but because of the way subatomic particles operate.

“For quantum cryptography we need ‘only’ to transit quantum particles over a certain distance, and this is relatively easy. Quantum cryptography has been demonstrated in practice and there are even companies that can sell it to you,” Ekert told Defense One.

Quantum cryptography and Bash’s pulse position modulation technique are two very different animals. Cryptography makes messages difficult to decipher and pulse position modulation cloaks them so that they can’t be detected. But Bash’s method could go hand-in-hand with something like quantum key distribution, which a message sender would use in advance to share the key code. That, in turn, would be used in the future for covert communication.

Here’s what the most secure electronic message exchange in the history of humanity would like: You would first exchange the code key in a quantum encrypted message, and then, when the receiver and the sender both had the code, they could exchange an invisible — thus perfectly secure — message. A third party might be able to detect that two parties had exchanged a single message that had been quantum encrypted, containing the key code, but that third party wouldn’t be able to see any of the exchanges that passed after that or open the key code message.

the world of cryptocoins has become rampant with FUD campaigns, puppet accounts and all sort of dirty tricks. It is sad that people want to operate that way instead of focusing on building the best technology and products, but there is nothing we can do about it, except minimize the disruption they cause. Fortunately most of their efforts are pretty transparent and ineffective (see comments a page or two back on this thread, or better yet don't).

ok i know now, refreshing is very important.

i hope it does not dissapear again

Update: bonuses have been sent. Fees are 0.5%.

That would be great. We first need to find out if the .NET features I used are even available in Mono (I'm most worried about WPF, Processes and async/await).

Another minor update: I think I managed to fix the problem where the daemon log window would sometimes stop updating. The wallet now 'pings' the daemon every second by sending an enter. This forces an update of the output from the daemon and will thereby update the log window.

https://dl.dropboxusercontent.com/u/6522303/CryptoNoteWallet_latest.zip

can you tell me what to look for inside the log?
i dont know how it looks like if i find a block

any ideas?

yes, its obvious theres something wrong, many people with same bug

Automatically (is this enforced or optional per wallet?) breaking the transaction outputs into constant units, e.g. 1 coin, 0.5 coin, 0.25 coin etc, will radically bloat the block chain. The ring signatures are going to be huge if you need to obfuscate among say for example 256 payers (1/256 probability of being non-anonymous) each for several inputs, as well as payee addresses for each of those fractional amounts.

gui?

I don't know if (part of) the bounty is open for everyone, but I have created a .NET based wallet. I started trying to use the RPC API of the daemon and simplewallet, but there are some large gaps in functionality covered by the API functions.

That is why I have create a wrapper around bitmonerod.exe and simplewallet.exe (filenames configurable in config file). It works by launching the simplewallet and daemon in the background and reading output and writing output to those processes. It should be relativly save, because it uses the widly used standard simplewallet and daemon.

It's targeted at windows, although it might be possible to port to Mono.NET (I have no experience with that). It should work with any of the bytecoin forks, but I have tested it with Monero.