[XMR] Monero Improvement Technical Discussion

[ArticMine]

...
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.

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.

[1714853665]

1714853665

[1714853665]

1714853665

[1714853665]

1714853665

[1714853665]

1714853665

[1714853665]

1714853665

[1714853665]

1714853665

[smooth]

...
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.

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.

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.

[GingerAle]

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.

[GingerAle]

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!

[smooth]

because you need the entire blockchain to craft a transaction, in order for the wallet to pick some outputs to mix with.

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.

[GingerAle]

because you need the entire blockchain to craft a transaction, in order for the wallet to pick some outputs to mix with.

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

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

[MoneroMooo]

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.

[smooth]

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.

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.

[GingerAle]

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

[owm123]

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

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?

[GingerAle]

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

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?

bah BAM!

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

Tor is optimised for low-bandwidth clients and high-bandwidth exit nodes, whereas i2p is optimised for internal hidden services. Thus, i2p is significantly faster when routing internal traffic.

i2p's floodfill routers (roughly analogous to Tor's directory servers) aren't hardcoded

i2p is a packet-switched network (as opposed to circuit-switched) which makes it more robust
no client-only peers, all peers route traffic and assist in building and running short-lived tunnels

TCP and UDP are supported, which means that things like OpenAlias can still work over i2p

[smooth]

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

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?

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

[owm123]

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

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?

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

Any idea when i2p support will be implemented into Monero?

[GingerAle]

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

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

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

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.

[GingerAle]

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.

[smooth]

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.

Yes there are various proposals like that

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

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

[tromp]

The next attempt at an improvement over Scrypt was (which I wrote down in 2013 well before the Cryptonite proof-of-work hash was published) was to not just read pseudo-randomly as described above, but to write new pseudo-random values to each pseudo-randomly accessed location. This defeats storing only every Nth random access location. However it is still possible to trade latency for computation by only storing the location that was accessed to compute the value to store instead of storing the entire value. The compute bound version of the algorithm can not be defeated by reading numerous locations before storing a value because the starting seed need only be stored.

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

Thus I concluded it is always possible to trade computation for latency in any memory-hard hash function.

Why limit yourself to hash functions? See

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

[tromp]

An algorithm with a much bigger memory footprint, like cuckoo, without a corresponding increase in verification time, might be sized for L4 though.

This focus on cache sizes may be unwarranted.

If you benchmark Cuckoo Cycle for increasing memory sizes,
you only see a small slowdown in access latency(~40%) when moving from
fitting in the 12MB/core on-chip cache to moving way beyond that.

[smooth]

An algorithm with a much bigger memory footprint, like cuckoo, without a corresponding increase in verification time, might be sized for L4 though.

This focus on cache sizes may be unwarranted.

If you benchmark Cuckoo Cycle for increasing memory sizes,
you only see a small slowdown in access latency(~40%) when moving from
fitting in the 12MB/core on-chip cache to moving way beyond that.

Yup. I think I was the one who pointed that out to you.

My point in mentioning cache is that cache benefits from physical proximity. You can't put two things in the same space, so if you want to introduce more parallelism (horizontal or vertical) in the processing elements you will have to move the memory farther away, incurring a cost, certainly in latency and probably in power usage too. Okay the cost may not be that large, but it does exist, and becomes an obstacle to overcome before even breaking even.

Obviously things like more use of 3D in microelectronics will shift the numbers around but the principle of finite proximal space will remain.

[GingerAle]

just an idea that just burbled up in my mind. Posting for 2 reasons - if it exists, someone will come in and go "someone already thought of this". Or if it doesn't exist, someone will go "it won't work because X"

Integrate an Audio signal into the POW function (somehow)

Rationale: all personal computing devices have audio hardware. There might be a way to use the audio signal to create a fingerprint of the individual computer that will prohibit pooling.

I imagine it as such, though this could be totally off due to an incomplete understanding of POW / pooling protocols.

The mining algorithm starts to attempt to find a solution for a block. Upon starting of this function, an audio recording is initiated (recording a wav file). No microphone would be needed - no audio board will read true silence in the circuitry, so the wav recording will contain electronic noise. Each time a block solution is attempted, a hash of the wav file is included in the hash of the POW. So basically, the duration of the current attempt to find a block solution will equal the duration of the wav file to find a solution. (that matters somehow... I can't figure out why)

Maybe? Perhaps?