Bitcoin Forum
November 01, 2024, 04:38:14 PM *
News: Bitcoin Pumpkin Carving Contest
 
  Home Help Search Login Register More  
  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 »
21  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: December 21, 2014, 12:27:58 PM
Can someone help me find that great illustration posted some weeks ago with a sunny forest when mining Burst and POW-mining with environmental problems and smog? Can't remember who did it.

Thanks!

Majere.  (He still shows up in the send list when I use the burst wallet.)

A simpler diagram for non-techies. Grin

The image is in public domain. Author's wallet: BURST-6MZ2-6MH9-U5AX-FNMJX


22  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: December 21, 2014, 12:24:59 PM
Has there been any work on the development environment for AT?  The spec at CIYAM seems very low-level.

Is a crypto API going to be added to it?  Doing crypto using the AT instructions would be very expensive.

How does the AT code interact with reward assignment?  Vitalik Buterin thought up a mining contract where the terms of mining would be very enticing, and would lock participants' coin into the contract using a heavy penalty once the mining pool controlled more than 50% of the hashing power, giving the controller of the contract the power to double spend.  Such a malicious arrangement could be simplified if AT code can automatically set reward assignment.

It would be great to see the source code for the AT branch of burstcoin.  Is it available anywhere?
23  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 29, 2014, 12:30:32 AM
I have 50TB and i can not even get 12K per day. (No matter the pool i am using)

I ran into a similar problem recently... seems to be corrected when I reboot (verified over three reboots, now.)  I haven't figured out why yet, doesn't seem to be  clockskew or the drives getting  slower the longer the system is up...

dcct-miner on Ubuntu Trusty
24  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 27, 2014, 06:30:40 PM
You should buy mine at a premium price because I have had them longer than anyone else.  Like fine wine and art, the older it gets the more its worth.  Plus, they are MY coins, so there's that extra value too, like if some fanboi bought Justin Bieber's underwear or Tom Cruise's comb or something like that.

Hmm, you make a strong case...
25  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 26, 2014, 10:27:51 PM
I think blago's miner for win actually beats dcct's linux original noeadays.

Cool.  I don't have a windows machine, though.
26  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 26, 2014, 08:42:06 PM
What's the best linux solo miner, these days?  I'm seeing pretty poor peformance with dcct-miner, and I'm looking for some other miner to provide a basis for comparison.  I've averaged about a block a day from 38TB of plots.  It's taking about 110s to read the plots in, which has been typical for a few weeks.  (I know, I should optimize... I'm getting there...)

This is the distribution of delays I've seen over the last three days.

27  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 23, 2014, 03:08:56 AM
for the future of burst compared to bitcoin it is absolutely worth to mention that the main difference in the protocol is that no transactions get included within blocks by the miner. this is absolutely important because nobody can exclude transactions when mining a block.
if you think in terms of centralized mining monopoles they could decide to not confirm blacklisted addresses.
if today someone would have the intention to destroy bitcoin it can simply  be done by buying up all major mining companies and not include any transactions in the mined blocks. this way about 50 million dollar could destroy 5 billion dollar.
this applies to all btc based clones and means the future is burst!

I'm pretty sure that for $50M you could 51% bitcoin.  Last time I calculated it, the cost was around $100M if you paid retail for the ASICs, and anyone with that kind of money could fab them for much less.

That's not to say the oligopoly isn't a weakness, but the attack will come in some subtler way.  The State Department didn't buy PayPal in order to shutdown payments to Wikileaks, they just claimed Wikileaks is a criminal organization, implicitly threatening to punish PayPal  for Wikileaks transactions.  If you ever see mining pools refusing to record some form of transaction, probably something like that will be going on.
28  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 23, 2014, 12:16:34 AM
mczarnek, have you seen this exchange with Luke-Jr?  It may answer some of your questions.

Yes, you can do the same thing with scrypt...

The key part you may be missing in the "shoddily made flow chart" is that it "Does not include caching plot\[s\] to disk and retrieving them."  For $130 plus plotting and optimization time, a 4TB drive can store about 4*(10**12)/(2**18) = 15,258,789 precalculated values corresponding to the boxes in the bottom right-hand corner of the diagram (i.e., "Hash, then hash with the resulting hash, etc.")  The other hashes in the mining calculation are fast or only computed once per block, so you can check these 15M values as fast as you can read them off the disk.

Even the latest bitcoin mining hardware provides at best 5 orders of magnitude speedup over CPU hashing speeds, so your custom ASIC burning hundreds of watts might just about come within an order of magnitude of the speed achieved with cheap commodity hardware burning less than 10 watts (see figures 11-13).

A custom ASIC for shabal hashes would be super useful for the initial plotting, though.

From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements.
It is probably just as weak to ASICs, though I can't say for sure without more information.
Do actual specifications exist for the algorithm?
Also, is anyone interested in doing a BFGMiner port I can merge?

This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process.
It doesn't have to be a HD, it could just as well be (a lot of) RAM.
This is essentially the same way scrypt works, except scrypt altcoins aren't using as much capacity.

The flowchart is missing the caching and retrieving from disk parts. Since the account id and nonces are run through the repeat hashing step before any network state is used, the results of the repeat hashing can be saved and reused every block, with the miner only having to do the repeat hashing once ever per nonce. This makes it so the computational expense of that initial repeat hashing can be increased any amount without causing miners to do any extra work after the initial caching process. The more expensive that repeat hashing step becomes, the more efficient using pre-cached work is over computing everything on the fly.

Still working on the ASIC resistance.  So far, I've got an explanation of why ASIC resistance is important.   Sorry it's taking me a while.

(Meant to be read in emacs org-mode.  Lines with asterices are headings.  More asterices means lower in the heading hierarchy.)

* The ongoing centralization of bitcoin mining

** The role of mining in securing a cryptocurrency

Bitcoin's key innovation in is "mining," a way to encourage people to
make an economic commitment in order to participate in a distributed
consensus about the history of bitcoin transactions.  It's essentially a
lottery where you "buy" tickets by running a certain computation.  Each
computation generates a lottery ticket and, roughly speaking, if your
ticket has the right number you get to specify the recent transactions
which are appended to the official history in a "block."  (The official
history is usually referred to as the "blockchain.")  One of these
transactions is usually a reward to yourself, and these rewards are the
financial incentive for mining.  If you think of bitcoin as roughly
similar to a credit card system, winning the mining lottery is like
becoming the system's payment processor for a very brief period.

In terms of security, the main benefit of mining is to ensure that it's
very expensive to rewrite a transaction after it goes into the official
record.  Very roughly speaking, you would need to generate approximately
the same number of lottery tickets as all mining participants have since
the transaction was recorded.  A second benefit is that the process is
massively parallel so in principle many people can participate in it.
This decentralization makes it hard to organize collusive manipulation
of the transaction history.

** Economic incentives to centralize mining

There is a strong incentive to do the mining computations as quickly and
as cheaply as possible: The more lottery tickets ("hashes") you
generate, the more often you get the mining reward.  The equipment and
electricity required to generate hashes at a given rate are now about
100,000 times cheaper than they were when bitcoin started. These massive
efficiency gains have mostly been due to the fact that bitcoin initially
ran on commodity CPUs which a huge fraction of people in the developed
world already owned, and now mostly runs on specialized hardware which
is mostly only useful for bitcoin mining, and the fabrication of which
depends on hundreds of thousands of dollars of initial research and
development.

Bitcoin mining thus now requires capital-intensive infrastructure, and
this has predictably led to centralization, i.e. While many were happy
to try out bitcoin in the early days with their spare CPU cycles, far
fewer are prepared to commit $2900 upfront for a mining appliance on the
argument that current conditions suggest they would recoup their outlay
in 100 days or so.  Even though ever more capital is committed to
verifying the bitcoin transaction history, it is being concentrated in
the hands of fewer people.

Another factor which has contributed to centralization arises from the
extremely sporadic (though large) minining rewards.  For instance, using
the above-mentioned $2900 bitcoin mining appliance, at the time of
writing the expected time between winning the lottery (about a $10,000
payout) is about 11 months, with a 10% probability of taking over 25
months. This high variability in payouts forces a mining operation to
keep a lot of cash on hand for ongoing costs like electricity and loan
repayments.  One way to smooth this pay schedule out is to pool efforts
with other miners.  With 1000 such miners cooperating, the expected time
to payout is just 8 hours, and a cashflow of $10 roughly every 8 hours
is much easier to manage than $10,000 roughly every 11 months.  And of
course the bigger the pool becomes, the lower the variance gets, so big
pools have a competitive advantage just from their size.  

This is a powerful centralizing force which has led to the majority of
hashes being generated in the service of just four mining pools at the
time of writing.  If the four entities running those pools were to
collude, they could rewrite the transaction history.  In June 2014, one
of these pools (GHash.IO) came to control 40% of bitcoin mining power
because it used its size and connections to present a sweeter deal to
miners than other pools could.  There were widespread concerns at the
time that the integrity of bitcoin might soon depend on the sheer good
will of GHash.  Many GHash miners moved to other pools in order to
prevent that, but in doing so they acted against their own short-term
economic interests, a clear failure of the mining incentive scheme as it
was originally intended, though so far not a catastrophic one.

* Attempts to make mining less capital-intensive

The centralizing force of customized mining hardware ("ASICs") was
widely recognized fairly early, and people attempted to mitigate the
issue by developing memory-intensive mining algorithms which they hoped
would run most efficiently on commodity CPUs.  It was hoped that since
with these algorithms most of the computation time is spent keeping track
track of large, mutating data sets, custom hardware would not provide a
significant advantage compared to the memory cache on commodity CPUs.
This has worked to some extent -- for instance, the per-hash cost of
custom hardware for mining LiteCoin (the first cryptocurrency to use
such an algorithm) is only about 100 times lower than mining on a
contemporary CPU.  However, the start-up costs necessary to gain this
efficiency are still high enough to motivate intensive centralization --
such a device currently costs $1600, and three pools currently control
more than half the LiteCoin hashing power.

There are also people researching mining algorithms which are so
computationally flexible that specialized hardware just doesn't make
sense for them.  SAT...
29  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 19, 2014, 05:12:31 AM
Just wanted to remind you all how I sold my coins at 698 satoshis a while back and everyone laughed at me for it.

I just want to remind you that you said you were holding on to 10k burst until you could get 800 sats a piece for them.
30  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 18, 2014, 05:46:51 AM
I'm looking for a paragraph on why Burst is ASIC resistant (I can write up something close enough)

Also a good description of how Proof of Capacity works on the checking side of things, as opposed to the plotting side.  Basically a description of the algorithm.

I'll take a crack at this.
31  Alternate cryptocurrencies / Altcoin Discussion / Re: which alts are left that have some serious promise and WHY?? in DETAIL. on: November 16, 2014, 02:14:30 AM
BURST.  Completely new algorithm for securing the blockchain, based on proof of storage capacity rather than proof of computation.  Much more efficient than existing cryptocurrencies, lower marginal cost for mining, therefore lower transaction costs.  Forked from and tracking NXT, so it's got all of NXT's sophisticated transactions, as well as a few besides.
32  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 13, 2014, 08:12:58 PM
I've just hammered the keyboard with random shift key presses and generated a very long string of characters that can't possibly be related to any language Smiley  That should do it LOL

Be careful, you can still end up with a low-entropy password that way.  A machine-generated password is safer.
33  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 11, 2014, 10:16:55 PM
I still don't understand how the deadline is calculated.. the infographic in the first post seems to indicate how plots are made.  I only vaguely understand how they are later utilized though to do the mining.

In this context, the details of the mining calculation themselves aren't that important, it's just that it takes substantial time to look up and process that many plots.  Knowing that you almost certainly have the best deadline means that you can get a jump start on that process.

Thanks for the thoughts about where to go next.  I may take a crack at writing an explanation about ASIC resistance at some point.
34  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 11, 2014, 08:14:22 PM
Why is there not a need to wait out deadlines?  Is it possible to force that and make blocks, and therefore chains containing them, that have not waited out the deadline invalid?

Most of the time, the attacker is going to get the best deadline on a fork, at least initially, particularly with no "Nothing at Stake" advantage, so it would make sense for an attacker to start calculating for the next fork as soon as his own best deadline is calculated.

- We really need to get more than one programmer on board.

I'd love to hear your opinions about the highest priority extensions needed in burst and the burst ecosystem.
35  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 11, 2014, 07:41:57 AM
The issue is let's say someone started working on a Proof of Work fork.  If they wanted to fake a fork that was 100 blocks long, they would have to remove 50% of the mining power from the main chain to create this fork, this would take 100 blocks to complete however.. by which point in time the network would be 100 blocks into the future, so they'd constantly be playing catch up.

The question is, can you occasionally say fake a fork like this in say 5 minutes with a large enough percentage of network resources that the network accepts and uses to overwrite the 10 confirmations of a blockchain which cheats the system and overrides that calculation?

This is not "Nothing At Stake."  That is an attack which can only work on a Proof of Stake currency (I know NXT has some defense against this.)  The idea is that since the mining process verifying the blockchain only requires a commitment of the currency the blockchain is tracking, it costs you nothing to mine on all current forks, giving a forking attack a substantial advantage.  That can't happen in a mining process which requires an economic commitment external to the blockchain.  Buterin is the guy to read about this.
36  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 08, 2014, 06:15:36 AM
As a general concept it seems nice, but it seems like it's far easier said than done, and you don't want to be misleading due to having overlooked something. It seems you'd need to include word lists of most major languages(you don't want to tell someone their short sentence is secure because you're not identifying words as words since it's in an unrecognised language), along with copies of major public domain literature(a user's favourite passage of the bible is not a good password, even if it has a high word count, but you'll never recognise it as such without including a copy). Even after bloating the client with all that, utilizing them in a rating algorithm might be non-trivial.

That's a good point.  How about a second login field where the user password is used to unlock a wallet in local storage containing a high-entropy machine-generated password, and making that the default for creation of new accounts?  And deprecating the existing login field with lots of scary warnings about easy passwords, adding a basic password checker to it, and a warning that acceptance by the checker is only the weakest possible assurance of password security?
37  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 07, 2014, 08:20:49 PM
I just broke the "send message" dialog by including an apostrophe in the transaction amount field (by copy/pasting the account balance and then reducing it slightly.)  The dialog has hung for over five minutes, saying "Submitting."
38  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 07, 2014, 08:11:21 PM
Would there be any interest in including something like http://www.passwordmeter.com/ into the passphrase pages along with some warnings and links to past thefts, to really beat people over the head with the importance of choosing a strong password?
39  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 06, 2014, 12:59:52 AM
i have'nt looked into the code on how the pk is used to sign transactions but i think it is ecdh based.
doing a google search for the included java code from nxt to do the signing brought up a site stating the sign function is not as secure as the original code where it was ported from to java. this is because java uses different size integers and a c big int variable has only the maximum size of an unsigned int in java (https://gist.github.com/doctorevil/9521116).
someone with java knowledge maybe can verify that the described flaw applies or hopefully does'nt apply to the code in src/java/nxt/crypto/Curve25519.java file or finds out this whole function is only included due to forking reasons.

this in combination with the wallet which offers 12 words OUT OF 1626 by default (html/ui/js/crypto/passphrasegenerator.js) makes it in my opinion attackable.
within an bruteforce attack this is less than 11 bit for each word which sums up to about 105 bits of combinations.
if the ecdh implementation shows the mentioned flaw it cuts internal 256 bit variables at 64 bit.
without further analysis this provides a option to bruteforce wallet generated keys by software designed to utilize this flaw by testing less than 32 bit of combinations. i am no crypto specialist and if someone with knowledge about all this could take a look into it would be great. i think as long as someone uses custom generated private keys even if the flaw exists in the code the required energy to break 105 bits is much more than what you get for the coins in the wallets. on the other hand it may be possible to bruteforce all known wallet addresses in one run without much more costs...

I think this is the relevant patch.

Code:
commit 56e44b38e524ea52a7b2f5a7e25d126c929ece72
Author: Jean-Luc Picard <jlp666@yandex.ru>
Date:   Sat Mar 15 06:05:36 2014 +0100

    applied Curve25519 patch from DoctorEvil

Come-From-Beyond claims that there were a number of deliberately-introduced vulnerabilities in the original NXT source code, to deter NXT clones.  It sounds like an incredibly irresponsible thing to do, but there it is.  Supposedly they're all patched, now.  Someone here probably knows the date of the last such patch... the NXT source should be checked for  patches to any vulnerabilities reported prior to that.

i currently do not understand why someone did'nt empty the whole account and only took 40k.
i dont want to make people panic sell and drive the price down but if you hold a certain amount of coins within one wallet think about all this if you used the wallet to generate your private key.

People should panic-sell.  Just let me in on the bargain-basement prices. :-)
40  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient HDD Mining | New version 1.1.5 on: November 05, 2014, 08:45:20 PM
My password is a random string of numbers and letters, caps and no caps, 30 symbols long. So weak password is not an issue.

By random, do you mean randomly machine generated, or chosen manually by you?

OS is Windows 8.1, so it stores the password in an unencrypted text file :/

https://www.virustotal.com/en/file/d3992c3d8be28d99b4f58b17a1d7eccbb04ba18e6471bcc3321a82b8011e0475/analysis/1413153796/

Either a false positive or  a very obscure trojan. After initial scam, this is hard to swallow and keep faith. Any insight into why this has shown up Dev?

no threat found on my end. false positive, its common with windows-qt and that particular antivirus


its scanned with 53 virus protectors and only 1/53 come up with a false positive
Alright, just thought I would check, have recently had some malware problems on the machine that hosts my wallets.

It looks like you have recently had security issues.  What steps have you taken to mitigate them?
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 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!