Bitcoin Forum
June 24, 2018, 03:10:04 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 ... 86 »
161  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: August 13, 2016, 07:13:16 AM
sp specs algo? you need to work better on your OP if you want to attract more people, looks very bland...

From looking at the code, it appears to be SHA256D.
162  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: August 13, 2016, 02:50:49 AM
Also not able to connect:

Code:
12/08/2016 20:43:13.020 MAIN:00000BF8 [Info] <TLog> Log file start: C:\Users\Maxwell\AppData\Roaming\PascalCoin\PascalCointWallet.log
12/08/2016 20:43:13.073 MAIN:00000BF8 [Update] <TPCBank> Clear Bank
12/08/2016 20:43:13.073 TID:00000898 [Update] <TPCBank> Clear Bank
12/08/2016 20:43:13.089 TID:00000898 [Info] <TPCBank> Start restoring from disk operations (Max 4294967295) Orphan:
12/08/2016 20:43:13.105 TID:00000898 [Info] <TPCBank> End restoring from disk operations (Max 4294967295) Orphan:
12/08/2016 20:43:13.105 MAIN:00000BF8 [Info] <TNetServer> Closing server
12/08/2016 20:43:13.105 TID:00000898 [Info] <TNetServer> Activating server on port 4004
12/08/2016 20:43:13.105 TID:00000898 [Info] <TNetData> Allready discovering servers...
12/08/2016 20:43:13.373 TID:00000894 [Info] <TNetClient> Connected to a server pascalcoin1.ddns.net:4004
12/08/2016 20:43:13.577 TID:00001058 [Error] <TNetClient> Pending requests without response... closing connection to pascalcoin1.ddns.net:4004 > Op:HELLO Id:2 - Op:HELLO Id:1 -
12/08/2016 20:43:13.577 TID:00001058 [Info] <TNetClient> Disconnected from pascalcoin1.ddns.net:4004

Here are the servers it tries to connect to:
Code:
bpascal1.dynamic-dns.net:4004
bpascal2.dynamic-dns.net:4004
pascalcoin1.ddns.net:4004
pascalcoin2.ddns.net:4004
pascalcoin1.dynamic-dns.net:4004
pascalcoin1.dns1.us:4004

When attempting to connect to these with raw socket connections, they all fail except for pascalcoin1.ddns.net:4004, which responds "Your IP is blacklisted:192.168.0.180:64873".

163  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: August 13, 2016, 01:42:46 AM
Sounds similar to the mini-blockchain implementation pioneered by Cryptonite: https://bitcointalk.org/index.php?topic=713538.0

The "safe box" could be compared to the mini-blockchain radix-tree-based balance sheet, where the hash of the safe box is embedded into blocks, so that a user's copy of the safe box can be validated against the blockchain.

If it doesn't need historical operations then why does it need a blockchain? What makes it different to other coins? Does it have a blockchain pruning mechanism to keep the blockchain small, or some special features besides being written in a different language to other coins?

As far as why it needs a blockchain, I would assume the blockchain acts as a means of maintaining consensus on the contents of the "safe box" although it isn't referenced directly for transaction history/data/validity.
164  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin - Protein Folding Research based Proof of Work on: August 12, 2016, 03:50:33 AM
Sorry for the silence.

I'm working (completely separately from CureCoin) on a project that I believe will be a significant step forward for blockchain security for alternative cryptocurrencies. It's an interesting (and much more secure + scalable) solution to cross-blockchain security than anything that exists today (namely merge-mining). We're going to use the technology for CureCoin 2.0 (for blockchain security reasons including preventing compromised university keys from being able to fork the network), and waiting on that technology to be available is the current delay.

Aside from some nips and tucks, the cc 2.0 sourcecode is primarily only waiting on an overhaul to its consensus mechanism. Merkle signatures work, the mini-blockchain works (but needs some tweaks), the networking code will be optimized a bit but works, etc. etc. To my knowledge, all non-display-related bugs in the current (few months ago) alpha release were related to block desynchronization. This overhaul can't be done until the project I'm working on (which unfortunately I can't give any details on right now) comes to fruition, because the cc2.0 consensus code will be heavily based on the a working version of that project. As soon as that project goes into public alpha/beta, cc2.0 will have a beta release which works with that project's alpha/beta network, and will closely mirror that project's development cycle leading up to that project's launch. CureCoin will be the first blockchain to adopt that new technology, so expect some hiccups during the beta(s). Unfortunately, I can't provide a meaningful timeline on that other project. We wanted to have a working (internal/private) alpha of that other project a few weeks ago, and we're close to getting that up and functioning, but it's a ways off from public release (few months? we'll see.).

I kept waiting to make any kind of announcement until I had more concrete details about a release schedule for that other project. It sucks to come here and say "we're working on something cool, sorry I can't give you any details or timeline," but it's been long enough that that kind of announcement is necessary.

There is always an option for releasing cc2.0 in-line with the previous plans (standard consensus algorithm), and then do a hard-fork to it to implement this new security technology when it becomes available and usable. However, causing a network hard-fork only a few months after launch isn't ideal, and the codebase would likely forever live with the solution "bolted-on after launch" rather than cleanly integrated from the beginning. This wouldn't be the end of the world--any existing blockchains which adopt the security technology will be required to do a similar hardfork. Given the complexity of both projects though, releasing a blockchain that will hard-fork a few months later is certainly not very graceful.
165  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin - 3/21/2016 SigmaXcoin Beta Download + Crowd Sale Active Now! on: April 25, 2016, 12:05:32 AM
When is the snapshot I keep buying curecoins I want to make sure i have them all in my wallet by the snapshot date?

Hey! Snapshot date still won't be for a while, but it'll also probably be a 'rolling' snapshot where balances are recorded weekly.
166  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin - 3/21/2016 SigmaXcoin Beta Download + Crowd Sale Active Now! on: April 25, 2016, 12:04:14 AM
Client seems to sync now, can anyone verify current block?

I'm at:

getinfo
Blocks: 423
Last block hash: 22B32DBEAE5004772E0758E6EAAF9068653D1BCDF9F6FED7C280E3F808F0C97
B
Difficulty: 50000000
Main address: S15W5NW37NSRY27GR53DG3JY7TCEBNOEDVOWMD
Main address balance: 65000000000

Edit: Pretty sure i've forked blocks stopped increasing after closing testnet miner.

Edit2: Started from scratch seem to be stuck at block 410 daemon is just spamming same stuff over and over.

got data: NETWORK_STATE 410 C24DB47300D0...568F4286931416C6D7C5E6CF51C97C
got data: TRANSACTION net.curecoin.sigmax.Transaction@54bedef2
got data: TRANSACTION net.curecoin.sigmax.Transaction@8efb846
got data: TRANSACTION net.curecoin.sigmax.Transaction@2a84aee7
got data: TRANSACTION net.curecoin.sigmax.Transaction@a09ee92
got data: NETWORK_STATE 410 C24DB47300D0...568F4286931416C6D7C5E6CF51C97C
got data: TRANSACTION net.curecoin.sigmax.Transaction@54bedef2
got data: TRANSACTION net.curecoin.sigmax.Transaction@8efb846
got data: TRANSACTION net.curecoin.sigmax.Transaction@2a84aee7
got data: TRANSACTION net.curecoin.sigmax.Transaction@a09ee92
got data: NETWORK_STATE 410 C24DB47300D0...568F4286931416C6D7C5E6CF51C97C
got data: TRANSACTION net.curecoin.sigmax.Transaction@54bedef2
got data: TRANSACTION net.curecoin.sigmax.Transaction@8efb846
got data: TRANSACTION net.curecoin.sigmax.Transaction@2a84aee7
got data: TRANSACTION net.curecoin.sigmax.Transaction@a09ee92
Sent:: REQUEST_NET_STATE
PUTTING INTO WRITE BUFFER: REQUEST_NET_STATE
Sending REQUEST_NET_STATE to /155.94.254.14
got data: REQUEST_NET_STATE
PUTTING INTO WRITE BUFFER: NETWORK_STATE 410 C2...
got data: GET_BLOCK 410
Sending block 410 to peer...
PUTTING INTO WRITE BUFFER: BLOCK {1461110264025...
got data: GET_BLOCK 411
got data: GET_BLOCK 412
got data: GET_BLOCK 413
got data: GET_BLOCK 414
Sending NETWORK_STATE 410 C2 to /155.94.254.14
Sending BLOCK {1461110264025 to /155.94.254.14
got data: GET_BLOCK 415
got data: GET_BLOCK 416
got data: GET_BLOCK 417
got data: GET_BLOCK 418
got data: GET_BLOCK 419
got data: GET_BLOCK 420
got data: GET_BLOCK 421
got data: GET_BLOCK 422
got data: GET_BLOCK 423
got data: GET_BLOCK 424
got data: GET_BLOCK 425
got data: GET_BLOCK 426
got data: GET_BLOCK 427

Etc... uptil Block 645 then it repeats.

Hey merc, is your client still stuck on block 645? If you type "getinfo" in the client, what is the block hash of your latest block? As of right now, the latest block appears to be 1212 with block hash 3A47C5DB73C1DFDB431E211732F1259A73EC82AC53F1EFEB389CAFAE5BF1FF6D.

The daemon will spam data for a while while it's syncing, you can see more in-depth progress (or lack there-of, in the case of desynchronization issues) by typing "getblock" into the client periodically. The spam is mostly caused by network 'reverb' or delayed block processing, which is something I'll try to address in the next beta release to make the debug output more useful.
167  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin - 3/21/2016 SigmaXcoin Beta Download + Crowd Sale Active Now! on: April 19, 2016, 04:36:33 AM
As promised, SigmaX beta 3: http://1.curecoinmirror.com/sigmax/SigmaXTestnetBeta3.zip Thanks for testing!
168  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 16, 2016, 12:01:18 AM
Done Smiley Cya man!

Thanks for stopping by.
it's regrettable that the situation degraded into cussing and fud throwing. We wish you luck elsewhere

Haha Sorry for swearing. I'll keep mining away. Got nothing better to do on my computers. I read and caught up. Totally get it now.

Please add me to the giveaway! Just registered. I've gotta say... mining is super rewarding right now to see it in the tens of thousands every hour. LOL.

That's great to hear! Sorry for our caps and thank you for understanding.

We hope to see you around. If you need any assistance please let us know. Smiley we are here for the community which we are glad you decided to be a part of.

We will gladly add you to the give away. (Any chance of you posting proof on the giveaway thread?)

http://bitcoingarden.tk/forum/index.php?topic=7403.225

I posted on the bitcoin garden page. Let's mine the crap out of this guys.

Awesome thanks for participating!





@vorksholk -

That is one hell of a lesson right there. You've also given me personally some things to maul over.

We will begin attacking our test coins in manners described and continue security development.

Thank you for sharing that valuable information and spending your time in doing all as that I imagine required some effort to put as well as your did.

Again Thank you.

No problem, thanks for reading! Let me know if you have any questions! Cryptocurrency security is a fascinating topic, and I certainly don't know all of it either.
169  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 15, 2016, 11:46:18 PM
As you know, proof of work is a security mechanism--someone needs to (essentially) match the hashing power of the rest of the network, and then they can freely fork blocks, create double-spends, etc. I know you're planning to implement another security mechanism, "proof of reliability," which I haven't seen explained yet, but understand it as an improvement over proof of stake. But until that's implemented (or even afterwards, depending on your implementation), your network's security only comes from the cost (in servers) of attacking the network.

It's not so much about pushing the chain along to process transactions, but to keep those transactions locked in the chain safely.

100milion is like month+- of mining with mid range CPU. So its not that much after all also. Can you code in wallet to have ICO coins locked in for a like 365 days and then only like 10% gets released and so on.

We are considering changing up the tactics, however we must be very considerate about it as to not upset the community either, no one will want to wait a year to get their coins. Here's the kicker though. Once we go PoR, your balance will impact what you earn per block like PoS. Just in different manner

Also PoW ends just at over half way of the total count. The rest is PoR. So PoW only takes the chain just over half way

People would probably be perfectly fine with the 100 billion coins paid out over a longer period of time, perhaps for as long as you think it'll take to get new security measures in place.

Right however if you've tested a 51% attack like we have it doesn't work very well as 51% gives a CHANCE at messing with the chain which legitimate nodes tthat we hardcode in will immediately reject the attackers. Trust me we have extensively tested an attack on our private network on several test clones. Please advise if I'm missing something as I'm not Einstein but attacking achain is not as easy as it sounds.


And I'd like to clarify I'm not trying to attack your project or anything--I'm excited about it, I love the dev activity, the roadmap is interesting.

What kind of heuristics do your legitimate nodes use to recognize attacker blocks? Is it a checkpointing system? Even if you do have nodes that can recognize these blocks somehow, unless it's actively communicating to the network to ignore the blocks (like signing a message as some form of authority that denounces the block, or something of the like), passively refusing to propagate the blocks won't stop a well-connected network from forking.

Attacking a chain isn't necessarily easy, but I wouldn't imagine it being much harder than running your own pool, blocking the daemon's outgoing traffic, mining a bunch of blocks faster than the rest of the network, and bringing it back online to propagate.

You're correct that 51% gives a chance of messing with the chain, not a guarantee. Variability could throw a wrench in it, but over the long term a slightly-higher-than-50% hashrate would outstrip the chain, and the attacker could simply wait until variability works in their favor to bring their attacking node(s) back online. The attacker has time on his/her side, because they decide when to submit their growing chain to the network.

Imagine you're attacking a network with a private pool. The legitimate network is at block 10,000 (which includes the transaction you want to double-spend), with 100 MH/s of mining power. You bring 102 MH/s online for your private pool. The legitimate pool has no knowledge of your private pool. In the beginning, due to random chance, the legitimate network gets ahead, and hits block 10,010 when your private pool has only gotten to block 10,008. You bring a bit more mining power online (or just wait for the inevitable swing of randomness), and by block 10,030 on the legitimate network, your private pool has hit block 10,032. You bring your node back online, the network forks back 32 blocks. What if you were still behind at block 10,030? Maybe you'd be ahead at block 10,040, and do even more damage. The naive solution to this is simply have peers refuse to fork past more than x blocks, but that can become dangerous if the network does, during normal operation, get that far out of sync due to something like a protocol disagreement (something like a BIP update gone awry), since the network would permanently divide into two (or more) fragments. And it doesn't necessarily have to be a user who's providing all of the hashing power--it could be an existing, popular pool who decides to "go rogue," feed bad data to miners, and use them to fork the network.  

Let's now say your network's seed nodes have the ability to detect this, and not propagate the 32 malicious blocks. Unless all of the nodes are connected to one another through your controlled nodes, those blocks will still propagate on the network. Basically the litmus test here is whether the network would continue to run if your seed nodes went down. If so, then passive refusal won't prevent the attack. Now, in the event that your nodes are actively managing the network--either by signing a message that checkpoints blocks as an authority that the rest of the network trusts, or by some other similar mechanism that either marks blocks as guaranteed-legitimate or certainly-illegitimate. Mechanisms like this would also raise concerns about centralization and the network being brittle and subject to break during non-malicious but unpredicted conditions.

I have no idea how your proof-of-reliability mechanism will function when launched (do you have any literature on it to read, or a brief summary anywhere?), but for now I'll just discuss it as if it is proof of stake, although I understand you're planning to make significant improvements/modifications on top of that protocol.

Proof of stake introduces an interesting complication to network forking, but also creates a new attack vector. Proof of stake (as it traditionally is implemented) gives priority/weight to transactions which consume larger quantities of coin-days. As such, an attacker could buy a large quantity of coin on an exchange and transfer it to addresses they own, wait until they reach max stake age, and then attack the network with significantly less than 51% of the total network float. The amount it would require depends on how active other people are with staking and how much outstanding coin age will be consumed by others legitimately while they attempt their fork, but under certain conditions such a fork could be successful with a quite small portion of the network float.

Additionally, when combined with proof-of-work, proof-of-stake blocks could be the extra 'icing on the cake' to push their network power over 51%--stake weight saved in reserve to use if variability doesn't work in the attacker's favor. Even non-malicious but greedy nodes (who spend time offline until reaching maximum stake age on lots of transactions, then coming online) could cause grief for a laggy network. One proposal for eliminating (or greatly reducing) this issue is to require that the blockchain is 'layered' (something like a minimum number of proof-of-stake and proof-of-work blocks in any given 'frame' of contiguous blocks). This would at least require an attacker to have mining power AND stake weight. Other solutions involve coin-age being only used to calculate reward but not "priority" (in the form of a greater chance of mining a block with x coins).

Anyhow I'm rambling, but if you want to discuss the types of attacks you've tested that your network has been able to thwart on testnet, or the security features your hard-coded nodes have, I'm all ears. But exchanges (a primary entry point for new users to get involved) are hesitant to list coins that have particularly low difficulties, because of the responsibility they have for user balances, which even non-malicious forks could disrupt.

And at the end of the day, if miners don't expect to at least break even on their efforts, they're unlikely to mine. Which makes all of the above attacks much easier. I understand price not being your primary goal--and that's a great approach to crypto-currency in general, and means you care about development, features, long-term support, etc. But a secure network is the foundation for the entire project, so there needs to be some acceptable security mechanism. Whether that be some semi-centralized checkpointing solution, or some alternate miner incentive (like a 'colored coin' or address reputation to give them voting power on something important), or your proof-of-reliability, this is certainly something to think about before those 100B coins hit the markets.  
170  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 15, 2016, 10:29:42 PM
For all invovled in Reverse-ICO
May higher force be with you, when you get Reverse-ICO transaction in.


Honestly must users will probably dump. We will be setting up toilets to catch them all as it'll be a shot in the foot after things stabilize. As with any legitimate startup.


Just enrolled.

Looking forward to it.

Saw that! We will update the list today.



Is this math correct?

Reverse-ICO reserve is 100,000,000,000 coins (20% of total supply), split on April 18th between everyone on the bitcoingarden thread. If 1000 people participate, that's 100,000,000 coins per person, which is equivalent to mining 2000 blocks.

Sounds legit
A lot.1000BTC worth if 1 ESP is 1 satoshi. must be something about Proof-of-Reliability Grin

everyone will be able to dump for free for one bitcoin, this is sounds retarded, good luck finding those that will pay 1 btc to other that didn't even invest anything

Price is not the goal, probably like the 100th time we've stated this...


Is this math correct?

Reverse-ICO reserve is 100,000,000,000 coins (20% of total supply), split on April 18th between everyone on the bitcoingarden thread. If 1000 people participate, that's 100,000,000 coins per person, which is equivalent to mining 2000 blocks.

Sounds legit

Hmm, alright. Well best of luck, but I doubt the coin will get any meaningful amount of mining (and, hence, security) once the market stabilizes, since it'll be flooded.

There'll still be hobbyist miners I suppose, but people won't be able to break-even with the cost of electricity.

Let's say it takes a miner 3 hours to mine a block on a CPU consuming 140W. Then a block costs a miner $0.063. Assuming 1,000 people participate in the bitcoingarden thread, and they each get the equivalent of 2000 blocks, that would mean they would have to refuse to sell under a valuation of their free coins of $126, or the market would need to support $126,000 (296.47 BTC) in sells.

Most new altcoin markets can't support anything near a 300 BTC dump, meaning that the price will fall way below miner breakeven.

And a network where a high-end consumer CPU can mine 8 blocks a day with a 20-second block target is pretty cheap to attack. That's 4320 blocks per day, or 540 high-end consumer CPUs that comprise the entire network's hashing power. That's about 220 high-end servers, like a c4.8xlarge on EC2. At the average spot pricing of $0.32 per box per hour, the network will cost $70.40 per hour to fork, plus an extra few dollars to ensure 51% is maintained.

If you wanted the network to cost, say, $500/hr to attack, you'd need a 7.10x increase in hashing power, which would mean a miner would need a block to be worth $0.4473, making the per-user-reverse-ICO-payout worth $894.60 per user, or $894,600 in total. That's 2104.94 BTC.

The market would need to buy that reverse-ICO at 2104.94 BTC (putting the currency's market cap at $4,472,997.50) to reach $500/hr cost to fork the network.


Anyhow, I could be wrong (or missing something major), but you might want to re-think the distribution or coin emission curve before you pay out all those coins. You could do a slow-release over a long period of time (still to the same giveaway users), or something else. If you plan to make Espers very feature-rich and well-supported to justify a $4.5 million market cap, a slower premine distribution would give you time to reach it before people lose faith in the market and the network's security dwindles to pure hobbyist miners.



Price is not the goal, probably like the 100th time we've stated this...


I understand that, but this is a discussion about security. Miners (generally) won't mine below breakeven.

I fail to see how that is asecurity concern? The chain will simply be pushed by our miners if no one else wants to. More for us. ... And more giveaways

This project is purely for people who want to get in early on something that will like a butterfly go from a ugly caterpillar and transform into something beautiful.

OR one can simply wait until this exits the cacoon and flies away. Either way the project will go on.

As you know, proof of work is a security mechanism--someone needs to (essentially) match the hashing power of the rest of the network, and then they can freely fork blocks, create double-spends, etc. I know you're planning to implement another security mechanism, "proof of reliability," which I haven't seen explained yet, but understand it as an improvement over proof of stake. But until that's implemented (or even afterwards, depending on your implementation), your network's security only comes from the cost (in servers) of attacking the network.

It's not so much about pushing the chain along to process transactions, but to keep those transactions locked in the chain safely.

100milion is like month+- of mining with mid range CPU. So its not that much after all also. Can you code in wallet to have ICO coins locked in for a like 365 days and then only like 10% gets released and so on.

We are considering changing up the tactics, however we must be very considerate about it as to not upset the community either, no one will want to wait a year to get their coins. Here's the kicker though. Once we go PoR, your balance will impact what you earn per block like PoS. Just in different manner

Also PoW ends just at over half way of the total count. The rest is PoR. So PoW only takes the chain just over half way

People would probably be perfectly fine with the 100 billion coins paid out over a longer period of time, perhaps for as long as you think it'll take to get new security measures in place.
171  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 15, 2016, 08:45:43 PM
Is this math correct?

Reverse-ICO reserve is 100,000,000,000 coins (20% of total supply), split on April 18th between everyone on the bitcoingarden thread. If 1000 people participate, that's 100,000,000 coins per person, which is equivalent to mining 2000 blocks.

Sounds legit
A lot.1000BTC worth if 1 ESP is 1 satoshi. must be something about Proof-of-Reliability Grin

everyone will be able to dump for free for one bitcoin, this is sounds retarded, good luck finding those that will pay 1 btc to other that didn't even invest anything

Price is not the goal, probably like the 100th time we've stated this...


Is this math correct?

Reverse-ICO reserve is 100,000,000,000 coins (20% of total supply), split on April 18th between everyone on the bitcoingarden thread. If 1000 people participate, that's 100,000,000 coins per person, which is equivalent to mining 2000 blocks.

Sounds legit

Hmm, alright. Well best of luck, but I doubt the coin will get any meaningful amount of mining (and, hence, security) once the market stabilizes, since it'll be flooded.

There'll still be hobbyist miners I suppose, but people won't be able to break-even with the cost of electricity.

Let's say it takes a miner 3 hours to mine a block on a CPU consuming 140W. Then a block costs a miner $0.063. Assuming 1,000 people participate in the bitcoingarden thread, and they each get the equivalent of 2000 blocks, that would mean they would have to refuse to sell under a valuation of their free coins of $126, or the market would need to support $126,000 (296.47 BTC) in sells.

Most new altcoin markets can't support anything near a 300 BTC dump, meaning that the price will fall way below miner breakeven.

And a network where a high-end consumer CPU can mine 8 blocks a day with a 20-second block target is pretty cheap to attack. That's 4320 blocks per day, or 540 high-end consumer CPUs that comprise the entire network's hashing power. That's about 220 high-end servers, like a c4.8xlarge on EC2. At the average spot pricing of $0.32 per box per hour, the network will cost $70.40 per hour to fork, plus an extra few dollars to ensure 51% is maintained.

If you wanted the network to cost, say, $500/hr to attack, you'd need a 7.10x increase in hashing power, which would mean a miner would need a block to be worth $0.4473, making the per-user-reverse-ICO-payout worth $894.60 per user, or $894,600 in total. That's 2104.94 BTC.

The market would need to buy that reverse-ICO at 2104.94 BTC (putting the currency's market cap at $4,472,997.50) to reach $500/hr cost to fork the network.


Anyhow, I could be wrong (or missing something major), but you might want to re-think the distribution or coin emission curve before you pay out all those coins. You could do a slow-release over a long period of time (still to the same giveaway users), or something else. If you plan to make Espers very feature-rich and well-supported to justify a $4.5 million market cap, a slower premine distribution would give you time to reach it before people lose faith in the market and the network's security dwindles to pure hobbyist miners.



Price is not the goal, probably like the 100th time we've stated this...


I understand that, but this is a discussion about security. Miners (generally) won't mine below breakeven.
172  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 15, 2016, 08:34:57 PM
Is this math correct?

Reverse-ICO reserve is 100,000,000,000 coins (20% of total supply), split on April 18th between everyone on the bitcoingarden thread. If 1000 people participate, that's 100,000,000 coins per person, which is equivalent to mining 2000 blocks.

Sounds legit

Hmm, alright. Well best of luck, but I doubt the coin will get any meaningful amount of mining (and, hence, security) once the market stabilizes, since it'll be flooded.

There'll still be hobbyist miners I suppose, but people won't be able to break-even with the cost of electricity.

Let's say it takes a miner 3 hours to mine a block on a CPU consuming 140W. Then a block costs a miner $0.063. Assuming 1,000 people participate in the bitcoingarden thread, and they each get the equivalent of 2000 blocks, that would mean they would have to refuse to sell under a valuation of their free coins of $126, or the market would need to support $126,000 (296.47 BTC) in sells.

Most new altcoin markets can't support anything near a 300 BTC dump, meaning that the price will fall way below miner breakeven.

And a network where a high-end consumer CPU can mine 8 blocks a day with a 20-second block target is pretty cheap to attack. That's 4320 blocks per day, or 540 high-end consumer CPUs that comprise the entire network's hashing power. That's about 220 high-end servers, like a c4.8xlarge on EC2. At the average spot pricing of $0.32 per box per hour, the network will cost $70.40 per hour to fork, plus an extra few dollars to ensure 51% is maintained.

If you wanted the network to cost, say, $500/hr to attack, you'd need a 7.10x increase in hashing power, which would mean a miner would need a block to be worth $0.4473, making the per-user-reverse-ICO-payout worth $894.60 per user, or $894,600 in total. That's 2104.94 BTC.

The market would need to buy that reverse-ICO at 2104.94 BTC (putting the currency's market cap at $4,472,997.50) to reach $500/hr cost to fork the network.


Anyhow, I could be wrong (or missing something major), but you might want to re-think the distribution or coin emission curve before you pay out all those coins. You could do a slow-release over a long period of time (still to the same giveaway users), or something else. If you plan to make Espers very feature-rich and well-supported to justify a $4.5 million market cap, a slower premine distribution would give you time to reach it before people lose faith in the market and the network's security dwindles to pure hobbyist miners.

173  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 15, 2016, 07:49:05 PM
Is this math correct?

Reverse-ICO reserve is 100,000,000,000 coins (20% of total supply), split on April 18th between everyone on the bitcoingarden thread. If 1000 people participate, that's 100,000,000 coins per person, which is equivalent to mining 2000 blocks.
174  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 15, 2016, 07:46:22 PM
This is a quark coin or HMQ1725 coin ? Can mine with sgminer ? why cpu miner shows quark coin?

HMQ1725 coin, can't mine with sgminer unless someone adds the algo. CPU miner shows quark because Ocminer just hacked in this modified version of quark into the quarkcoin.c file in cpuminer and so the flag stays the same. If you used tpruvot's with -a quark, it wouldn't work.

175  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin - 3/21/2016 SigmaXcoin Beta Download + Crowd Sale Active Now! on: April 15, 2016, 06:09:23 PM
Hey everyone, SigmaX Beta 3 coming this weekend to patch the desynchronization issues.

There's quite a bit of confusion about SigmaX in the last two pages, so I'll give the 2-minute summary:
Curecoin 2.0 and SigmaX are different blockchains. Neither exist yet (both are in testing). They share much of the same code base, and in general development of one contributes to development of the other due to their similarity.

Curecoin 2.0 is our main/primary focus, and contains several unique features over Curecoin 1.0 and other existing cryptocurrencies, namely quantum-computer-resistant signatures, a mini-blockchain, a "jigsaw" blockchain that uses PoS as a security mechanism without the risks exposed by traditional PoS, and a certificate blockchain.

Since the certificate blockchain forces Curecoin 2.0 to be more centralized than some people in the crypto-community are comfortable with, we expect someone to create a pure-PoW fork of Curecoin 2.0 when it finally launches. As a preemptive measure, we figured we'd develop that PoW solution ourselves, so that it contributes to the Curecoin ecosystem.

Holders of Curecoin 1.0 (the only 'real' blockchain we currently maintain) will be able to convert their Curecoin 1.0 holdings 1:1 to Curecoin 2.0. The networks will run simultaneously, with Curecoin 2.0 eventually replacing 1.0 in its entirety, once the conversion period is over.

SigmaX will be PoW. PoS may be added, that's still up for discussion. People who own either Curecoin 1.0 or Curecoin 2.0 during the first (year? 6 months?) after launch will receive weekly payments of SigmaX as an extra reward for participating in Curecoin.

Curecoin 2.0 will be 'mined' by folding. SigmaX will be mined by hashing of some fashion (probably using a hard-drive mining algorithm as was pioneered by BURST).


If there's still any confusion as to how all of this fits together (it's confusing, I know), let me know and I'd be happy to explain further.

As I mentioned before, this weekend SigmaX beta 3 will be public, to do additional stress testing on my fixes for the blockchain synchronization issues people reported in beta 2. Thanks!
176  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 15, 2016, 02:14:18 PM
Hi, I wonder if i can rent some rigs to mine espers? if so where can i rent a rig with HMQ1725 algo?

There aren't any sites like Nicehash offering HMQ1725 mining (yet), but you could rent servers from EC2/Vultr/QuadraNet/DigitalOcean/Atlantic.net/VexxHost/etc.
A few pages earlier in the thread, there are instructions for compiling both the wallet and external (pool) miner on Ubuntu 14.04.

177  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 15, 2016, 07:02:36 AM
thats the windows miner? please update the op with pool n working miner

Yup. I'm sure they'll update the op with it and the pool when they get the chance Smiley
178  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 15, 2016, 07:00:27 AM
Windows binary of the ocminer's pool miner.

http://1.curecoinmirror.com/cpuminer-hmq1725.zip

Direct compilation of Ocminer's github repository, use at your own risk, yada yada. Seems to be running about ~50%-70% faster than the built-in solo miner. Tested working on an Intel (i7-5820k) and AMD (8350) with Win7 and Win10. And for anyone nervous about binaries, you only lose ~4% speed by running it in a VM, which is where you should run binaries from random people on the internet anyway.
Sorry about all the disgusting dlls, it's Cygwin and I'm not a Windows guy.




No no no, do NOT apologize! You just saved us a lot of headache! THANK YOU!
(PM your addy, we will be sure you get a little extra for that! As we did promise that previously to anyone compiling a windows version)


(Okay seriously we will now hold off on posting until we announce the update)




Nah no worries I've already mined a ton, just roll whatever you were gonna send into your airdrop/reverse-ICO thing Smiley
179  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 15, 2016, 06:42:59 AM
Windows binary of the ocminer's pool miner.

http://1.curecoinmirror.com/cpuminer-hmq1725.zip

Direct compilation of Ocminer's github repository, use at your own risk, yada yada. Seems to be running about ~50%-70% faster than the built-in solo miner. Tested working on an Intel (i7-5820k) and AMD (8350) with Win7 and Win10. And for anyone nervous about binaries, you only lose ~4% speed by running it in a VM, which is where you should run binaries from random people on the internet anyway.

Sorry about all the disgusting dlls, it's Cygwin and I'm not a Windows guy.



180  Alternate cryptocurrencies / Announcements (Altcoins) / Re: | ANN | Espers [ESP] | New Algo | New Features In Development | Reverse-ICO | on: April 14, 2016, 11:54:01 PM
I finally had some spare time and had a look at the pool stuff again, the problem was solved, thanks to tpruvot for the help !

Working Pool here:

https://esp.suprnova.cc

Working (new) and optimized external Miner here:

https://github.com/ocminer/cpuminer-hmq1725

Unfortunately I have no Windows and cannot compile for win, but I hope some nice guy will provide a compiled version.

For the other pools, here is the Hashing-Module needed:

https://github.com/ocminer/hmq-hash/


Happy hashing !

Thanks for this ocminer. When I try to compile the miner I get these errors, have you come across this before? Ubuntu 14.04
Code:
cpuminer-cpu-miner.o: In function `workio_thread':
cpu-miner.c:(.text+0x432a): undefined reference to `curl_easy_init'
cpu-miner.c:(.text+0x4419): undefined reference to `curl_easy_cleanup'
cpuminer-cpu-miner.o: In function `stratum_gen_work':
...

Thanks

Code:
sudo apt-get install libcurl4-openssl-dev
./configure CFLAGS="-march=native -Ofast" --with-curl --with-crypto
make
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 ... 86 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!