Page 1 of 1
Hardfork Wishlist
Posted: Sun May 18, 2014 12:36 am
by midnightmagic
Pointers to information re: fairly uncontroversial hardfork wishlist items
https://en.bitcoin.it/wiki/User:Gmaxwel ... sucks_less
And we should correct the merged-mining chain_id awkwardness:
https://en.bitcoin.it/wiki/Merged_minin ... erkle_tree
Re: Hardfork Wishlist
Posted: Mon May 19, 2014 4:48 am
by John Kenney
gmaxwell's suggestion for storing key=value data isn't well thought out, it'd make namecoin suck more by adding unnecessary overhead & weak (false) security. Simple improvement for storing a private data verification in the blockchain should be hash(data+sig), the sig should add enough entropy to the data to make it hard to brute force/dictionary attack. Doesn't require a fork either.
I'd like to enforce some simple rules on what can be added to the blockchain to make it easier to parse, like enforcing valid json.
I'd also like changes to make WoT verification work easier.
Re: Hardfork Wishlist
Posted: Mon May 19, 2014 11:19 am
by virtual_master
We have already discussed in other threads gmaxwell's idea and some other related possibilities however at is no need for that at all at the moment.
He had a very good suggestion but they are other solutions also. Beside of the hardfork related risks exists other disadvantages also.
This could change when we raise the transaction size limit above a certain limit(which is still disputed if it is 2kB or 5kB) but in that case it will be necessary anyway to make a hardfork.
Re: Hardfork Wishlist
Posted: Tue May 20, 2014 12:59 am
by John Kenney
Increased fees for name_new
Renewal fees and/or increased fees for name_update
Re: Hardfork Wishlist
Posted: Tue May 20, 2014 9:25 am
by midnightmagic
What you're describing as "entropy" is just an additional speedbump for people who are willing to mine to store arbitrary data in the result. You increase or decrease the speedbump, and if you do it incorrectly, the effort is wasted, while the side-effects we have to live with until the next hardfork. You're not going to stop spammer jerks from mining to store arbitrary data in the blockchain no matter how complex you make it to do so. If they control any aspects of the input, they will be able to mine for something specific in the output.
The only way to make most of the changes people want is to hardfork. There is no other way.
The current larger holders in namecoin (and all their mining power) will simply not follow you into a land where you're destroying their investment in namecoin by making it impossible for them to maintain their ownership stake. But! Every single one of them will follow you if you incentivize their participation in FutureNamecoin by protecting their current investments.
There is no way to prevent what you're calling squatters. If you make it more expensive to "squat" it'll just be a system where the squatters will begin monetizing their squatting in earnest in order to make their investment maintain itself.
It is a bad idea to make name_update more expensive. It is an excellent idea to make name_new more expensive.
Remember: ass long as it's open source, people can choose to keep running the old one; or, choose to backport improvements, and keep running the old one, because inertia.
Re: Hardfork Wishlist
Posted: Sun Jun 08, 2014 9:05 pm
by John Kenney
Entropy is defined as data it'd be hard for an attacker to guess, the number of combinations you'd need to try to do a brute force search. Getting a private key from a hashed signature is no simple speedbump, it'd be totally breaking crypto & you'd need to do that first to be able to brute force a signature to get the data. My goal for a similar type of feature isn't to prevent spammer jerks, it's to allow the storage of private data in the blockchain & prevent attackers reversing it to get the plain text, which could be very easy if the data is easy to guess, under gmaxwell's hash scheme. If it's a signature instead, that makes it near-impossible (I think). I also think it could be added as an optional feature available in nmcontrol & whatever gui wallet we'll be using, not requiring a protocol fork.
I'm thinking slightly differently to gmaxwell, as far as I'm concerned it's supposed to be a broadcast medium, but if people want to use it to store verification tokens for private data then that's a really useful added feature, especially for id/, it could be done easily if we can agree on a standard. I think that's more important than preventing people using namecoin as it was designed to be used & I worry that people will think they can use Namecoin to store private data with gmaxwell's proposals. My signature proposal wouldn't work for names, it'd be impossible to prevent duplicate registrations, it'd just be storing a verification token for private data in the key=values under the name. My proposal could possibly work alongside gmaxwell's, I'm not sure, maybe his proposal would break my possible use for storing private data, it'd make it more complicated at least, but I don't like his proposals. I think there are some possible good uses of Namecoin as a type of broadcast medium that could be made very hard or impossible with a hardfork enforced hashing system for everything.
I don't see how gmaxwell proposes to enforce hashing to prevent namecoin being used as a broadcast medium either, how would a node know if it was a hashed value & not something manipulated to broadcast a message? Brute force can work both ways, even if hashing was somehow enforced they could mine for a partially manipulated hash.
So I think his goal is wrong, and I think he's wanting to achieve it with something that wont work & could create unnecessary hassle and/or limit how namecoin can be used. However, some of it relates to how I want to store private data. Maybe I'm wrong though? I think gmaxwell's proposals need consideration, but I think they need more work. I broadly agree with his first couple of proposals about utxo/spv - although I haven't really considered how they'd affect the WoT stuff I'm thinking of - his "who gives a ?!#@" comment scares me, I do, but I'm more wary of his hashing proposals. Whole thing just seems like a bit of a quick & badly thought out blog post, but maybe there's something in it if he or somebody else spends some time to work out the implementation details. Maybe I'm just totally missing the point, I'm just learning.
Increasing the fees is a simple way to cut down the number of scammer/spammer jerks, obviously there are some rich scammers & you can never eliminate all jerks, but even a small fee changes the economics of trying to perform attacks which involve mass registrations to make it less (or ideally not) profitable to run. Ideally we'd separate updates from renewals & charge for renewals only. Renewal fees are needed because a lot of dormant domains exist & they should have a cost. People who want to use the domains should be able to register them instead of somebody keeping hold of a dead domain (or thousands of them) forever for free. You can never eliminate jerks, but you can cost them more money, cut down the scale of their scams & put a few people off because they can find easier/more profitable scams elsewhere. Increasing fees is a direct way to make sybil/spam/squatter attacks more expensive. It has the downside of costing legitimate users money too, so the fees can't be too high, but right now 0.01nmc for a domain for life is silly. Other alterations, like lengthening the expiry time (to around 1 or 2 years) could sweeten the deal. If somebody is using a .bit domain then a dollar or two every year or two shouldn't cause much problem for them, if somebody holds 10,000 dormant names, then it's more of a problem for them, that's the whole idea. Without renewal fees then somebody could've picked up a few thousand names for next to no money already, or between now & the hardfork, keep them for life & then hold them to ransom if .bit ever takes off, which it wont because of all the squatters holding the best names.
I'm not sure the larger domain holders & the larger miners are the same people, it's the miners & mining pools that have the power with Namecoin, there are only a few large pools that control most namecoin mining, should probably get any hardfork changes reviewed by cex.io . I'm not sure how many .bit domains cex.io have, or if they're the main .bit squatter or not, I'd guess not.
I'm really not convinced of or don't understand the reasons why miners can't get the domain fees, like they do with normal transaction fees, that could help sell it to miners & stop all the namecoins being burned on domains. The only argument I heard against it was that it allows more types of 51% attacks, but I think there are worse ones to be scared of already, afaik they own the network with over 51%. Eventually I want to move away from sha256 proof of work, but that'll probably require a whole new currency with a new blockchain, rather than trying a blockchain fork.