Topic: [XMR] Monero Improvement Technical Discussion - page 6. (Read 14744 times)

I fail to make sense of the last two sentences. Could you elaborate?


Why limit yourself to hash functions? See

http://cryptorials.io/beyond-hashcash-proof-work-theres-mining-hashing/

Yes there are various proposals like that

https://bitcointalksearch.org/topic/dagcoin-a-cryptocurrency-without-blocks-1177633

https://www.reddit.com/r/Bitcoin/comments/2m8sh9/am_i_missing_something_blockchain_without_bitcoin/cm272vv

I proposed something similar but a bit different in MRL discussions, but it isn't fully designed into something workable (nor are the above proposals, but maybe they are closer)

Probably others too

Crazy idea I haven't fully thought through, but need to get it out of my head so I can get back to work.

Instead of the network being broken up, functionally, into miners, nodes, and transaction makers (which is they way things have devolved), would it be possible to combine making a transaction with mining? So essentially you can't mine without making a transaction, and you can't make a transaction without mining.

So, when the wallet crafts a transaction, it also crafts a proof of work. So - It takes everything in the mempool, creates a block candidate with the new transaction, and then hashes the block with a nonce or whatever to find a POW. In this design, the mempool is filled with failed block candidates. We'd have to find a way to commit each mining / transaction attempt though, such that one couldn't simply create a million transactions and pick the one thats works. There's also some obvious flaws in terms of bootstrapping. I.e., you can't mine without transacting, and you can't transact without coins.

edited to add: Duh. Stupid. Easy exploit - sybil-type attacks, setting up other wallets / accounts that you send transactions too in order to "mine". Though transaction fees could eat away at this.

edited to add:

so the software creates a transaction, pulls from the mempool some failed block candidates, extracts from those failed block candidates novel transactions (removes duplicates), and then hashes the whole thing to provide a POW.

hrm, perhaps make something called a failchain, which is a mini blockchain containing all failed block candidates. The failchain lives in ram, similar to the mempool. Once a transaction/block solution is found, that top block is added to the primary blockchain, and the failchain is destroyed. I think, perhaps, this fail chain would prevent one from spamming the POW-space with extra work. Because only unique transactions would be removed by the de-duplication mechanism. Thus, if you submitted multiple transaction-block-solutions, the failchain would reject them if they contain the same transaction as the POW-transaction, and if they were all unique, then when the block is finally found, all of those transactions will be processed (with their associated fees).

how the fail chain would be enforced, though.... hrm.

what's interesting, in general, is that this adds an in-network cost to mining.

For future reference, a lot of interesting work regarding pool disincentivization

https://cs.umd.edu/~amiller/nonoutsourceable.pdf

https://bitcointalksearch.org/topic/a-non-outsourceable-puzzle-to-prevent-hosted-mining-and-mining-pools-309073

which is  (obviously) an old problem in bitcoin, but I had no idea they were digging into this 2 years ago. And the thread seems to have been resurrected.

Unfortunately, I don't see pooling discouragement anywhere on the monero research and development goals. There's smart mining, but that suffers a chicken and egg problem IMO. If smart mining happens before / during a surge in adoption, then great, everyone's solo mining. If pools maintain their prominence in the network hashrate, people may not adopt monero due to the centralization. I.e., if people begin to appreciate the centralization of bitcoin as a flaw, they will look for a truly decentralized cryptocurrency. If monero, at that point in time, still has pools and an insurmountable network architecture (i.e., pools will not accept a fork that inhibits pooling), people will look elsewhere, or at worst, view cryptocurrencies as a failed experiment. The value proposition of all cryptocurrencies is the decentralization. That nothing is done to secure this fundamental nature of these networks is mind boggling to me.

Any idea when i2p support will be implemented into Monero?

No there won't be two blockchains. Everything will be relayed bidirectionally between the open and hidden networks.

bah BAM!

https://www.reddit.com/r/Monero/comments/2ti53m/why_is_monero_aiming_to_integrate_i2p/

Why i2p not tor? From what I understand, with i2p you can only access others  who are also in i2p network. So would there be two monero blockchains? One within i2p darknet, and second in "regular" internet?

Yeah I imagined that i2p would be integral to any non-full-blockchain transaction creation for the best privacy.

That's assuming you are only using one ISP. For mobile devices that will only be true if you never switch between cellular and WiFi, and with WiFi (or wired) only if you never switch locations. Of course they may all be spying and they may share data but they also may not. It seems there could be a lot of gaps.

If your ISP has spied on your connection (and let's face it, they prety much all do, whether for themselves or on behalf of people they can't easily say no to), and thus know which blocks you have received, any output used as input to a ring signature can be ruled out as yours if it was created in a block you did not download. Till we get I2P anyway.

right! exactly! that's what I guess the microchain downloading would do.

Nah just a sampling of it. You can even grab a bunch of outputs of every size ahead of time (say when a phone is on WiFi) store and use when needed.

I've been thinking about how Monero could pull off some form of light node / mobile wallet / electrum-style thing.

On-network transaction creation:

Basically, create a way in which you can create a transaction without having the blockchain downloaded. This is interesting in monero, of course, because you need the entire blockchain to craft a transaction, in order for the wallet to pick some outputs to mix with.

What if instead you could broadcast the skeleton of a transaction to the network, and other nodes could fill in the outputs necessary to complete your mixin. These nodes then send the transaction back to the node transacting.

So, I want to make a transaction for 22.2 XMR, with a mixin of 3. The wallet creates a network request essentially asking for other outputs of 10, 2 and 0.2. Perhaps this "file" sits in other mempools. When in the mempool of a remote daemon, the daemon recognizes it needs outputs, and puts in some candidates. When transaction is filled in, the daemon relays it back to the network. Because different daemons could create the transaction differently, you'd have different candidate sets. The requesting daemon then randomly picks one of these, the actual outputs are entered and then the full transaction is sent to the network.

Of course a problem might be a loss of privacy, because a snooper could skim the mempool for incomplete transactions, and then compare these incomplete transactions with finalized transactions on the blockchain. Although the stealth addresses might take care of this, because a set of outputs in a candidate set from the mempool would look completely different than the final set in the transaction recorded on the blockchain.

Microchain downloading
Alternatively, these type of clients could download portions of the blockchain on demand from multiple peers and only maintain a microblockchain containing blocks with their outputs. So, when a wallet goes to create a transaction, it instructs the daemon to just start downloading random chunks from the network. When enough chunks have been obtained to craft the transaction, the transaction is created and sent to the network. The other nodes participating as peers in this sub-network could have chunk candidates ready for transmission - i.e., the software scans the data.mdb file for useful chunks - essentially, seperating the wheat (blocks with actual transactions to mix with) from the chaffe (the rest of the blockchain filled mostly with coinbase payments at this point). This separation would become less useful over time, but still some block chunks are probably more useful than others.

Users of this client could then occasionally "freshen up" their privacy set - clear their microchain and obtain a new chain to craft transactions from. 

Again, this has the possibility of affecting privacy, in that the set of transactions your mixin is coming from would be observable on the network, if the stealth addressing doesn't masque this. Also, on your device, if someone obtained your microchain, they could potentially deduce which transactions are yours on the main chain.

And ultimately these would require implementation of MRL4 for ultimate untraceability, but thats the case with anything.

Well, that was one way to spend my morning coffee!

Okay, so one month of this thread being up. A short recap -

1. Using difficulty as a proxy for price as a way to automatically adjust minimum xmr / kb transaction fees. Potentially has legs, but the exact formula is yet to be determined.

2. Proof of work discussion re: asic resistance. A lot of it went over my head, but its the main thing being discussed on page 2. Cuckoo cycle seems fascinating, uses some sort of graph theory.

Going forward, I'm going to try and extract a model from the existing litecoin and bitcoin data, as they are two systems that have seen the full evolution of adoption, price discovery, and mining hardware. Whether or not these functions / models will be useful is unknown.

By technology never changing I was referring to a regime change in difficulty as happened with Bitcoin ASICs. The difficulty increased by a factor of 1000 (or whatever the number) without a corresponding increase in broader technology that would relate to the cost of transaction processing.

Actually that is not the assumption here. The assumption is that if the price of technology falls by say 1000x then the spammer would need 1000x as much spam to do the same damage.

Edit: We are talking about a per KB fee here after all.

It can't be assumed that the technology will never change though. That's not as big a deal for transaction fees where as I explained earlier it is fundamentally a guideline, so the worst case is you end up with a poor guideline but it doesn't fail altogether. It could be a bigger problem if using this method for something else.

sweet, thanks for the leads. Currently hunting down litecoin info.

edited to add: got the difficulty / time.

i think I can hack this to get price history... its somewhere in here

view-source:https://coinplorer.com/Charts?fromCurrency=LTC&toCurrency=USD

The Bitcoin price data going back to July 10, 2010 can be downloaded from CoinDesk http://www.coindesk.com/price/ It is the CoinDesk BPI. The difficulty data going back to January 3, 2009 can also be downloaded also from CoinDesk http://www.coindesk.com/data/bitcoin-mining-difficulty-time/. In both cases click on Export in the chart and select CSV Chart Data. There was some Bitcoin trading before July 18, 2010 on New Liberty Standard and Bitcoin Market both of which have gone defunct. The New Liberty Standard site is still up with the 2009 data. http://newlibertystandard.wikifoundry.com/page/2009+Exchange+Rate however the early 2010 data is now gone. I did manage to download the early 2010 data in November 2013 before it was lost. Send me a PM and I can send the file. LibreOffice (.ods) format only to preserve the download timestamp.

One thing to keep in mind is that difficulty measure price in terms of computing resources. As for the time period for Bitcoin the best is 2010 - 2012. Still there is an evolution here from CPU, GPU and then some FPGA before ASIC mining. One other option that would be clean is actually Monero over the last 14 months since in the Monero case the technology has not changed.