Bitcoin Forum
October 16, 2018, 01:01:00 AM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1]
1  Bitcoin / Bitcoin Discussion / You don't need a mobile device to make lightning payments on: September 03, 2018, 09:58:06 PM
I would like to dispell the myth that you need a mobile device to pay at a store with lightning. I personally don't carry a phone or such device with me when I am outside.

I think it is quite simple actually.

1) Set up a lightning node at home
2) Print little paper bills with QR codes that act as one time auth keys for telling your node to send money with lightning. Print different denominations such as 10k satoshi, 50k satoshi, 100k satoshi
3) At the store, whatever the price, you give the paper bills and they scan them, and (as long as they have a computer with an internet connection) then your node sends the right amount. The denomination of the bill would specify the maximum that your node would send for the auth key. So if you have to pay the store cashier 152k satoshi, then you would give a 100k bill, a 50k bill, and a 10k bill. Yes they may steal 8k satoshi from the extra amount allowed by your 10k bill, but that's worth like 50 cents now, so it's a small risk, and you can use smaller denominations if you wish.

This type of setup would need a standard protocol that nodes use and cashiers would have on their computers, so would be worth starting on this if someone wants.

Edit: You can also use plastic/cardboard cards with a fixed code that has a daily limit and you can set "approved merchants" that are identified by public keys, and each merchant can have a unique daily limit.
2  Bitcoin / Development & Technical Discussion / Solving Selfish/Colluding Mining on: September 02, 2018, 08:09:33 PM
As I understand, selfish mining is an attack where miners collude to
mine at a lower hashrate than with all miners working independently.
What are the current strategies used to prevent this and what are the
future plans?

One idea I have is to let the block reward get "modulated" according
to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
consisting of 144 blocks, h is the hashrate of the last 144 block (1
day) period, and r is the base subsidy (12.5 BTC currently). You can
then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
peak you get the full reward. Otherwise you get less, down to a min of
0.5 r.

If miners were to collude to mine at a lower than peak hashrate, then
they may be able to do it profitably for 144 blocks, but after that,
the reward would get modulated and it wouldn't be so much in their
interest to continue mining at the lower hashrate.

What flaws are there with this? I know it could be controversial due
to easier mining present for early miners, so maybe it would have to
be done in combination with a new more dynamic difficulty adjustment
algorithm. But I don't see how hashrate can continue rising
indefinitely, so a solution should be made for selfish mining.

Also when subsidies stop and a fee market is needed, I guess a portion
of the fees can be withheld for later if hashrate is not at peak.

Edit: There are 3 classes of attacks I'm worried about and my proposal currently is just to modulate the fees on a voluntary user basis
3  Bitcoin / Project Development / New Sidechain - An Alternative to Bitmark on: August 18, 2018, 01:07:02 PM
I was a developer for Bitmark since early 2017. I created most of the protocol changes that transformed it from a simple SCRYPT chain to an 8 algo chain with full merge mining support. The idea is to create a decentralized reputation platform or a web of trust. Right now it mostly functions as a highly secure and reliable ( blockchain for use as a currency or for embedding data in transactions. The leaders of the Bitmark development team now want to release a fork that would only serve to manipulate the price from the supply side and that would obviously and permanently harm the value of Bitmark (

I have some ideas on how to build a meaningful web of trust ( It would rely on a sort of betting market, similar to how Truthcoin/Hivemind works, but I would like to start with something very simple (but still powerful), and focused entirely on building a web of trust, one "web" for each "category" that someone "funds". And each web would be like a function that depends on the user of that web (initial assumptions are needed as to who you trust in order to create your personalized web of trust). I think this would be a good first step in creating a truly decentralized and meaningful search engine, where people can quickly access information they find useful based on who they have "marked" in the past as reputable for whatever category (and those who were marked would mark others, and you may trust their marking judgements to some degree as quantified in your markings).

I can launch a new "coin" and have it be traded with other "coins", but I am now leaning more towards the idea of just using bitcoin as the currency, and place the chain a sidechain of Bitcoin. Yes there are still trust issues with how sidechain coins are unlocked, but since the point of this project is to create a reputation platform, I think solving the "who is reputable enough to unlock coins" problem could be a first step. A category for that can be created and then whenever someone wants to add funds to the sidechain, they would have to for example, use 2 signing keys from the "top 10" most reputable keys from that category, and they can use 1 from whoever they want, and to unlock would need 2 out of 3. The top 10 can be constructed based on how much fees are paid to bet on or donate to those keys overall. If this all works, and miners get comfortable with the system, then it can perhaps be used for introducing new sidechains (let them use this sidechain to determine who can be trusted for unlocking coins). I realize that in the future more efficient zero knowledge proofs will allow for a trustless use of sidechains, but for now this can be a good alternative.

A lot of the implementation ideas are rough, but I hope it makes sense and if there is enough interest, then people can help me build something that would strengthen the value of Bitcoin, and further decentralize mining (what sidechains do). I have an idea for the name, but I will save that for later Smiley
4  Alternate cryptocurrencies / Marketplace (Altcoins) / Need X17 hashpower on: March 20, 2018, 07:26:45 PM
I need some temporary X17 hashpower to get altcoin blocks moving again. I see X15 on nicehash, but I know that X17 can work on GPUs too. I need someone who has around 10 GPUs at least and that should be enough hashpower. I think the last hashrate was around 40 GH/s, but abandoned, but anything in the megahash range should at least get a block per day I estimate. Price negotiable.
5  Bitcoin / Development & Technical Discussion / The Soft Fork Deception on: October 28, 2016, 09:45:09 AM
Hi here is my post to the mailing list:

Everyone needs to be aware of this. I support 1 MB blocks and I support Seg Wit, but I do NOT support the forceful way in which Seg Wit is being deployed. It will inevitably lead to a hard fork.

Here is confirmation that my fear is true:
No, the attack blocks would, but the attacking miners would still accept segwit transactions, so segwit would not "become a hard fork"-- only the removal of it would be.
-nullc (Gregory Maxwell)

Edit:  I may be wrong on something here, but I still need to think about it. See posts below.
6  Other / Meta / Asking for funding a project not allowed? on: January 09, 2016, 10:30:57 AM

I posted a new topic yesterday where I asked for funding a Bitcoin project. Why did it get deleted? Is it because I put an address there explicitly?

What's the policy?
7  Bitcoin / Project Development / Need funding for Bitcoin Scaling Work on: January 08, 2016, 11:51:21 AM
Hi, I have proposed a scaling solution before called "Scaling Bitcoin with Subchains": I have seen other similar proposals like treechains, sharding, etc:

(No this is not the same as Peter R's subchains)

I don't see any development progressing in this area and I would like to help. It seems the general conclusion is "it's too complex". But, I disagree: I think it is the simplest/most straightforward way to scale to arbitrary transaction volumes. Segregated witness seems ok (still need to see how it will be implemented), but it is not a full scaling solution. As transaction volumes keep increasing we need to have some solution ready. Even if a better solution comes along later on, we need a working solution, and it can be used as a benchmark to compare with other solutions.

I am ready to work on this, and I think I have enough experience to get this done on my own. You can see my web page for some links to my work. My goal would be to fork Bitcoin Core to add these features, and have it tested on Test-Net. I need some time to get more used to the code base, but I think I can have a working solution done in 6-12 months. I can also create a formal white paper if people wish.

I currently moved to a new country to lower my living costs, and I basically need 1000 USD/month to live comfortably. Since I expect Bitcoin to continue its up-trend, I would accept 1 BTC/month to cover my expenses. I created a new donation address: 12pdFSHyJTEQaqs1qUzkxxX25SCt4GBzsq.

If I receive x bitcoins to this address, I will work full time on this for x months (12 months maximum for now). Later, I may adjust the rate to the exchange rate. I promise not to let anyone's donations influence the goals of the project. If I don't get enough funding, then I'll continue looking for freelance jobs, but will only be able to work part time on this.

I can also attach a PGP-signed version of this message, but my subkey expired in November, and I am currently unable to find the password for my master key Smiley, so this is the best I have for now.

8  Bitcoin / Development & Technical Discussion / UTXO commitments - Possible Problems? on: June 20, 2015, 10:47:19 PM
I read a few descriptions recently about UTXO commitment schemes. But is this idea really robust? To prove the UTXO status of an output, you need a branch of hashes from the merkle tree that stores the UTXO state of all outputs. So yes, this branch would be O(log n) in size where n is the size of the UTXO database. But...what gives incentive to nodes to relay these branches to people? How do you know they will not deny the service?
9  Bitcoin / Development & Technical Discussion / Scaling Bitcoin with Subchains on: June 07, 2015, 11:02:05 AM
tl; dr: This is a soft-fork way to allow Bitcoin to have an arbitrarily high transaction rate, without increasing the block size, and improving decentralisation. Yes it adds some complexity, but if you understand it carefully, you will see that it significantly improves the protection against censorship attacks and mining centralization. I'm not saying this is the best way to do things, and exact details can be tweaked, but I haven't seen a better proposal (Lightning alone has limitations), and it is definitely better than simply increasing the block size. As I have calculated, even 10 MB blocks is too much centralisation for many years to come, and the limit can instead be regulated with a softfork that forces miners to mine at a higher difficulty if they want bigger blocks.

I posted this to the Bitcoin-development mailing list a few weeks ago: Please read that post. Here I want to clarify some things and add some more details.

It is similar to the tree chains idea by Peter Todd, but I think it solves some problems that those had. It is kind of like sidechains, but the chains are not independent. You can call also call it a form of "blockchain extensions", something that Adam Back (inventor of hashcash) likes: So I just chose to call it “subchains” to distinguish it from the other similar concepts.

The idea is that you add ten blockchains, each with a 1 MB block size, that are validated by the main chain (the one we use now). The main chain can validate them by recording a hash of each of the chains’ block headers inside its own block header; so the 10 chains are synchronized with the main chain. As you know from the sidechains paper  ( you can transfer Bitcoin between chains, and this is made easier now since the chains are synchronized, and the child chain always trusts the parent chain.

So now you have the equivalent of 11 MB blocks, but spread out on 11 chains. The benefit is that now you can choose what chain to store/validate. If you have only one chain, then you need to store all blocks (since a long term period) in order to see and validate all the transactions that occurred on that chain. The key word is “see”. An SPV node can validate whether a transaction occurred or not, but it is not certain whether it is looking at ALL the transactions (some can be hidden by full nodes) and, as I explained in the mailing list post, a heavily pruned node is BAD for transparency (keeping powerful entities such as governments and corporations in check). You cannot just store a subset of transactions from a chain that are important to you, since the validity of each new block depends on the validity of the previous blocks.

Due to the relationships between the chains and the sizes of the blocks, you only need to store two chains. You (and everyone else) stores the main chain. But you only need to store one of the 10 subchains. Just make sure to keep all of your transactions on that one chain that you choose. Transactions that include two different subchains will be recorded on each chain (so there is some duplication) Thus, you get the power of an 1+10 MB / 2 = 6 MB block size while only storing/validating two chains each with 1 MB blocks, which is equivalent in terms of storage size / computing power of you storing/validating a blockchain with a 2 MB block size. If you want to keep track of transactions that are in another subchain (such as the public purchases being made by your government MP), you can store and validate that one too, so you need the equivalent of 3 MB per block in that case. You can also have an alternate identity that uses a different blockchain... In general, the amount you store/validate is proportional to the amount of “stuff” you want to keep track of. With this kind of partitioning scheme you have the freedom to finely tune what you store/validate, instead of being forced to follow a “one size fits all” policy.

You can keep going like this by adding 10 children chains for each of the 10 subchains, resulting in 100 more chains (now we have the equivalent of a 1+10/2+100/2 = 56 MB block size with each participant required to only store/validate 3 MB. For 4 levels, you have the equivalent of 1+10/2+100/2+1000/2 = 556 MB block size with each participant only needing 4 MB. In general, if you have n levels of blockchains, the network has O(5^(n-1)) transactions, while each participant only stores O(n) of them. In other words, each participant stores/validates ~ log(N) transactions where N is the number of transactions in the network. This is far better than the ~ N^2 requirement on each participant if every transaction just happens on one chain. Note, even if you want to store/validate transactions on a chain, you don’t have to fully store/validate the parent of that chain. You just need the block headers of the parent chains in order to validate each block in the chain. Also, miners on a chain will only need the headers of the 10 child chains in order to validate the transactions going on in the child chains. The idea is that higher valued transactions will be performed on the chains that are higher up in the hierarchy, while lower valued transactions on the chains that are lower in the heirarchy.

For any chain that a miner mines on, it will be merged mined with its parent chain, so a miner has a chance of getting the rewards from the parent chain and also strengthening the hash power of the parent chain. Big miners will tend to stick to the upper level chains, since they will have the highest transaction fees (as well as a coinbase reward for the main chain). Note: Initially I thought that miners should merge-mine with the main chain, but then you wouldn’t have good mining decentralization, right?

Other things: Chains that are too empty have an incentive to be filled up with transactions since the transaction fees are lower there. For instant transactions, contracts, we can use Lightning channels attached to whatever chains you want. Privacy would be enhanced since it would be hard for one node to store all transactions when the number of transactions get very large.

To illustrate the point, I made a diagram:

Initially, I wanted to draw a classical tree-like structure, but it was awkward to fit all the nodes, so I decided to go with the circular structure. With just one blockchain, we are sticking all transactions in the center black dot (centralisation). With more blockchains, we can spread things out, let everyone contribute, and actually scale for a higher transaction rate than possible with the centralised model (no more O(N^2) or even O(N)).

One more thing: Recently, I have been thinking of ways to add flexibility to the block size, so that it is relevant even with better computing technology. As you should know, miners hash block headers. How about adding a soft-fork rule, that blocks must be 1 MB with block header hashing or more if the whole block is hashed? It doesn’t have to be the whole block, it can also be the hashes of the transactions inside the block, or anything proportional to the block size. That way, we have a robust proof-of-computers-are-now-fast-enough-to-have-this-block-size. For instance, in the future, computers (or ASICs) can be so fast that 10 MB blocks can be hashed at the same speed as headers are hashed today. Then the soft fork rule will allow 10 MB blocks. This needs more research.

Mike Hearn will probably tell you that this is a Rube-Goldberg contraption, but I believe that this is an elegant solution, and probably the simplest I can think of. It is more of a generalisation of Bitcoin rather than a change of Bitcoin, and only requires a soft-fork. It is like in physics, where you have the special theory of relativity, and then you zoom out and realize that it is actually a special case of the general theory of relativity.

And yes, I do have a strong academic background in the fields related to Bitcoin, so I am familiar with the mainstream arguments in these fields. I also have good practical experience with Bitcoin related projects. But it is possible that I made an error in my logic somewhere, so it would be good if some people could review this. In particular, I would appreciate it if I could hear comments from the following people: Gavin Andreson, Peter Todd, Adam Back, Pieter Wuille, Andrew Poelstra.


Edit Jun 19: As I mentioned in the mailing list, the other main idea is that addresses will be constrained to a path of subchains. An address can be represented as a number, and therefore you can perform modular division on it. (Let "%" mean "mod") The rule can be like this: For any address A, if A % 1 = 0, then A goes to the top chain C0 (so every address); if A % 11 = 0, to subchain C00, else if A % 10 = 0, to subchain C01, else if A % 9 = 0, to subchain C02, ...., else if A % 2 = 0, to subchain C09; if A % 111 = 0, to subchain C000, else if A % 100 = 0, to subchain C001, ..., etc.. Note Cij is a child of Ci, and Cijk is a child of Cij, and Cijkl is a child of Cijk, etc... And to make it so that and address A satsfies A mod m = 0, just multiply the address by m. This way you can ensure that your wallet follows only one path of chains that you track, and that you way you can keep track of the UTXO database related to your wallet (or the public wallet of your government representative) in a O(log n) way without using UTXO commitments, which I don't think is as good for decentralization purposes and shortness of proof.

Also, I take back the merge-mining scheme, I think it should be done without merge mining at all. Parent chains will instead collect fees from child chains to put the hashes of the child chains as special transactions in the parent chain blocks. These fees will be of the form of UTXOs that are only valid at the child chains (not the parent chains). That will give incentive for the parent chain to be careful with what child block headers it commits to (thus properly validate the child chains).

Edit Jun 24: Forgot to add that at most 2 sibling chains can be used in a transaction, so that the duplication of transactions is limited. You can always create a more complicated transaction by combining multiple transactions that include at most 2 chains.

Also, to limit "deep" forks, we should make a rule that once an output moves from a child chain to its parent (or grandparent) chain, any later discovery of a flaw in the output's value in the child chain cannot change its value, so this limits the effect that errors in the validation of deep child chains has on the parent chains.
10  Bitcoin / Project Development / Pirate Linux 2.0 alpha 3 - Fully Working Paper Wallet Creator on: June 29, 2014, 02:33:31 AM

I'm happy to announce the Pirate Linux is now a fully functioning Bitcoin paper wallet creator. Since my old posts (, Pirate Linux is no longer based on Ubuntu, but rather based on Hardened Gentoo. Paper wallet creation isn't the main purpose of the project, but this alpha release is designed especially to have a fully functioning paper wallet creator that you can boot up live and easily create a paper wallet for cold storage. I am not claiming that it is perfect, but I think this is currently the most secure paper wallet creator that exists. Unlike other paper wallet creators, it does not use Ubuntu, and it does not use a browser (coded in pure C). Also, there is an encryption feature that I think is superior to the overly-complex BIP-38 method. The passphrase (allowing the alphanumeric, space, and hypen characters) (base-64) gets converted to base-256, and this is used as a one-time-pad that gets added byte-wise to the secret part of the private key in base-256 representation, so the encryption is perfectly secure, with no loss of randomness.

Guide with screenshots and more information:

Some interesting parts from the guide:

As you can see, the first page contains the QR code of the encrypted private key (encrypted to your passphrase), the address written on top, and the encrypted private key written on the bottom. The second page contains the QR code of your passphrase together with the written version of your encrypted private key and the written version of your passphrase. The first page is meant to be stored in a safe location, such as in a physical safe at home (can be covered in plastic). The second page is more compact, and is meant to be cut out into the size of a business card, and kept in your pocket when you travel. For example, if you are moving to a different home, you will need to take the first page with you, but this can be scanned or searched at an airport, so it is safer to have it password protected, and in case you forget the password, you can have it in your pocket.

Cwallet will output each address and private key in Bitcoin’s base-58 format. It will also check to make sure that the private key correctly corresponds to the address by performing a multiplication in Elliptic Curve space. When converting between different bases, a reverse conversion is made to verify that the conversion went well. When inputting a private key, its hash portion is checked to make sure that it correctly corresponds to its content portion. Each conversion from a public key to an address is computed twice and both versions are compared for consistency; as is each conversion from a base-256 private key to Bitcoin’s base-58 private key. Pdflatex is used create the PDF file as it is a clean and well tested method of creating PDF documents. We use qrencode with the highest error correction level. A passphrase may be given to encrypt the private key with a one-time-pad derived from the passphrase. The program is written in C, the dependencies are minimal, with the core functions contained within less than 1000 lines of code. This makes it very easy to audit Cwallet for correctness and security.

Also, stay tuned for the next release of Pirate Linux (in a month), which will bring more advanced anonymity features as well as dark-wallet setup to go through Tor...
11  Bitcoin / Project Development / Pirate Linux - First Release on: January 21, 2012, 09:13:41 AM
This is a project I have been working on for the Pirate Party of Canada. You can see the feature list and download links at The video walk-through is at

Some features that are perhaps unique when compared to other distros:

- Ubuntu based together with a package called "piratepack" that installs all the modifications.
- Full disk encryption is preseeded for the installation of the OS.
- The piratepack has been tested to work on Ubuntu 10+ and Debian 6.
- Tor & Vidalia run in the background and you can access Vidalia from the icon on the top panel.
- Tor browser uses your current firefox under a profile called "tor".
- Both the Tor browser and the regular firefox get addons automatically installed (your firefox settings and history are still working as usual, it's just as if you installed the addons on top of them).
- Regular Firefox addons: AdBlock Plus, Bloody Vikings, Download Helper, Ghostery, HTTPS-Everywhere.
- Tor browser addons: Bloody Vikings, HTTPS-Everywhere, NoScript, Torbutton.
- Tor browser automatically launches Pidgin in OTR mode connected to the server through Tor.
- Bitcoin client (both command line and graphical).
- Cwallet: My own program that lets you list the private keys associated with your addresses in your wallet.dat and make a paper backup of your wallet in QR code format. Also, it checks to make sure that the keys are not corrupted. There's both a command line and graphical version.
- Custom Google Homepage: Google SSL search & Pirate search, plus useful links on top.
- Piratepack modifications can be enabled and disabled through a GUI controller.
- You can launch the Liberte & Tails privacy enhanced distros from the boot menu.
- IMPORTANT: Any binaries that piratepack installs are compiled from source automatically on installation. You don't have to trust my binaries. Of course the dependencies (such as libz1g or firefox, etc...) will not be compiled, but by default come from the standard Ubuntu/Debian repositories. Piratepack also produces a binary version of piratepack and puts it in /opt/piratepack/bin-pack. You can share this binary version with a friend or use it for yourself for installation on another machine. Of course you can also choose to install the binary version of piratepack if you don't want to wait for the compilation and you trust my signed binaries. Also, when doing updates to piratepack, you may want to read the source code first. In this case you can simply download piratepack from the website instead of using the update manager. Or you can install it from the update manager and then read the source code from the cache directory /var/cache/apt/archives in order to make sure that the code is not malicious.

The Pirate Party's stance on bitcoin is currently unclear, so I'm not promoting it with this distro. I'm just placing it there in case someone wants to use it. Also, note that the current ISO has Bitcoin 0.5.1. The current latest version is 0.5.2. Soon I'll update piratepack to install 0.5.2, so if you do the update from your update manager (or website), you'll get the latest version.

I'm taking a break from this now to focus on other things. But, Ill try to get some small updates done from time to time and I'm keeping an eye out for the release of Ubuntu 12, and that's when the next major update will probably happen.



- Fixed cwallet-gui to work properly (the 1.4-3 update caused an issue)

- Tor Browser: I fixed a Torbutton setting to prevent a leak of your IP through FTP. I know, it's a really stupid mistake.
- Bitcoin 0.5.2: This version fixes bugs, especially a Tor IP leak bug (this time it's not my fault).
- qrencode now compiles from source.

After installing Pirate Linux from the ISO, please go to Update Manager and install all updates (especially Ubuntu Security Updates and piratepack). You can of course install the latest piratepack by downloading the DEB from the website if you want to read the source code first.

Please note that I am not guaranteeing any form of security for my software. I'm trying my best to make it as secure as possible (I use it for myself, so I do care about it's security), but it still needs a lot more testing. Of course since it automatically compiles on your machine, anyone is free to assess the source code and it is easy for you to not have to trust me and run a transparent system.

You can test your browser anonymity on websites such as and
12  Bitcoin / Project Development / idea for mixing service on: December 31, 2011, 02:05:30 PM
So with mixing services, the problem is usually "How can I trust the server that does the mixing?"

But what about having a webcam livestream the server and also allow people to physically visit it to make sure that the stream is not corrupt?

The stream would be sent encrypted with PGP, so people physically visiting the server would have to verify that the server actually can sign messages with the correct key, and also make sure that no one else has gotten access to the private key. Also make sure the equipment there functions as it should...

The first time it goes live, it generates a new private key in front of anyone who wants to physically be there, and then those people can monitor the livestream to ensure that everything stays as it was. People who weren't physically there when the key was generated won't be sure that no one else has the key, but they can trust their friends (if they were there), or they can come the next time a new key is generated.

I thought of this kind of thing before when I was thinking of a way to make a trustworthy online voting system. It's still a rough idea, and it may be very hard to do for practical purposes, but can this be a way?
13  Bitcoin / Project Development / cwallet - Lightweight wallet reader to extract address & private key pairs on: December 28, 2011, 11:48:18 PM
Video demo:

<p xmlns:dct="" xmlns:vcard="">
  <a rel="license"
    <img src="" style="border-style: none;" alt="CC0" />
  <br />
  To the extent possible under law,
  <a rel="dct:publisher"
    <span property="dct:title">Andrew K</span></a>
  has waived all copyright and related or neighboring rights to
  <span property="dct:title">Cwallet</span>.
This work is published from:
<span property="vcard:Country" datatype="dct:ISO3166"
      content="CA" about="">

Version: 0.1


- libgtk2.0-dev
- libdb4.8-dev (May need to manually change this if your wallet is created with a different version)
- libssl-dev
- qrencode
- convert (ImageMagick)

To compile cwallet (command line version):

cd src
(set the INCLUDES and LIBS variables to be used in the makefile)
export LIBS
make -f makefile.static

To compile cwallet-gui (graphical version):


To run cwallet:

cd src

To run cwaller-gui:

(make sure both cwallet and cwallet-gui are compiled)
cd src

Options for command line version:

-w WALLET_FILE (defaults to ~/.bitcoin/wallet.dat)

-d WORKING_DIRECTORY (defaults to directory the program is called from)

-a ADDRESS (if not specified, all addresses are listed)

-q (produce pdf file of private key QR coded)

-o OUTPUT_FILE (file to save the pdf with QR encoding, defaults to WORKING_DIRECTORY/ADDRESS.pdf)


./cwallet -qa 1PkQCQmcyHR3gEPoBVLEchkVRYr5928Ko5


The program will output each address and private key in Bitcoin's base58 format. It will also check to make sure that the private key correctly corresponds to the address by performing a multiplication in Elliptic Curve space.

The program is written in C and has minimal dependencies. I did it mainly so that I can create a backup of my wallet in paper form. As a bonus it checks if my keys are corrupted. Also, I will soon include it in another project I'm working on (Pirate Linux). I cross checked with pywallet and it gives the same results. I did however notice that sometimes private keys are 31 bytes instead of 32. My program prints out "INVALID-KEY" if this is the case, but I can easily change that. Pywallet treats the 31 byte keys as if they were 32 bytes, but then the private key it produces isn't really a private key and there may be issues with importing those back into a wallet. Suggestions are welcome.
14  Other / Beginners & Help / History of all transactions necessary? on: November 27, 2011, 11:14:41 PM

I've been moderately using bitcoin since June, but haven't looked deeply into the technical details. Maybe someone can help me answer this question. It's my understanding that the history of all bitcoin transactions that ever took place is stored in the network. But is all this information necessary? Isn't it sufficient to store only the information that specifies who has how much at the current moment rather than how much they had at other points in history?

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!