Topic: fuck this shit, I want my own blockchain! - page 2. (Read 3360 times)

Just to give you a hint (Without revealing my own supersecret plan hahaha )

The metagame of 51% is not just about the right hardware and the right hashing algorithm, it's defining what's your own game is and what it is needed for someone to beat you at your own game. Implementing something like trusted nodes or a decentralized version thereof is _not_ the right answer.

OK I already said enough  

These are great ideas, you should go for it. I've got some hashing power I'll pledge to mining on the new chain. I've got some BBQ coins for you too if that helps. 

That would be point 3.3 in my original message. I don't have a complete picture right now, but I guess it should be a trusted node which signs blocks it sees so certain version of blockchain becomes locked. This isn't very different from locks in source code, it just doesn't require binary updates.

But I think it should be advisory rather than mandatory. I.e. users are free to ignore it, or they can switch to different trusted node.

Also maybe it's worth detecting running 51% attack and advising to hold transactions for some time.

Frankly, I don't see 51% attack as a big issue. It's kinda unlikely that it will be used for double-spends on a young currency (aside from pranks), and denial of service isn't a big deal: they won't pull it off for months, right?

Network-level DDoS would be a different thing, though.

But if "influential people" would announce their hostility from start I will just cancel this idea, it's not worth it. But then, don't complain about lack of innovations

You might look at the "trust node" model of solidcoin which is resistant to 51% attacks.

The main issue with sc is not the coin  itself it is the lead developer's attitude.

1. To get it merged-mined I need to convince some major pools that my chain is a great thing. To make it just mined I only need to convince a bunch of users to contribute their CPU resources. One is harder than another. And, frankly, I don't want to lie that some experimental chain is best thing since sliced bread, it might be a total failure. Users will be more forgiving than pools, won't they?

2. I think that CPU-mining is a great feature. Not for coin security, of course, but it's just fun for users. I believe that considerable part of initial bitcoin popularity could be explained by the fact that averages users were empowered thinking that they can download some program and start generating some currency. GPU-based mining is quite a bit more involved than that, but pools and GPU-mining came when Bitcoin already had some popularity. It also worked with a limited success for *brix and litecoin. But now, as far as I can tell, there is no real GPU-hostile currency at this point.

3. Obviously no existing block chain can serve as CPU-friendly merged mining host. Frankly, I don't see Litecoin merged-mining sufficiently different from Bitcoin merged-mining for it to matter, aside from the fact that it might be easier to convince Litecoin pools. (And maybe there will be some difference when ASICs will dominate Bitcoin mining.)

4. While CPU-only mining is mostly just for fun and economic reasons, it can also be seen as a way to improve democratic control over currency as there will be lower incentive for people to organize into pools. This might be of a higher importance for a experimental currency: pools are inherently more conservative, and "pooled democracy" is inferior to direct democracy. Basically, I won't have to convince DeepBit-analog to enable certain feature. You remember BIP-16, right?

5. I believe that worst thing can happen is DoS and double-spends, and I don't see it as a big deal for experimental currency. So I won't see 51% attacks and obscure forking conditions as a big deal.

6. Thanks for encouragement, but I also want to see some CPU power pledged. If bbqcoin could get it, can't I?

You could start by making litecoin and bbqcoin merged-mine-able. That would give you the basic scrypt-based merged mining setup from which to proceed onward to your experimental chain(s).

-MarkM-

At some point this project is going to be mainly your baby so it would be good to hear that your commitment is stronger. If all you need is encouragement then... fuck yeah! You should so do this!

I do like the constant coin generation rate. Constant rate would also neutralize in some part the early-adopter argument. Then again, that early adopter incentive might need to be replaced by another incentive like a genuine technical improvement of some sort(not an easy feat mind you).

Whatever you do I suggest making a good case for the new chain's existence before the genesis block is mined and be setup with merged mining from the start.

If you need a break from thinking about this project too much, consider writing a developers guide for Bitcoin and amass all the best development practices you can find. Things like don't use floats to store BTC balances. You can put it on the wiki in a new page.

Good luck killerstorm.

You could ask yourself what you are trying to archive. What purpose should the currency have, in a sort of end means?
Even if it doesn't turn out that way after all it should give you the motivation to make it good.

I'm motivated only if I see that other people are interested in work I'm going and I interact with those people.

Alternatively I can get motivated by a challenging problem, but coding is too boring to trigger that kind of motivation.

That's a personality trait, I guess, other coders might have no problem coding for 8 hours straight. I can't, even for money, unless I'm really motivated.

If somebody doubts my qualification, here's a little crypto research I've done: https://bitcointalk.org/index.php?topic=55888.10 (Although I'm not a cryto professional, it's just a little research project which I found interesting.)

Nothing, actually. I'm just sort of lazy.

I'm posting this just to see community reaction, if people are interested I can do this, otherwise I won't.

I'm currently working (aside from my main job) on a speculative market, e.g. futures/options exchange, where people can bet on exchange rates, prices and stuff like that. Ideally, I want a blockchain-level escrow for this, to avoid bitcoinica-style fiasco.

I started working on it about a year ago, and at that time there were talks about escrow and distributed contracts. But, still, these things are PITA in Bitcoin mainline, so maybe I have to implement it myself?

What's stopping you from implementing your ideas yourself, releasing it and see what happens?

Of course that would be more work than creating this thread....
To clarify why are you so lazy? (tbh I don't think you are not really a c++ coder)

I mean, if bbqcoin is possible...

1. OK, to make it clear, it is vaporware: I'm a really lazy person and I have lots of ideas. But, on the other hand, I'm a pro C++ coder, so I can do this, in theory.

2. People might say: "Why don't you work on improving existing currency like bitcoin or litecoin?". It's simple: when currency is actively used and valuable, its developers become conservative in features they allow. They do not want disruption for existing users, which is understandable. OTOH with some obscure alt chain you can experiment however you want.

This is actually the purpose of alt chains, according to Gavin himself (https://bitcointalksearch.org/topic/innovation-in-the-alt-chains-55506)

3. So, here's a list of features I'm interested in:

3.1. Geared towards CPU mining, via scrypt tuning (more memory), plus maybe my own crypto ideas. (I need to discuss them with pros first, though.) This would change initial coin distribution patterns (i.e. owners of large GPU farms won't get majority of coins, sorry), and might help against 51% attacks simply because influential people in bitcoin community are likely to have more GPU hashing power than they have CPU hashing power. (Although they can rent CPUs from EC2, for example.)
3.2. First class support for escrows, distributed contracts and stuff like that. With usable interface. They are sort of supported in bitcoin, but half of features are disabled, and half doesn't have proper UI. I actually work it working since I'm working on services which need this stuff.
3.3. Optional centralized timestamping to make instantaneous transactions possible. EDIT: probably irrelevant since similar goal can be accomplished with escrow I know it might be unpopular, but I'm going to make it a configuration option in client: you can configure it to either trust both timestamping server or only blockchain. It might also help against 51% attack, although I'm not sure about it. (Note that it's possible to implement it in bitcoin as a client feature, but it won't be as effective just because it's not default.)
3.4. Merged mining of stuff like ripple, distributed exchanges. (Technically this has almost nothing to do currency, but if I'll be making mining software I'll just include it there as a bonus feature.)
3.5. Potentially support for 'daughter chains', i.e. transfer of coins between many chains. I think it might help against blockchain bloat.
3.6. Constant mining rate, i.e. always 50 coins per block, forever. It would make monetary base stable, believe me or not. Rationale is that some coins are inevitably lost at a rate proportional to current quantity (on average), thus it's should be possible to get to equilibrium where number of coins lost = number of coins mined. As a side effect:

3.6.1. Since there are no changes in amount of bounties it makes things predictable and reduces volatility. (I.e. when mining goes from 50 to 25 you have change in supply and markets are going to react, even if it was known beforehand.)
3.6.2. Might subsidize transaction fees, i.e. miners don't have to charge a lot.
3.6.3. No deflationary problems like 'grandfather's wallet'.

4. I understand that many community members won't like some of these features, but the goal here is to try new things, not to get some people rich. If you don't like it, then forget about it. If nobody likes it, I have other things to do.

5. If there is an interest in bbqcoin community I can take it over. As I understand, original developer abandoned it... So this can save some time doing renaming and making initial block. However, it might be somewhat hard to switch hash algorithm 'on fly'. Also, there is already an awesome, vibrant community

Otherwise, I'm accepting donations (in form of pledges).

Thanks!