Bitcoin Forum
September 24, 2018, 04:34:02 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1]
1  Economy / Collectibles / Selling 10 BTC 1oz Silver Casascius Coin on: January 04, 2017, 04:52:41 AM
Hash: SHA1

Hi all, my account on bitcointalk was hijacked on 03/01/2017. I wasn't using this account for a while and had pretty easy password here. I'm really sorry for whatever who was scammed by the hacker Sad.

Now the account is better protected and fully back under my control.
Version: GnuPG v1

2  Alternate cryptocurrencies / Marketplace (Altcoins) / [CLOSED] on: January 04, 2017, 12:35:43 AM
Hash: SHA1

Hi all, my account on bitcointalk was hijacked on 03/01/2017. I wasn't using this account for a while and had pretty easy password here. I'm really sorry for whatever who was scammed by the hacker Sad.

Now the account is better protected and fully back under my control.
Version: GnuPG v1


I'm interested in buying high quantity of BTC.
The minimum I'm interested in buying is 5 BTC.

Paying 5% more LTC @ preev rate
3  Bitcoin / Electrum / Opensource Electrum builds for Windows (using Linux!) on: December 08, 2012, 03:31:08 PM
Hi all,

I spent last night by preparing Windows build process for Electrum client.

The goal for the future is to create deterministic Electrum builds, so anybody will be able to compile Electrum on his own and check that official binaries from website don't contain any malware. Currently the process is not fully deterministic yet (filesize is the same, but file contains parts in random order so it has different md5sum), but I'm pretty sure it can be solved sometimes.

Another goal of this project is that now you can create Electrum binaries even without having Windows installed, because build scripts are using Wine on Linux!

Build script isn't patching Electrum in any way. The goal is to create trusted build process, not optimize Electrum for Windows users. Please ask ThomasV for any Windows-related feature for the client.

Compiled binaries of Electrum for Windows:
Single executable, compressed file:
ZIP archive, uncompressed files:

How to compile Electrum on my own?
1. Builds were tested on more machines with Ubuntu 12.04 LTS and 12.10
2. Install Wine 1.4 (default in 12.04) or 1.5+ (don't use Wine 1.4.1 included in 12.10, there's issue with MSI installer; use wine PPA instead).
3. Download
3. Build scripts are already in Electrum git repository.
4. Copy /contrib/build-wine from git to / (yes, really, put it into the root; final binaries contains some paths, so extracting files to another location will affect final EXE!).
5. Run "./", it will download all dependencies. When you'll be asked, always leave default settings and press "Next >"
6. Build will create two separate versions in dist/ directory. One is "dist/electrum.exe", standalone compressed executable. Second one is directory "dist/electrum" containing uncompressed binaries, useful for comparsion with other builds.
7. If you want to rebuild new version of Electrum, just change path to ZIP file in "" and re-run script with "./ update". It will skip downloading all dependencies.

Nightly builds for Windows (EXE)
Visit to get nightly builds from Electrum's Git every day at 00:30 UTC.
4  Bitcoin / Development & Technical Discussion / Hardware wallet wire protocol on: November 16, 2012, 11:17:14 AM
Hi everybody,

after short discussion with someone42, we decided to start separate thread discussing wire protocol used for future hardware wallets. We would like to find some universal and flexible solution which can become a standard, to make easier life for programmers of bitcoin desktop clients.

My current proposal is to use generic class USB HID device, which can be used without installation of drivers across every major operating systems (especially MS Windows). There are some limitations, like 64 bytes of message payload and communication can be initiated only by the computer (polling).

I want to use HID protocol just like a transport for higher level protocol, instead of using some custom binary format. No, this time I'm not going to propose JSON-RPC :-), but I think Protocol Buffers is a good choice. There exists some lightweight implementations for microcontrollers, it is super-easy to use PB from every major programming language and it is well defined high level protocol (in comparsion to some custom-built protocol on top of HID messages).

There's my current draft of proto file:

I completely dropped the idea of storing custom private keys on the device, I plan to use the seed for BIP32 or Electrum algorithms on the device instead. It also makes the protocol a bit easier, because there's no need for messages handling with custom keys. I'll try to describe every message in my next post.

5  Bitcoin / Project Development / Hardware wallet name on: November 05, 2012, 02:00:37 PM

few moments ago I posted announcement of Bitcoin hardware wallet project, which we're working on ( At this stage, we have only internal codename for the project, but we're looking for business name for the final product.

We'll be very pleased if the community help us to find some catchy and unique name for the product. For that reason, I'm offering 1BTC bounty to whoever who post the name which we then use for our hardware wallet.

Unless it will have some hidden sense, please do *not* suggest names containing "bit", "coin", "key" or so. By participating in this bounty, you agree that you give up the copyright and any other rights related to the name. Also, to make this thread sane, please suggest maximum three names per post and up to three posts per user.
6  Bitcoin / Project Development / [ESHOP launched] Trezor: Bitcoin hardware wallet on: November 05, 2012, 01:45:11 PM

TREZOR finally for sale!

TREZOR The Bitcoin Safe is ultimately secure
and easy to use hardware bitcoin wallet.


Original post:

Hello all!

Today we'd like to announce a project I and stick have been working on for the last couple of weeks. We decided that we want to keep the development open since the beginning.

We are creating a hardware bitcoin wallet, basically a device that is a secure place to store private keys to your bitcoin addresses. Because all transactions are signed in the device itself, the keys never leave the device and thus cannot be stolen by a virus, malicious code or an attacker.

We believe that this project is very improtant for the bitcoin world, because it gives the ability to use the highest possible security measures, which were only available for geeks until now, for all bitcoin users, even the non-technical savvy ones.

There will be two versions of the wallet available:
1) A shield for Raspberry Pi (for DIY hackers)
2) Custom hardware based solution (for common consumers)

Both versions will be open-source (both hardware and software!) and will provide the same functionality, like for example:

* Deterministic BIP 0032 compatible wallet algorithm (=unlimited count of addresses)
* No need for periodic backups, writing down the seed to paper during the device initialization will be enough forever
* Unlimited count of inputs and outputs in transaction (transaction streaming API)
* Plug & Play - no driver installation on a desktop computer required
* Unauthorized physical access to wallet protected by PIN
* Optionally wallet will require one-time-passwords for important actions

Custom hardware version will have these extra features:

* Impossibility to obtain private keys from the device in a case of theft
* Impossibility to re-flash the device with malicious code
* Possibility to do paper-backup of private keys only once during wallet initialization
* iPod Shuffle sized aluminium case for durability and robustness
* Variety of colors to tell the wallets apart by simply looking at them

We believe that we have enough knowledge and experience to succesfully finalize this product. Stick is a hacker and he has been involved in development for quite some time. He's also one of the founders of Brmlab hackerspace, which you may know from Prague Bitcoin conference 2011. We've already done arrangements with a hardware manufacturer who has confirmed that he's able to deliver casings for our custom solution.

Sneak peek preview of our hardware:
7  Bitcoin / Electrum / [Electrum] Tor service at 4lhnnupincd3gyda.onion:50001 on: September 26, 2012, 11:29:10 PM

I just started Tor hidden service running Electrum server on 4lhnnupincd3gyda.onion:50001. Now you can use Electrum client without revealing your real identity and without a need of Tor exit nodes.

1. Install Tor
2. Run electrum 1.0 as: "electrum -p socks5:localhost:9050" (point Electrum client to your local Tor node)
3. View->Pro mode
4. Click to "Network" icon in right bottom corner and put "4lhnnupincd3gyda.onion:50001:t" into "Connect to" field.

8  Bitcoin / Electrum / [Electrum] Independent monitoring of running servers? on: September 24, 2012, 04:16:29 PM
Hello all,

weeks ago I knocked up simple script which crawl over all public electrum nodes, connect to them and periodically check if they're up to date with their blockchains:
(use easy_install twisted stratum to install dependencies)

Is there somebody interested in providing (public?) service which will:

a) Show current status of all known servers (up/down)
b) Send mail to electrum operator if his node crashed

It should be quite trivial for some pythonist by using my code, but I don't have free time to finalize it into some usable form.

Such service would be really useful, because electrum servers are sometimes crashing (you know, it's still beta software) and it may took some time to admin to realize that his node is down.

Edit 03.03.2013:
9  Bitcoin / Pools / [ANN] Stratum mining protocol - ASIC ready on: September 11, 2012, 03:07:01 AM
Hello all,

I'd like to announce my proposal for new pooled mining protocol.

All details and links can be found here:

I'm running experimental pool since yesterday. You can connect to it using mining proxy, which is linked from the document above.

Both pool source and mining proxy is opensource!

I'm waiting to your comments :-)
10  Bitcoin / Bitcoin Discussion / Hacked Linode & coins stolen to 1NRy8GbX56MymBhDYM... on: March 01, 2012, 07:37:35 PM
Short story:

Somebody hacked my backup machine with pool data hosted on Linode and steal 3094 BTC ("hot" coins ready for payouts). Cold backup was not affected in any way by this hack.

It looks that also user database has been compromised. Although passwords are stored in SHA1 with salt, I strongly recommend to change your password on the pool immediately.

Robery of Bitcoins has no impact to pool users, I'm covering the loss from my own income (although it means that many months of my work is wasted  Roll Eyes ).

Long story + evidence:

This morning I received SMS from pool monitoring that BTC balance went under expected amount, so I started investigating what happen. I saw that there was transaction moving 3094 BTC out of the pool wallet ( few minutes ago. I watched the logs and it didn't look like server has been compromised in any way.

Then I found that two of my Linode machines has been restarted half a hour ago, too, and root passwords has been changed. I changed passwords to new one and found that there was malicious activity on the machines. Then I discover that passwords were changed over Linode Manager (Linode web management), because there was record about password change in Host Job queue (last activity done over Manager). This also explains why attacker restarted machines, because it's necessary to apply this change from Manager.

I reported accident to Linode staff and asked for log of recent logins to Manager. To my surprise, there were only my own log attempts and last login before the attack was on 08/02/2012! I reported to Linode that something is going wrong, because I has been using strong password for my Linode Manager (because I know it's basically backdoor to my machines) and I didn't use this password on different places.

Full log of support ticket is here.

I'm still waiting what they'll find, but expect they'll try to hide any issue on their side and they will definitely reject to pay 3000 BTC for this attack :-/.

Few hours ago another guy contacted me that his Linode machine has been attacked and his coins was moved to the same wallet, asking me if I know what happen (because he found that 1Mining2 address is mine). We found that our issues are the same - changed password in Manager, stolen coins & Linode staff is telling they have no security issue on their side. Heh.

It looks like attackers found some vulnerability of Linode Manager and used it to infiltrate Linodes with running bitcoind (we both had bitcoind running on the machine), to gain maximum profit for the less rush (it does not look that so much machines has been hacked, at least I didn't find anything on twitter etc). It looks like attackers were interested only in Bitcoins, because they leave Namecoins untouched, although they have the same chance to steal them.

From the attacker's wallet it looks there were more people affected by this Linode hack, maybe they'll know anything more?


There's no reason to think that pool itself was hacked. I changed all passwords everywhere (mainly to database), moved coins to new wallet and everything is working fine. Backup machine didn't contain keys for accessing pool server, so there's no need to reinstall pool to another machine. I'm covering all financial loss from my own money, to keep pool users out of this stupid issue.
11  Bitcoin / Development & Technical Discussion / [Stratum] Overlay network protocol over Bitcoin on: December 27, 2011, 10:08:22 PM
Few days ago I started the discussion in Electrum client thread about new protocol and server implementation of overlay network over Bitcoin p2p network. I think that discussion is not anymore relevant to Electrum client itself, so I started this new thread dedicated to my proposal. Please comment my proposal, ask to anything or suggest any improvement if you want.

Network protocol proposal (in progress):

Server implementation (in progress):

Running nodes:
  • (TCP - 3333, HTTP - 8001), provider:
  • (TCP - 3333, HTTP - 8000), provider: (thanks!)

Short quote from google document, describing main purpose of such overlay network. (current codename is "Electrum platform", but I'm searching better name ATM: edit: "Stratum" won the contest for network name.

Electrum platform is a framework for creating lightweight Bitcoin clients (= clients without a blockchain, keeping only private keys). Absence of blockchain on the client side provide very good user experience, client has very small footprint and still provide high level of security and privacy.

Basically Electrum is overlay network on the top of Bitcoin P2P protocol, creating simplified facade for lightweight clients and hiding unnecessary complexity of decentralized protocol. However there’s much bigger potential in this overlay network than just providing simplified API for accessing blockchain stored on Electrum servers. For utilization of such potential, we definitely need some robust protocol providing enough flexibility for various type of Electrum clients and their purposes.

Some advanced ideas for Electrum network, which will need flexible network protocol:
* Integration of BTC/fiat exchanges into clients
* Wallet storages for diskless or extremely low-resource clients (AVR-based hardware wallets)
* Server-side escrows (sending bitcoins to email)
* Integration of bitcoin laundry
* Exchange calculators (for providing “fiat” equivalents of BTC in clients)
* Firstbits support
* Mining support for clients
* Various transport protocols (especially HTTP Push, which allows PHP websites to integrate with Bitcoin easily)

Requirements to protocol:

* Protocol should be as simple as possible. Some clients aren’t capable to handle high-level message systems like Google’s Protocol buffers or Apache Thrift.
* Protocol should be text-based. Some languages cannot handle binary data (javascript) or it’s pretty difficult to implement it correctly (PHP).
* Protocol must support standard RPC mechanism (request-response). Request should contains method identifier and parameters, response should be able to transfer error states/exceptions.
* Mapping between request and response must be clear. Don’t allow vague relation between request and response. Some message-based systems use only textual conventions to map requests and responses together, like ‘firstbits_resolve <firstbits>’ expects ‘firstbits_response <firstbits> <address>’ or ‘firstbits_error <firstbits> <reason>’. It creates ambiguous data flow, avoid it.
* Protocol should support publish-subscribe mechanism. Client can subscribe on server for receiving some kind of information. After this request, server will proactively broadcast messages to subscribed clients until client disconnects or cancel it’s subscription.
* Protocol must be bi-directional. In the opposite of standard client-server model, we sometimes need to allow server to initiate the communication. As an example, server can ask client to reconnect to another node (before switching to maintenance mode) or send some text message to user.
12  Bitcoin / Project Development / [CLOSED] 2 BTC for suggesting a name of an overlay network on top of Bitcoin on: December 27, 2011, 08:45:06 PM
I'm involved in development of Electrum client, which is very cool concept of chainless Bitcoin clients. Electrum client don't handle copy of Bitcoin blockchain, but ask servers for necessary information. Few days ago I proposed new version of network protocol ( and I'm implementing server on top of this specification (not finished yet; My goal is to provide general-purpose server protocol and implementation, which act as overlay network over Bitcoin p2p network, providing bitcoin-related services for lightweight clients, eshop implementations etc.

genjix suggested that such server protocol/implementation should have it's own name to not confuse Electrum users. Although I like name "Electrum", I agree that using another name for server side and protocol is really good idea.

So I'm opening this contest to find some cool sounding name for such overlay network. I'm keeping the right to not pick any of suggested name and only the winner receive those 2 BTC. Please don't propose anything with bit* or *coin, I think there's already a lot of projects with similar names.
13  Bitcoin / Project Development / [idea] Escrow service / cold storage, building trust for merchants and services on: October 29, 2011, 02:45:14 PM
I've been thinking a lot how to help building real Bitcoin economic. There are many shops and other services built on Bitcoin ("bitcoin shop" on google is giving me 13 milions results!), but I cannot resist the feeling that many of them doesn't look trustworthy.

And building trust on Internet and especially in Bitcoin community is really really hard. You probably remember all those recent scams as bitcoin7 and mybitcoin, right?

I'm personally very cautious which services I'm using and I'm always searching the Internet for good references. But this is chicken and egg problem. When there's new service, how it can prove they're trustworthy? Like this one (, which popped up today. It's new web wallet specialized for merchants and looks professional, but isn't that only new generation of mybitcoin scam? How can people trust them with storing funds?

So I have one idea, but it's mostly request for comments, nothing well-advised yet. Maybe we find some major flaw why it won't work, but nevermind.

Let's create escrow specialized for new services and for building their initial trust.

a) New services can deposit xxx coins to this escrow, which will be used as assurance in case they'll suddenly disappear or they got hacked (you know, many new useful services are usually in alpha or beta stage, it's hard to trust owner AND his alpha software).
b) Existing and well-settled services can use this escrow for their cold storage backup, as act of their openness to community.

ad b)
All bigger services (which are also well designed) are using some kind of cold storage (coins, which are managed by service, but they don't need to be used instantly, so they're stored on some offline medium). This is really good way how to protect user's funds against hackers. However users must believe this cold storage is well designed. Also many services are mostly one-man shows (like my pool :-) ); what happen when owner will die (God forbid!)? All coins will be probably lost, even when this owner had good reputation.

Every service which want to build their trust in community by using this escrow should decide how many coins will deposit here. Of course merchant selling Alpaca socks don't need such big assurance as new ewallet. They can also claim they'll be storing some percent of all received coins here as a cold backup, which also depends on type of business. Typical ewallet or exchange can probably store more than 70% of all coins to cold backup without any problem, because most of received coins is just sitting here forever. Service simply announce their rules for using escrow and then they receive permanent address for storing funds. Finally they can use the fact they're using this escrow/cold backup on their website or promotion. There can exist simple public web UI which display contract details for given service so everybody can check if this service is really depositing enough funds.

* If it will work and will be succesful, in escrow will be probably huge amount of coins stored for longer time period. Fortunately, they don't need to be accessed online most of the time, so internal cold storage is a perfect way to go.
* Private keys for cold storages can be encrypted with erasure coding and every part can be provided to many well-trusted members of Bitcoin community. Thanks to this, there need to be a consensus of more people before cold storage will be accessed and coins used, because no single entity can take all coins from escrow and disappear.

Known problems:
1) How to check how many coins should be in escrow if service make a promise to pay some percent of their funds?
2) How to decide who to pay after service crash.
3) Service itself can act as many of customers in claiming process after crash, which will reduce paybacks for regular users.
4) How to pick "trusted members"?

ad 1)
It's for longer discussion, but I'm thinking about concept of reversed "green addresses". Service will use their green address for consolidating all income from customers. Every customer can check if his funds sent to this service has been transferred to this address and thus confessed as service income. Of course not many services will want to publicly show their income, but it's absolutely their choice; they'll receive additional trust for their openess. Personally I don't think revealing this information is so much sensitive. Total income and at least rough estimation of cold backup amount for the biggest Bitcoin services is usually publicly known (at least for Mt Gox and other exchanges and for most of the pools).

ad 2)
Depositing coins to escrow is pretty good signal for community that they're serious about their business, however it's only one part of problem. What if this service get really hacked or owner disappear? It's not not easy to answer who to pay and it depends on type of business. I can image that for some smaller business will be enough to make a promise like "If I disappear, use all those coins to Bitcoin development and give it to Bitcoin foundation". However users of bigger services (like exchange) will probably want to receive back at least part of their funds. There are still many solutions in the game, just two extreme ideas:

* Board of trusted members (holders of erasure coded private key for service funds?) will be established and they'll approve user's claims using some facts (realized transactions from private wallets to service wallet, scans of bank transfers etc). This can be a lot of work and nothing for impatient people. This also won't be absolutely fair, because not all users can provide enough evidence about all their funds stored there. But world isn't perfect and the main target is that funds from cold storage will be distributed back between people.

* Second way is more automated. If merchant will be interested, they can provide (daily) snapshots of customer's funds stored there, with absolute amounts or just as a percents of all funds. This report can be private, accessible only for erasure key holders, to protect personal data (account balances) of customers. Actually refunding wallet & share on total funds is necessary. This is of course related to point 3) below, but those snapshots can be used at least as starting point for next investigation (I have some idea for following discussion, if anybody will be interested).

ad 3)
To be discussed. Any idea?

ad 4)
Of course there's tiny chance that trusted members from Bitcoin community and holders of erasure coded private keys will make a devil plan, steal all deposited funds and buy some nice island on Bahamas. But every service can nominate another "trusted users" from Bitcoin community (and it's only up to people if they're trusted enough to believe it's not yet well-elaborated scam). Thanks to this, it's not necessary that all funds stored in escrow will be in hands of few people.

Concept of escrow/cold storage can be very flexible. I can imagine that somebody will deposit 2000 BTC on his service launch and claim his intention to send it (in case of scam/hack) to Bitcoin developers (or ongoing Bitcoin foundation?) as his commitment. Another extreme can be a cold backup of some exchange and tight integration of with escrow, so when service got hacked or operator disappear, every registered member will get his fair share of deposited funds. But it's definitely case to case what will fit better for given business.

Any suggestions?

Edit: Heh, much longer post than I initially expected :-).
14  Bitcoin / Pools / BTCGuild and it's relation to DDoS attackers on: October 20, 2011, 02:00:25 PM

I have very strong evidence that is somehow related to those DDoS attacks.

I think that I owe an explanation about my yesterdays "accusation" that is behind last DDoS attacks. Let me clarify that I'm not saying that is an *attacker*, but that there's some relation between this pool and attackers, which is big difference. I'll try to use only hard facts in following text.

Firstly, let me talk about how those attacks worked. Basically it's network of thousands zombie computers, listening it's operator and doing some simple commands like "flood some specific IP address". There's no or very small chance to shut this botnet down. All people asking me to use whitelisting or filtering this traffic on server don't really understand, how massive those attacks are. If you have 100Mbit pipe to server, but attacker's uplink is 1Gbit, there's no chance to filter out this traffic, because your pipe is simply too small. You may say that buying a bigger pipe is a solution, but actually it isn't. Actually last attacks were far over 1Gbit/s and paying dedicated 10Gbit line is simply out of my financial possibilities.

During many of those attacks I learned a lot how they're working. I tried everything; setting up more balancers, using DDoS mitigation proxies etc. But *everytime* when I changed DNS records to new IP or even when I created yet another DNS record (do you remember my post about new DNS last week?), attack followed those changes in DNS or posts on forum almost immediately. Thanks to that I know attacker is here between us, following what's going and targeting attack to new places instantly (in matter of minutes).

I don't remember when exactly I had first DDoS attack, but as I was the biggest pool, attacking to me was pretty logical step. Later, when deepbit had higher hashrate than me, attacking two biggest pools was still pretty good way how to harm Bitcoin network. However last two attacks where more pool was affected, attackers picked first (deepbit) and *third* (my) pool.

I know btcguild once had massive many-days DDoS attack, but it was related to banning some botnet out of his pool. I'm not actively following btcguild community, but as other people told me, those attack finished to "peace agreement" between some botnets and btcguild, because btcguild probably understood that it has no sense to fight with them. Personally I understand that; if I would have an options to reject botnet and be ddossed to death or silently accept them and don't receive attacks, I'll probably pick first one, too.

Yesterday I did one thing which I'm proud of, but which was a logical step in closing the circle; what happen when I change my DNS to btcguild servers? At this time, me and deepbit were completely off, but btcguild had even higher hashrate (probably thanks to failover configurations in miners). So I modify DNS records and point everything to I had 5minutes DNS timeouts, so there was an easy way how to revert this traffic back from btcguild.

As I expected, nothing happen. I leaved DNS to btcguild over a half of hour, which was many times longer than botnet need to switch to new IP address before. And btcguild was still untouched.

You may say that btcguild is using some DDoS protection, so redirecting traffic didn't affect them so much as me. But those IPs are owned by Hetzner Online AG, the same housing company as deepbit is using and which was convicted that they cannot handle DDoS attacks. This is also reason why deepbit isn't using them for facing DDoS attacks and he uses 3rd party company to handle it.

There's only one logical conclusion - an attacker didn't want to shut down for some reason. If I don't want to say that btcguild itself is an attacker, then I can at least say that attacker is probably using btcguild and he don't want to shoot his own leg.

Note: Currently is btcguild under an attack, too. I don't want to speculate more, because I don't have any more facts for current situation. However this attack started after I moved DNS back to my servers and post about attack on forum.

There's yet another strange stuff on btcguild. As cosurgi calculated and other guys confirmed by re-calculation. It practically means that 4% of accepted shares of btcguild cannot be used to "win" a bitcoin block. Although btcguild rejected that those 4% are anything more than bad luck, with thousands of mined blocks there is really tiny chance that this variance is "natural". From cosurgi's calculations you can see that other pools fits mathematical expectations. Basically there are three general explanations why btcguild performs so badly:

a) btcguild operator is cheating and those 4% are hidden fees
b) there is some major bug in pool software he's using. This cannot be just a downtime, because those 4% shares were accepted.
c) it's an evidence of an "withdrawal attack" (attack where miner is submitting only shares which don't fit full difficulty)

Until now, all points were hard facts. Let's me say my own opinion:
* Personally I'm inclined to point c), becuse I don't believe that any pool operator is intentionally stealing so much; as you see, it is pretty easily detectable after some time. However point c) fits pretty good to an image of botnet trying to earn money for himself, but otherwise hurting bitcoin network (including withdrawal attack hurting other pool users). 4% from 2THashes are something like 80GHashes, which is doable by medium-sized botnet.

* However if I'm right at least in few points, btcguild is only one entity who can try to track who is an attacker, because *if* one of his mining botnet is one who's attacking to other pools (to lower difficulty and earn more for him) and at least partially protect btcguild itself (because he don't want to hurt his own pool), then btcguild have some IPs and also payout wallet of attacker, which can be small pieces in a puzzle.

I agree that last points are wild speculation, but the first part of this post are hard facts. Please think about it before you'll write that I'm kicking around me. Personally I wish all best to operational pools, because they're very important part of Bitcoin ecosystem; and as I wrote yesterday, I believe in Bitcoin success. However I wrote everything important now and I don't want to join some following flamewar; I didn't write anything personal against other pool operators. Now I'm locking myself to room just with pen and paper and I'm thinking how to make pools more DDoS resilent.

15  Economy / Marketplace / Anyone willing to sell 1oz gold bars for Bitcoins in Europe? on: May 16, 2011, 08:58:51 PM
Is there anybody willing to sell 1oz gold bars (with certificate) for bitcoins, delivery in Europe?
16  Economy / Trading Discussion / SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: April 18, 2011, 01:51:38 AM
SierraChart is desktop application providing a professional Trading, Real-time and Historical Charting, and Technical Analysis platform for the financial markets. It's not so intuitive as other platforms, but once you learn how it works (and remember few shortcuts), it is very strong tool for professional technical analysis. Because of lacking real trading tools for Bitcoin economy, I decided to write simple Bitcoin markets->Sierrachart bridge, which enable real time Bitcoin charting in Sierrachart.

How to start
  • 1. Download and install SierraChart software (use default settings and data directory)
  • 2. Download SierraChart feed for bitcoin markets.
  • 3. Start feed in a console. No parameters required list of all parameters: sierrachartfeed.exe --help
  • 4. Start SierraChart software
  • 5. Go to File->New/Open Intraday Chart and select (for example) mtgoxUSD.scid
  • 6. Customize your view using F5 (chart settings) and F6 (analysis/studies) menus
  • 7. Enjoy real time charting!

After those steps, you should see something similar like following image:

Used settings/indicators in this screenshot: 60min candles, Volume, Current price line, Moving Average-Exponential, vertical line every week. There are hundreds of other indicators and studies. I'm sure you will find something which fit your needs...

Linux support
Sierrachart recently released version without .NET requirements, which runs nicely on Linux under Wine. You can download this version on (choose "No-.NET/CLR" version). This version is still under development so it is missing some fancy studies and features, but it works well for basic charting.

sierrachartfeed.exe is using's CSV feed for historical downloads and socket API for real time updates of all charts published on Thanks tcatm for providing this API on his amazing website!

Source (github repository) for sierrachartfeed is available here.
Source code (ZIP archive) for latest release is here.

09.12.2012 - Fixed issue with endianess, runs natively on Linux now.
27.04.2012 - Automatic storing of all Bitcoin markets, added --volume-precision option.
23.11.2011 - Dropped support for mtgox websocket, using bitcoinchart socket connection instead.
07.09.2011 - Added multicurrency support for Mtgox. Please update to avoid weird price peaks.
17  Bitcoin / Pools / [4+ EH] Slush Pool (; Overt AsicBoost; World First Mining Pool on: November 27, 2010, 01:45:41 PM

News | Pool Statistics | Block History | Help Center | Demo Account

We are the world's first cryptocurrency mining pool founded in 2010.
Since then we have together mined over 1 million BTC.

Reasons to mine on Slush Pool

  • low flat fee of 2 % (network fees are shared with miners!)
  • stable income thanks to our significant network share (~ 15 blocks a day)
  • neat interface with dashboard and worker monitoring
  • advanced security with 2FA and payout address locking
  • servers in Europe, North America and Asia
  • free withdrawals above 0.01 BTC
  • Overt AsicBoost compatible

Start mining on Slush Pool


  • Create a ticket in our support system, if you have any issues or questions.
  • We will get back to you as soon as possible, usually within 24 hours.
  • We cannot guarantee answering questions posted elsewhere. Thank you for understanding.

Follow us: Twitter | Facebook | Blog

Original post:
Once people started to use GPU enabled computers for mining, mining became very hard for other people. I'm on bitcoin for few weeks and didn't find block yet (I'm mining on three CPUs). When many people have slow CPUs and they mining separately, each of them compete among themselves AND against rich GPU bastards ;-), because everybody counts sha256 hashes from the same range. Two separate CPUs with 1000khash/s isn't the same as one 2000khash/s machine!. But new feature of the official bitcoin client called 'getwork' now enables work of many computers together, so they don't compete. Because there is now standalone CPU miner (thanks to jgarzik!) and 'getwork' patch is in official client now, I have an idea:

Join poor CPU miners to one cluster and increase their chance to find a block!

How that should work? There will be web page where you can register, enter your wallet address and get URL and your personal rpcuser/rpcpassword for your CPU/GPU miners. When you start own miner with these credentials, server will send you work which was not calculated yet by other members of cluster.

But when your client find winning hash, you do not get full reward for block (50BTC right now), but only proportional part, which you calculate. When you offer 1000khash/s for one day and whole cluster performance will be 20000khash/s and it takes two days to find a block, your reward will be (50/20/2=)1.25BTC.

Advantages? When you have poor standalone computer, you need to wait many weeks or even months for finding full 50BTC reward. When you join cluster like this, you will constantly receive small amount of bitcoins every day or week (depends on full cluster performance).

Disadvantages? You need to trust in central authority (me) that I don't steal block for myself. But I'm goofing around for few week and I'm amazed with bitcoin idea, so I don't plan to steal anybody right now :-).

Another possible problem is that somebody will ask for new work very often, but in fact he will not count real hashes. In this case it will look like he has very strong CPU and he should get big part of reward if cluster find a block. But there is a simple defense against cheaters: Central server sometimes send work which leads to 'winning' hash. Worker which don't return this hash as matching will be permanently banned (login/password and IP address). This was succesfully solved by letting miners calculate proof-of-work. It is not anymore possible to be a part of cluster and not count hashes.

Are you interested in?
18  Economy / Trading Discussion / Is AlertPay better than PayPal? on: November 25, 2010, 10:01:39 PM
Does anybody have any experience with AlertPay? It is safer than PayPal for sellers? I mean chargebacks etc...
19  Bitcoin / Development & Technical Discussion / Bitcoin Protocol Specification on: November 20, 2010, 06:09:48 PM

I'm surprised that there is no complete documentation of current protocol specification at this time. I found something on wiki and some fragments on pybitcoin pages But there are many blank pieces (unknown bytes in format etc).

I'm missing also some standard way for protocol proposals - everything is done here on the forum in some obscure process (at least obscure for me). I think it is because bitcoin community is still quite small, but we should define standard processes for that when we want to grow.

I would like to implement own library (in python) to support bitcoin protocol, but I realized that there is no easy way until I'm familiar with cpp and official client sources. There are also many 'hacks' like limited block size, which are related to protocol itself than on client implementation.

Also one dumb question - it is really needed to have binary protocol for our intentions? I think something more standardized should be more friendly to programmers in another languages (say java) and on another platform (I don't need to solve 32/64 bit problems on datatypes etc) when I defined protocol as (for example) gzipped xml (like other opensource data formats).

Currently there is big barrier to bring new clients with cool new features, but because I don't know lowlevel internals of bitcoin client, I don't know how to improve this situation for now :-(.
20  Bitcoin / Development & Technical Discussion / Potential vulnerability of hash function? on: November 20, 2010, 05:20:20 AM

I discussed bitcoins with my friend today, he is something-like-mathematician. I told them that bitcoins are safe, because:

* are built on widely used and not-yet-broken hashing function
* when somebody find weakness of this hash function, it will be probably big problem also for other companies - banks, army etc.
* if weakness will be found, it will not be only bitcoin specific. In this case, bitcoin software can switch it's hash function in nearest software version to something not yet broken before massive attack to bitcoin mining infrastructure

I hope that are correct arguments, aren't they? He was almost ok with that, just with this comment, which don't let me sleep. Please correct me, if it is wrong in some point:

Some new block of 50BTCs is valid, when hash itself fullfill some requirement, so we can crosscheck it's validity. Something h = f(x) where f is hashing function, x is salt we use for validity check and h is hash itself. But we do not looking forward some specific 'h', just kind of 'h' which fullfill defined requirements. So breaking this is much more easier than breaking whole hashing function in terms 'give me _specific_ "h" and I will give you salt "x" which matches h=f(x)" as is valid for already broken MD5, for example. There are plenty of valid 'h' hashes, so we are not forced to full break of hashing function!

This vulnerability is just teoretical - we both don't say that we know how to break hashing function in this way! I just noticed that breaking hashing function for purposes of generating bitcoins is many-degree easier and does not mean that attack can be publicly used for breaking of general encryption. So teoretically there can be attack which can be used on bitcoin mining, but will not be in public interest, because common usage of hashing function will still be valid.

Am I correct or I missed something big in my ideas? Unfortunately I didn't find any detailed bitcoin algorithm or protocol description and I found source codes too much obscure to find these details directly here.

Pages: [1]
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!