Bitcoin Forum
June 23, 2024, 12:24:39 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 5 6 7 8 »  All
  Print  
Author Topic: [XMR] Monero Improvement Technical Discussion  (Read 14668 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
GingerAle (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile WWW
July 31, 2015, 01:48:40 PM
Last edit: July 31, 2015, 04:23:57 PM by GingerAle
 #1

I grow weary of the constant trolling, inverse trolling, talk of "investing", nonsense etc. This is cool software / technology that happens to be explicitly tied to money.

This thread is about Monero technical ideas, discussion, ONLY. If you barge in here with something non-technical, I will delete it. This is not a support thread. I will point you in the right direction, then delete your post.

Yes, you might say "there's a monero specific forum at forum.getmonero.org". Yes there is. People don't use it for their own reasons.

My first post will be a copy of the discussion smooth and I were having regarding trying to figure out how to automodify the minimum fees. I hope that this cleaner thread will spur more actual discussion as opposed to the neverending "woh look market cap! hey I have a scam detector! who wants some spam?"


< Track your bitcoins! > < Track them again! > <<< [url=https://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/] What is fungibility? >>> 46P88uZ4edEgsk7iKQUGu2FUDYcdHm2HtLFiGLp1inG4e4f9PTb4mbHWYWFZGYUeQidJ8hFym2WUmWc p34X8HHmFS2LXJkf <<< Free subdomains at moneroworld.com!! >>> <<< If you don't want to run your own node, point your wallet to node.moneroworld.com, and get connected to a random node! @@@@ FUCK ALL THE PROFITEERS! PROOF OF WORK OR ITS A SCAM !!! @@@@
GingerAle (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile WWW
July 31, 2015, 01:48:51 PM
 #2

Well, now that thats all over, lets talk about something fun!!!

I've been trying to wrap my head around how to convert the fee calculation to something dynamic that wouldn't require human intervention.

As far as I understand, the primary reason the fees exist is to prevent blockchain spamming (and mining incentive). So Monero has some minimum fee thats based on the size of the transaction. I'm sure you've noticed how this works if you've tried to clean up some dust using Moneromoo's recent simplewallet enhancements (2.3 XMR to cleanup 5xmr of dust wuuuuut)

Currently, the fee is 0.01 xmr / kb as writ here: https://forum.getmonero.org/1/news-and-announcements/91/monday-monero-missives-17-november-2nd-2014

Now this is all fine and dandy except when Monero shoots to the moon (1 xmr = $1000), because an increase in price doesn't mean the size of the transactions will decrease. A transaction to send 0.045 XMR will use the same space (well, probably more depending on mixin availability) as a transaction to send 45 XMR (more or less).

Obviously, the easiest solution is to modify the code by hand (the devs intervene), and there will be plenty of incentive to do so - the cost of transacting will decrease the utility of Monero - the coin has become worth a lot, but it is really expensive to use, so people just hold it. But when humans intervene, you end up with all the nonsense associated with humans. Miners might not want to switch because they're raking in profits. The monero-as-asset crowd will rally for not changing the protocol because transaction friction could actually increase the value of an asset ( perhaps ).

All-in-all, the modifying-the-fee-using-human-intervention is the antithesis of cryptocurrency. Again, the goal of cryptocurrency is to remove as much of human element as possible.

So, how could we do that?

I don't think its possible to somehow link the protocol to some type of oracle - i.e., the protocol somehow gets data input from some external source. For example, you could imagine the protocol gets a feed from some XMR / fiat exchange. I don't think this is possible primarily because it depends on factors exterior to the protocol.

I think we would have to stick with data that exists within the protocol / blockchain. Specifically, I think these are the data we can use:

t = Transaction frequency = number of transactions per block
a = transaction amount = the amount of XMR actually transacted in a given transaction


Using these data, I think something could be written that would achieve goal of increasing the XMR cost of a transaction when fiat value is low, and decreasing the XMR cost of a transaction when fiat value is high.

Essentially, when the transaction frequency is low and the transaction amount is high, one could infer that the fiat value of XMR is low.

Conversely, when the transaction frequency is high and the transaction amount is low, one could infer that the fiat value of XMR is high.


Obviously, some sort of rolling window would be used to aggregate an average of these data.

I've been trying to wrap my head around how to convert the fee calculation to something dynamic that wouldn't require human intervention.

This is a useful and interesting effort but keep in mind there are at least four different tx fees:

1. The fee required for relaying by nodes.

2. The default fee set in the code for miners to include a transaction.

3. The default fee set in the code for those sending a transaction.

4. The actual fee at which miners include transactions in practice.

The first is a network function that prevents spamming the p2p network as a DoS attack. It should not really be much less than #4 because that allows spamming the p2p without any real cost (the spammer wouldn't actually pay the fee because the tx wouldn't get mined). It can't be changed (either higher or lower) by individual nodes because if they violate the rule expected by other nodes they will get disconnected.

The second is a default in the code and miners can change it if they want (currently this would require recompiling the source code, but other options may be added later), though setting it lower than #1 would not result in any more transactions being mined since they won't be sent over the p2p UNLESS the miner gets these transactions via another channel, or creates them.

The third is a default in the code and users could change it if they want (currently this would require recompiling the source code, but other options may be added later). If this is set lower than #1, the transaction will be rejected by nodes.

The fourth is entirely a market phenomenon that is a balance between supply, demand, and the fee policies set by users and miners.


EDIT: fixed typo "much much" -> "much less"

I've been trying to wrap my head around how to convert the fee calculation to something dynamic that wouldn't require human intervention.

This is a useful and interesting effort but keep in mind there are at least four different tx fees:

1. The fee required for relaying by nodes.

2. The default fee set in the code for miners to include a transaction.

3. The default fee set in the code for those sending a transaction.

4. The actual fee at which miners include transactions in practice.

The first is a network function that prevents spamming the p2p network as a DoS attack. It should not really be much much than #4 because that allows spamming the p2p without any real cost (the spammer wouldn't actually pay the fee because the tx wouldn't get mined). It can't be changed (either higher or lower) by individual nodes because if they violate the rule expected by other nodes they will get disconnected.

The second is a default in the code and miners can change it if they want (currently this would require recompiling the source code, but other options may be added later), though setting it lower than #1 would not result in any more transactions being mined since they won't be sent over the p2p UNLESS the miner gets these transactions via another channel, or creates them.

The third is a default in the code and users could change it if they want (currently this would require recompiling the source code, but other options may be added later). If this is set lower than #1, the transaction will be rejected by nodes.

The fourth is entirely a market phenomenon that is a balance between supply, demand, and the fee policies set by users and miners.



So the fee that I'm talking about would be #1 - the fee required for relay by nodes. I'm not sure I'm parsing what you write in the above bold -  so the spammer could spam just by bloating the mempool? I think the confusing part is the mis-type of "much much", which could be "much less" or "much more", and this is a key piece of data.

I'm assuming its much less.

blue text = but couldn't each individual node recalculate the minimum value based on data on the blockchain? So then all nodes will be in agreement, because they're all making the same calculation off the same blockchain.

If I'm reading you right, the primary protocol-induced fee is #1. Is this fee what I understand as the per-kb fee?

So the fee that I'm talking about would be #1 - the fee required for relay by nodes. I'm not sure I'm parsing what you write in the above bold -  so the spammer could spam just by bloating the mempool? I think the confusing part is the mis-type of "much much", which could be "much less" or "much more", and this is a key piece of data.

Yes exactly, not only the mempool but bandwidth used by every node to relay the transactions.

I'll go back and fix the typo but the idea is that if you broadcast a transaction it should have a significant chance of actually being mined.

Quote
If I'm reading you right, the primary protocol-induced fee is #1. Is this fee what I understand as the per-kb fee?

I'm not sure I would agree that one or another is "primary" protocol-induced. They are all important to the protocol (the process of mining, for example, is certainly part of the protocol), but they are different and interrelated. They're all per-kb in the current implementation.

So the fee that I'm talking about would be #1 - the fee required for relay by nodes. I'm not sure I'm parsing what you write in the above bold -  so the spammer could spam just by bloating the mempool? I think the confusing part is the mis-type of "much much", which could be "much less" or "much more", and this is a key piece of data.

Yes exactly, not only the mempool but bandwidth used by every node to relay the transactions.

I'll go back and fix the typo but the idea is that if you broadcast a transaction it should have a significant chance of actually being mined.

Quote
If I'm reading you right, the primary protocol-induced fee is #1. Is this fee what I understand as the per-kb fee?

I'm not sure I would agree that one or another is "primary" protocol-induced. They are all important to the protocol (the process of mining, for example, is certainly part of the protocol), but they are different and interrelated. They're all per-kb in the current implementation.

So the fee that I'm talking about would be #1 - the fee required for relay by nodes. I'm not sure I'm parsing what you write in the above bold -  so the spammer could spam just by bloating the mempool? I think the confusing part is the mis-type of "much much", which could be "much less" or "much more", and this is a key piece of data.

Yes exactly, not only the mempool but bandwidth used by every node to relay the transactions.

I'll go back and fix the typo but the idea is that if you broadcast a transaction it should have a significant chance of actually being mined.

Quote
If I'm reading you right, the primary protocol-induced fee is #1. Is this fee what I understand as the per-kb fee?

I'm not sure I would agree that one or another is "primary" protocol-induced. They are all important to the protocol (the process of mining, for example, is certainly part of the protocol), but they are different and interrelated. They're all per-kb in the current implementation.

gotcha gotcha. I think I'm picking up what you're putting down.

Basically, you're saying that if some kind of algorithmic floating number were to be implemented, we would have to find a way to harmonize it across those 4 different elements. Well, really, elements 1,2, and 3. What miners decide ( #4) has to be >= 1,2,3 .

And changing the fees would require recompiling the source code.

I would imagine it would work something like this:

When a block is mined, a new piece of data (activity) is stored in the header. This piece of data (calculated by the miner) is something like 

activity = (sum of number of transactions in n recent blocks) X (total amount in transactions in n recent blocks) / (n recent blocks)

We'll have to figure out exactly what the function X is.

When new block is made, every miner can validate that activity value was properly calculated.

(1) When determining whether to propagate a transaction, the daemon can use the most recent activity value in its calculation of minimum fee.

(2) When determining whether to include a transaction, the mining code can use the value in its calculation

(3) When making a transaction, simplewallet can use the activity value to make its calculation of minimum fee.

Sure, we've added more data to each block, but I think Monero is fond of the notion of increased protocol utility vs. concerns over blockchain size. And yes, Monero is sentient and can be fond of things.

Hrm, you would also have to make the floating minimum a range, not a fixed value.

Ff the precisely calculated minimum is 0.01211 xmr / kb, and by the time your transaction is made and sent to the network, the new precisely calculated minimum is 0.01213 xmr / kb, that won't work.

instead, you would have some range around the precise minimum. This range itself would have to be dynamic, but that could be easy... just use the rate of the delta for the minimum. I.e., if over n blocks the minimum moved 0.0004 xmr, then thats the range. (or something like this)

< Track your bitcoins! > < Track them again! > <<< [url=https://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/] What is fungibility? >>> 46P88uZ4edEgsk7iKQUGu2FUDYcdHm2HtLFiGLp1inG4e4f9PTb4mbHWYWFZGYUeQidJ8hFym2WUmWc p34X8HHmFS2LXJkf <<< Free subdomains at moneroworld.com!! >>> <<< If you don't want to run your own node, point your wallet to node.moneroworld.com, and get connected to a random node! @@@@ FUCK ALL THE PROFITEERS! PROOF OF WORK OR ITS A SCAM !!! @@@@
GingerAle (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile WWW
July 31, 2015, 03:51:22 PM
 #3

Lots of posts deleted because they were not technical.

< Track your bitcoins! > < Track them again! > <<< [url=https://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/] What is fungibility? >>> 46P88uZ4edEgsk7iKQUGu2FUDYcdHm2HtLFiGLp1inG4e4f9PTb4mbHWYWFZGYUeQidJ8hFym2WUmWc p34X8HHmFS2LXJkf <<< Free subdomains at moneroworld.com!! >>> <<< If you don't want to run your own node, point your wallet to node.moneroworld.com, and get connected to a random node! @@@@ FUCK ALL THE PROFITEERS! PROOF OF WORK OR ITS A SCAM !!! @@@@
luigi1111
Legendary
*
Offline Offline

Activity: 1105
Merit: 1000



View Profile
July 31, 2015, 03:57:46 PM
Last edit: July 31, 2015, 04:21:13 PM by luigi1111
 #4

Lots of posts deleted because they were not technical.

So pretty. I haven't any useful input on fees.

What do people think about serialized stealth payment IDs versus unique spend keys with single viewkey?

Edit: try to keep up! Cheesy

Edit2: maybe you should change title to "[XMR] Monero Improvement Technical Discussion" or something.
GingerAle (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile WWW
July 31, 2015, 04:28:27 PM
 #5

Lots of posts deleted because they were not technical.

So pretty. I haven't any useful input on fees.

What do people think about serialized stealth payment IDs versus unique spend keys with single viewkey?

Edit: try to keep up! Cheesy

Edit2: maybe you should change title to "[XMR] Monero Improvement Technical Discussion" or something.

I don't understand .....'

good idea on the thread title change.

< Track your bitcoins! > < Track them again! > <<< [url=https://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/] What is fungibility? >>> 46P88uZ4edEgsk7iKQUGu2FUDYcdHm2HtLFiGLp1inG4e4f9PTb4mbHWYWFZGYUeQidJ8hFym2WUmWc p34X8HHmFS2LXJkf <<< Free subdomains at moneroworld.com!! >>> <<< If you don't want to run your own node, point your wallet to node.moneroworld.com, and get connected to a random node! @@@@ FUCK ALL THE PROFITEERS! PROOF OF WORK OR ITS A SCAM !!! @@@@
kazuki49
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250



View Profile
July 31, 2015, 04:32:36 PM
 #6

Obligatory reading, how Monero identified some weakness and proposed changes to betterment of the cryptonote protocol:

https://lab.getmonero.org/pubs/MRL-0001.pdf
https://lab.getmonero.org/pubs/MRL-0002.pdf
https://lab.getmonero.org/pubs/MRL-0003.pdf
https://lab.getmonero.org/pubs/MRL-0004.pdf
luigi1111
Legendary
*
Offline Offline

Activity: 1105
Merit: 1000



View Profile
July 31, 2015, 04:41:52 PM
 #7

Lots of posts deleted because they were not technical.

So pretty. I haven't any useful input on fees.

What do people think about serialized stealth payment IDs versus unique spend keys with single viewkey?

Edit: try to keep up! Cheesy

Edit2: maybe you should change title to "[XMR] Monero Improvement Technical Discussion" or something.

I don't understand .....'

good idea on the thread title change.

The new Bytecoin "breakthrough", where they're "depreciating" payment IDs. It is a potential solution, and I'd be really interested in seeing an actual cost analysis instead of generalities.
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
July 31, 2015, 05:10:28 PM
 #8

Lots of posts deleted because they were not technical.

So pretty. I haven't any useful input on fees.

What do people think about serialized stealth payment IDs versus unique spend keys with single viewkey?

Edit: try to keep up! Cheesy

Edit2: maybe you should change title to "[XMR] Monero Improvement Technical Discussion" or something.

I don't understand .....'

good idea on the thread title change.

The new Bytecoin "breakthrough", where they're "depreciating" payment IDs. It is a potential solution, and I'd be really interested in seeing an actual cost analysis instead of generalities.

The idea is to have one view key with multiple spend keys. That gives you multiple public keys (addresses) where half is common and half is unique. This allows scanning for all of these addresses much more quickly than scanning for completely different addresses (for the use case of an exchange or web wallet where each user has his own address -- instead of the current practice of one exchange address plus payment IDs).



MalMen
Member
**
Offline Offline

Activity: 95
Merit: 10


View Profile
July 31, 2015, 05:20:36 PM
 #9

The idea is to have one view key with multiple spend keys. That gives you multiple public keys (addresses) where half is common and half is unique. This allows scanning for all of these addresses much more quickly than scanning for completely different addresses (for the use case of an exchange or web wallet where each user has his own address -- instead of the current practice of one exchange address plus payment IDs).

So one viewkey for multiple spendkeys, is that what bytecoin is doing ? I am more favorable to this option rather than payment_id
luigi1111
Legendary
*
Offline Offline

Activity: 1105
Merit: 1000



View Profile
July 31, 2015, 05:46:40 PM
 #10

Lots of posts deleted because they were not technical.

So pretty. I haven't any useful input on fees.

What do people think about serialized stealth payment IDs versus unique spend keys with single viewkey?

Edit: try to keep up! Cheesy

Edit2: maybe you should change title to "[XMR] Monero Improvement Technical Discussion" or something.

I don't understand .....'

good idea on the thread title change.

The new Bytecoin "breakthrough", where they're "depreciating" payment IDs. It is a potential solution, and I'd be really interested in seeing an actual cost analysis instead of generalities.

The idea is to have one view key with multiple spend keys. That gives you multiple public keys (addresses) where half is common and half is unique. This allows scanning for all of these addresses much more quickly than scanning for completely different addresses (for the use case of an exchange or web wallet where each user has his own address -- instead of the current practice of one exchange address plus payment IDs).



Yes indeed. Sorry, I didn't really mean to come across as snarky (not sure if I did).

Neither of these change any consensus rules in any way, they're just attempts to recommend standards for recipients to differentiate payments.

smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
July 31, 2015, 05:52:26 PM
 #11

Removing support for payment IDs entirely could be a consensus change. I have no idea if they intend that.

The transaction format could be made a lot cleaner if tx_extra were remove and a fixed size transaction-key field were added instead. Plus it would remove one obvious way for scumbags to stuff kiddie porn on the blockchain.

fluffypony
Donator
Legendary
*
Offline Offline

Activity: 1274
Merit: 1060


GetMonero.org / MyMonero.com


View Profile WWW
July 31, 2015, 06:49:23 PM
 #12

Removing support for payment IDs entirely could be a consensus change. I have no idea if they intend that.

The transaction format could be made a lot cleaner if tx_extra were remove and a fixed size transaction-key field were added instead. Plus it would remove one obvious way for scumbags to stuff kiddie porn on the blockchain.

I would 100% support dropping tx_extra *if* we have MoneroAsset etc. duaghter-chains to deal with the metadata normally stuffed into mainchain. Having a separate optional output (or tx) identifier is a good replacement.

GingerAle (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile WWW
August 01, 2015, 03:04:59 AM
 #13

Removing support for payment IDs entirely could be a consensus change. I have no idea if they intend that.

The transaction format could be made a lot cleaner if tx_extra were remove and a fixed size transaction-key field were added instead. Plus it would remove one obvious way for scumbags to stuff kiddie porn on the blockchain.

I would 100% support dropping tx_extra *if* we have MoneroAsset etc. duaghter-chains to deal with the metadata normally stuffed into mainchain. Having a separate optional output (or tx) identifier is a good replacement.

I would support the development of a MoneroAsset daughter chain, especially if it enabled refining the primary currency chain. Removing the ability to use the primary currency chain as more than what its supposed to be - accounting - would be very beneficial, IMO. Especially because Monero already has to deal with an inherently larger blockchain with interesting hurdles for pruning. Having separate chains would also make it explicitly simpler to differentiate between the everyday user (someone who runs a currency-only node) vs. enthusiasts or vested interests running multiple chains. Of course, incentivizing maintenance of the daughter chain is a different beast, unless I'm not understanding daughter chains properly.

Yeah, generally, I feel that trying to multipurpose the ledger is something to be avoided - especially in the case of Monero where the data is cryptographically obscured. I don't think every blockchain should be viewed as an oppurtunity for data storage - "metadata normally stuffed into the mainchain". The primary currency chain should be just that - a ledger where it is indicated that I sent n things to someone else. Keep it simple stupid.

and yes, preventing kiddie porn on the blockchain is always a good thing.

damnit I wish I knew how to code so I could get the data from the blockchain to try and come up with a formula for the floating minimum fee adjustment proposal outlined above. Gah. It'd be fun to make pretty graphs.

< Track your bitcoins! > < Track them again! > <<< [url=https://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/] What is fungibility? >>> 46P88uZ4edEgsk7iKQUGu2FUDYcdHm2HtLFiGLp1inG4e4f9PTb4mbHWYWFZGYUeQidJ8hFym2WUmWc p34X8HHmFS2LXJkf <<< Free subdomains at moneroworld.com!! >>> <<< If you don't want to run your own node, point your wallet to node.moneroworld.com, and get connected to a random node! @@@@ FUCK ALL THE PROFITEERS! PROOF OF WORK OR ITS A SCAM !!! @@@@
GingerAle (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile WWW
August 03, 2015, 11:04:01 AM
 #14

I wonder if there's a way to make morphing POW code, such that every n years the POW function gets modified.

This would prevent mining centralization, and do so in a way that avoids politics, because changing the POW would definitely cause an uproar from the mining camp.

In the case that ASICS *are* developed for Monero, this would disrupt that significantly.
If the only thing that exists in 10 years are GPU operations, then it would only disrupt it in terms of software development.
if the only thing is CPU mining, then all it would do is cement further CPU mining.

< Track your bitcoins! > < Track them again! > <<< [url=https://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/] What is fungibility? >>> 46P88uZ4edEgsk7iKQUGu2FUDYcdHm2HtLFiGLp1inG4e4f9PTb4mbHWYWFZGYUeQidJ8hFym2WUmWc p34X8HHmFS2LXJkf <<< Free subdomains at moneroworld.com!! >>> <<< If you don't want to run your own node, point your wallet to node.moneroworld.com, and get connected to a random node! @@@@ FUCK ALL THE PROFITEERS! PROOF OF WORK OR ITS A SCAM !!! @@@@
poloskarted
Member
**
Offline Offline

Activity: 63
Merit: 10


View Profile
August 03, 2015, 11:36:09 AM
 #15

I wonder if there's a way to make morphing POW code, such that every n years the POW function gets modified.

This would prevent mining centralization, and do so in a way that avoids politics, because changing the POW would definitely cause an uproar from the mining camp.

In the case that ASICS *are* developed for Monero, this would disrupt that significantly.
If the only thing that exists in 10 years are GPU operations, then it would only disrupt it in terms of software development.
if the only thing is CPU mining, then all it would do is cement further CPU mining.


The following approaches, being IO bound with a changing dataset achieve "some" extra level of polymorphism and although the PoW as it stands has strong merits for ASIC resistance, IMO they improve upon it somewhat.


http://boolberry.com/files/Block_Chain_Based_Proof_of_Work.pdf
https://github.com/ethereum/wiki/wiki/Ethash

For instance, in the case of the blockchain PoW (wild keccak) faster verification resulting in faster syncing. I believe last year someone conducted a test in an infographic for initial blockchain download and XMR was 200+ minutes, whereas BBR came in at about 13 minutes.  I'm trying to find where it was posted.

 I can't conceive a situation at the cryptonote protocol level where you could randomly switch algo's outright though. Voting through forks would be inelegant and cause much disruption.  Much like modifiying the emission curve, even if it was practical on a technical level, it would seem that it would far from ideal from an econ standpoint. You can't just switch what people signed up for retroactively.

  Also, you cannot ever stop the tendency to drift towards mining centralization- even the classic notion of 1 CPU, 1 Vote can be abused by sysadmins, botnet owners etc, AWS cowboys. I know this well as I was mining BTC before there were optimized CPU miners- and no GPU miners nor pools, and it was not even called mining, but "Generating'. It was always centralized to some degree.  With the rolling snowball effect of those who are profiting ploughing in more towards expansion you can only ever attempt to stave off specialized custom silicon.

GingerAle (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile WWW
August 03, 2015, 11:58:52 AM
 #16

I wonder if there's a way to make morphing POW code, such that every n years the POW function gets modified.

This would prevent mining centralization, and do so in a way that avoids politics, because changing the POW would definitely cause an uproar from the mining camp.

In the case that ASICS *are* developed for Monero, this would disrupt that significantly.
If the only thing that exists in 10 years are GPU operations, then it would only disrupt it in terms of software development.
if the only thing is CPU mining, then all it would do is cement further CPU mining.


The following approaches, being IO bound with a changing dataset achieve "some" extra level of polymorphism and although the PoW as it stands has strong merits for ASIC resistance, IMO they improve upon it somewhat.


http://boolberry.com/files/Block_Chain_Based_Proof_of_Work.pdf
https://github.com/ethereum/wiki/wiki/Ethash

For instance, in the case of the blockchain PoW (wild keccak) faster verification resulting in faster syncing. I believe last year someone conducted a test in an infographic for initial blockchain download and XMR was 200+ minutes, whereas BBR came in at about 13 minutes.  I'm trying to find where it was posted.

 I can't conceive a situation at the cryptonote protocol level where you could randomly switch algo's outright though. Voting through forks would be inelegant and cause much disruption.  Much like modifiying the emission curve, even if it was practical on a technical level, it would seem that it would far from ideal from an econ standpoint. You can't just switch what people signed up for retroactively.

  Also, you cannot ever stop the tendency to drift towards mining centralization- even the classic notion of 1 CPU, 1 Vote can be abused by sysadmins, botnet owners etc, AWS cowboys. I know this well as I was mining BTC before there were optimized CPU miners- and no GPU miners nor pools, and it was not even called mining, but "Generating'. It was always centralized to some degree.  With the rolling snowball effect of those who are profiting ploughing in more towards expansion you can only ever attempt to stave off specialized custom silicon.



Cool, thanks for those links - will read up on them and try to understand them!!

re: the first bold, I agree, which is why these things would need to be done before things get too cemented. Furthermore, one of the pillars of Monero is decentralization - so I tend to believe that efforts would be made to maintain decentralization even at the cost of switching things as fundamental as the POW.

re: second bold - I agree to a degree ( snarf ), but its the "some degree" that matters, IMO. At the existing difficulty, it is still possible for your average PC consumer to mine monero, even though there are probably definitely botnets, AWS cowboys, and sysadmins already on the network. This is *not* the case with bitcoin and soon to be litecoin with the scrypt asic development.

re: third bold: e x a c t l y. thats what a theoretical polymorphism would do. A guarantted 10 year window where its guaranteed that the only thing that will work is a CPU.... granted, its impossible to know CPU architecture in the future.... but, we got math.

and there will soon be a missive detailing your point re: voting through forks, if I understood correctly.


< Track your bitcoins! > < Track them again! > <<< [url=https://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/] What is fungibility? >>> 46P88uZ4edEgsk7iKQUGu2FUDYcdHm2HtLFiGLp1inG4e4f9PTb4mbHWYWFZGYUeQidJ8hFym2WUmWc p34X8HHmFS2LXJkf <<< Free subdomains at moneroworld.com!! >>> <<< If you don't want to run your own node, point your wallet to node.moneroworld.com, and get connected to a random node! @@@@ FUCK ALL THE PROFITEERS! PROOF OF WORK OR ITS A SCAM !!! @@@@
Hueristic
Legendary
*
Offline Offline

Activity: 3850
Merit: 5030


Doomed to see the future and unable to prevent it


View Profile
August 10, 2015, 03:33:20 PM
 #17

Removing support for payment IDs entirely could be a consensus change. I have no idea if they intend that.

The transaction format could be made a lot cleaner if tx_extra were remove and a fixed size transaction-key field were added instead. Plus it would remove one obvious way for scumbags to stuff kiddie porn on the blockchain.



Shit, only skimmed this thread but this popped out at me. Is there that shit on the chain right now or are you warning of a possibility? Is anyone with the chain getting setup? To remove would take a hard fork prune?

How about adding a option to boycott specific transaction meta data and maintaining a blacklist? Is there another place where this is being discussed?

“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
August 10, 2015, 04:03:17 PM
 #18

Removing support for payment IDs entirely could be a consensus change. I have no idea if they intend that.

The transaction format could be made a lot cleaner if tx_extra were remove and a fixed size transaction-key field were added instead. Plus it would remove one obvious way for scumbags to stuff kiddie porn on the blockchain.



Shit, only skimmed this thread but this popped out at me. Is there that shit on the chain right now or are you warning of a possibility? Is anyone with the chain getting setup? To remove would take a hard fork prune?

How about adding a option to boycott specific transaction meta data and maintaining a blacklist? Is there another place where this is being discussed?

It's been discussion countless times on this forum and elsewhere in the context of Bitcoin (which indeed does have some nasty stuff on its blockchain) and possibly other coins. There isn't really a good solution, but there are less bad solutions.


GingerAle (OP)
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile WWW
August 10, 2015, 04:34:00 PM
 #19

RE: POW mod.

It seems that cryptonight is fighting the good fight re: maintaining CPU dominance with few benefits of GPU (besides hardware configuration scalability). From what I understand, it does this by being "memory-hard" - i.e., requiring fast access to memory to be efficient. Today's CPUs are designed with fast access memory built in (the L3 cache), wherein GPUs have high bandwidth memory but not necessarily fast memory (random read/write)

I know aeon recently modded cryptonight to a lower memory requirement (1 Mb per instance).

I wonder if the algorithm could be modified so this parameter is slowly adaptive. While its impossible to know how hardware will evolve, the general architecture evolution has been to get faster memory closer to the CPU (apparently new chips have L4 cache).

I.e., whatever factor causes the algorithm to require 2 mb (or 1 in the case of aeon), could be modified to increase over time.... talking on the scale of decades, wherein over 10 years the memory requirement would go from 2 MB to 3 MB.. of course, to be dated using blocktime.  Or maybe it should be exponential to follow the actual evolution of CPU cache.




So what would this do? On one hand, it wouldn't do much besides make outdated hardware useless. In a world without the adaptive tech, people with old hardware would get less of the network hashrate, because newer tech has larger / faster cache. In a world with adaptive tech, people with old hardware get less of the network hashrate, because the algorithm has changed to become harder. So, I think things are equal on this front.

What it does do is prohibit useful development of asics. And asics that are developed have a limited useful shelf life. Perhaps I will compare cryptonite light with standard to see where that parameter is.

Of course, this ties the POW to a function of time, which could get tricky. But I think that would be the easiest implementation of an adaptive system. Otherwise, we would have to make the protocol "sentient" in some fashion, and these could all be gamed - e.g., the protocol "knows" how frequently particular miners are being rewarded, and infers centralization.

< Track your bitcoins! > < Track them again! > <<< [url=https://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/] What is fungibility? >>> 46P88uZ4edEgsk7iKQUGu2FUDYcdHm2HtLFiGLp1inG4e4f9PTb4mbHWYWFZGYUeQidJ8hFym2WUmWc p34X8HHmFS2LXJkf <<< Free subdomains at moneroworld.com!! >>> <<< If you don't want to run your own node, point your wallet to node.moneroworld.com, and get connected to a random node! @@@@ FUCK ALL THE PROFITEERS! PROOF OF WORK OR ITS A SCAM !!! @@@@
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
August 10, 2015, 05:23:05 PM
 #20

The actual cache size is less important than cache per core. That seems to have been fairly constant over a several year period (i.e. more cores and more cache both over time). How far into the future that will continue Huh
 
Whether L4 is worth using for this is unclear. It is about half the speed of L3. That probably translates into lower hash/watt, so kinda bad.

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

Pages: [1] 2 3 4 5 6 7 8 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!