Won't let me install it since I have a newer version. I am running Windows 8 Pro / Visual Studio 2012 Ultimate.

So that probably isn't the issue.

Build your own better client or at least a proof of concept and showcase it in the forums.

Based on your previous thread you mentioned the JSON requests were very slow. Yet your CPU/RAM were at low usage. So clearly they are not the bottleneck. Unless someone has a thread wait sitting in the code somewhere(Unlikely) you are probably looking at network lag.

I've only worked on communication between nodes thus far, haven't tackled the JSON-RPC in the client. As far as I am aware you aren't really forced to support that JSON specification they published, you could really have your own client specific endpoints/schemas. Assuming you decided to build your own client.

I'm not entirely sure you know what your talking about. Google translate sure as hell didn't

JSON Rubbish? Everything you said was rubbish.

Tried working on it myself for awhile but I am not too familiar with cmake. I fixed compile errors for awhile, mostly missing references. Now it says it can't find CURL....

As for your visual studio project, your build doesn't work for me. When I use CUDA I get an error "can't load module 301".

Any status updates on a compiled version for Windows?

The problems with the printed are...
1. Transactions can't be validated offline. Double spends would be possible.

The person receiving the coins should always be able to confirm the exchange. Meaning there is no connectionless approach they could take. If your talking just convenience for the consumer then sure they could walk around with the paper and just leave it up to the vendor to authorize.

As far as the consumer is concerned, what if you have 2 bills worth 0.25BTC but you are buying something worth 0.35BTC? The vendor would need to issue a credit and send the coins back to you. If the consumer is paying with offline bills they have no way to ensure that they received the credit.


2. They have fixed amounts.

As mentioned in the above situation you need to have the exact cost with you to carry around or vendors need to start offering credits.

3. It also puts you at higher risk to losing it. You don't physically need to steal the paper itself like cash, so a thief would only need to scan a barcode.

Nothing you can really do about this except be safe, and take same precautions you would with a regular wallet.



Basically there is no reliable way for 2 offline clients to make an exchange since the entire concept is based on authorizing against a public ledger. The next best solution is for a 3rd party to create certificates, sealed, and difficult to duplicate. Bitcoins would need to be escrowed by this 3rd party prior to releasing a certificate.

Honestly our lives would just be easier if we could go just with physical metal coins such as gold, silver, or likely an alloy of some kind with lower value... And use bitcoins for all transactions where connections are available. Small purchases could be made with physical coins or bitcoins, and large purchases should generally always require bitcoins. Unless you want to carry some silver bricks around when you want to buy a car.

I use this control suite for charting when I am looking for an HTML solution that takes json data.
http://demos.kendoui.com/dataviz/overview/index.html

If you have the expertise buy the license for the charting, and wire in the JSON data. It is cheaper to do it yourself if you can.

If you need help I can do it, however I only have a developer license at work. I can't build this for you from home without buying a license for myself. Ultimately it depends how much it is worth to you, and how much you are paying. If your offer was enough to buy a license then that would make it possible for me. The downside of course is that they do not sell their products in Bitcoin.

Before anything else though, check out their charting products and make sure they will work for you.

 

I am still undecided on WinRT. At first glance it seems to be very limited, but I think that could be a result of lack of documentation.

For instance I implement the SocketStream class to send/receive bytes over tcp. While first looking into it many forums said that 2 way communication was not possible, and it only allowed you to send bytes once connected. The recommended solution was to use websockets. Of course in actual implementation I was able to use the SocketStream to easily perform 2 way asynchronous communication. This wasn't the first incident of bad information out there, and the more I research it the more I realize many people have their facts wrong when giving information on WinRT. So for me the jury isn't out yet, I will know more as development progresses.

Microsoft is still to blame either way. They need more in depth tutorials for advanced programmers.

On the plus side, I am a huge fan of the Metro Style interface especially on Tablets/Phones. As for desktops I have mixed feelings about it.

I was actually discussing this with someone at work today. Still somewhat unclear how this was actually handled. Has the fork resolved itself? It appears that the initial recommendation was to revert to 0.7, but then later it was decided to push on to 0.8 instead.

Looks like there needs to be a slower and more controlled rollout process. I still don't know all the details, but it seems strange that two nodes would be allowed to talk to each other using different protocols.

Very nice, I will look through the project later I am sure it will be of value. Does it sync the entire block chain dataset? How does this affect data plans on the users phone?


Getting it into the Windows Store is likely going to be a bit more of challenge then a copy and paste. In WinRT when you navigate away from an app it suspends all processing. Only one App can be active at a time. That being said it appears there are methods to keep certain types of background processes going, so that will be the next learning curve. It's obvious Microsoft would prefer backgroung tasks be avoided as much as possible. However we can't expect a user to sit at the app screen for hours while it syncs the blockchains.

I also built my own network access layer code generator. In past projects I would build up my protocol specification within this app, and it would output the server code in .Net, and output the client code for both .Net/Silverlight. All send functions and receive handlers become exposed through an interface. The benefit with this approach is all serializion/deserialization takes place in a consistent manner and as far as the consuming developer is concerned they are just strongly typed classes with no knowledge of the networking. I went this route because I am accustomed to WCF development and I wanted to simplify my own development. Of course Bitcoin slightly breaks my model since messages are wrapped differently, combined with the learning curve of adopting WinRT. So there are some roadblocks for sure since my code generator does not support WinRT.

More than anything else I actually want to have a better understanding of how it works, and I get to learn WinRT at the same time. The hands on approach has helped me in the past. There is a good possibility your libraries will remain superior to mine, but my objective isn't necessarily to compete with anything. After all I intend to release it for free.


If you wouldn't mind, could you elaborate on some the more difficult/tricky problems you encountered? I'm still interested to see if you can talk me out of it

Interesting... I knew RAR could split a file into parts, but I didn't realize there was a similar recovery feature. It seems like an obvious feature I suppose, but then again I've never had the need for it until now.

In regards to passwords, cracking is becoming easier each day. It is true that the weakest point in any encrypted file is not the encryption itself, but the password used. As time goes on the length of passwords will need to perpetually increase. I guess that is where certificates come in. But then if you lose your private key you are equally compromised.


Anyway the point I am trying to make is that perhaps we should have the part file functionality built into the wallets. While other technologies are effective we need something the majority of people can use and understand. As times goes on we should expect people to become more ITsavvy. However for mass adoption of Bitcoin to continue, it must be relatively secure for the average person without having to jump through hoops.

Right now it is widely seen as a currency for hackers. For this to change... my 85 year old grandmother should be able to use it without being robbed blind. Of course this idea doesn't solve that, but I think it is a step in the right direction. 

Hi Everyone,

I am building a Windows 8(WinRT) bitcoin wallet, I will use this thread to provide status updates or to assist others with their own implementations.

Before I get too far along in my development I will outline my current approach so that forum members can offer some criticisms if I seem to be going in a wrong direction.

The solution contains the following projects

1. BitcoinSchemas

This is a .Net Portable Class library, meaning it can be added and compiled against many frameworks such as Silverlight, .Net, and WinRT. It contains a set of serializable classes so that in future I may serialize them into XML/JSON should I choose. However currently I am only working with sockets so these classes end up being processed by my own packet readers/writers.  

This project contains no logic, only types.

2. BitcoinPortable

This is again a Portable Class Library. It contain logic pertaining to Bitcoin that does not require any framework specific namespaces. So in future I may create a .Net or Windows Phone client without duplicating logic.

3. Helpers

Generic helpers not specific to bitcoin such as converting Windows DateTime to Unix Time.

4. BitcoinWinRTNode

This is a Windows Store Class library and contains all functions required for communications with other nodes. I am trying to make sure it is abstracted as much as possible so that any developers new to bitcoin can quickly jump in and follow the logic. I should be able to support new command types in the future without modifying any of the low level networking. Also includes lots of comments.

Majority of logic in here is wrapped in asynchronous/non blocking code. It should never cause a deadlock within referencing UIs.

5. BitcoinWinRTWallet

This is a Windows Store App that I am building, it references the WinRTNode library for communicating with the rest of the bitcoin network. I use the MVVM design pattern by using asynchronous relay commands, and binding UI elements to viewmodel properties.



Current Status

All of these libraries have been created and in the beginning stages of development. I've got my networking API finished and seemingly bug free. In my implementation I have all message commands wired up to event handlers, however most of them aren't performing any business logic yet. Most are just skeleton handlers at the moment that receive the payloads.

These empty handlers basically look like this:

Essentially everything runs asynchronously, I am currently not manually creating threads anywhere. I leave it to the runtimes task scheduler. In terms of the UI I've got a few screens built, I've also created my own brand identity(ProductName/Logo/Color Palette). Although the brand details could still change at some point. I don't plan on releasing too many details right now, unless of course someone else in the forums requires assistance with their own app. I will post code snippets as needed until I am ready to go open source.



Now I do have some dumb questions.

1. If all of the nodes connect via sockets, then what purpose does the RPC-JSON serve?
2. I've built JSON Web Services many times, but how would this differ from the RPC-JSON approach? As far as I would be concerned calling a web service method is a remote procedure call. However I've read some contradicting information in the forums.
3. I'd like to release all my code to be open source at some point. However I do not want to restrict myself or anyone else from using these libraries for commercial purposes should they choose. I don't work in open source projects often. What is the best licensing model I should use for this?
 
I would be willing to build a WCF web module for the JSON component should anyone request it.

Thanks

Also,

Vee may I ask what your proficiencies are?

My primary skills would be C#/VB.Net, WCF(JSON/SOAP), Asp.Net. Oracle, MSSQL, HTML5, Silverlight, WinRT, Web Service Architecture. Secondary skills would be C++, C, and other things that I haven't touched since college. Additionally I also have a strong IT background as it related to database administration, network administration, Active Directory, backups, firewalls, etc... Currently most of my day to day work is architecting software for Banks and Insurance Companies.

To be honest I am not entirely sure Microsoft will accept the application into the Windows Store. Given that Apple has removed their first and only bitcoin client from the Apple App Store.

I am building a wallet for Windows 8 / Windows Store. The networking API will be open source, as for the wallet app itself I have not decided yet. I assume for it to gain any level of credibility in Bitcoin network I will likely need to make all components open source. It is guaranteed to be a free Windows Store Application.

Porting it to the Windows 8 phone shouldn't be a challenge, the code will all build except for the XAML. The interface will need to be redesigned for a smaller screen. And although it will build I don't imagine a phone user is going to want a 6gb blockchain download over their data plan. So at this point I would need to leverage the community for ideas to get around this.

Currently I am using raw sockets to communicate between nodes. Following the specification seems to be relatively straight forward. Although I see some references to JSON-RPC throughout the forums and it has added a little bit of confusion for me. I am not sure if this is just some kind of wrapper to simplify client development or if it is part of official spec and should be supported. Personally I'd rather stick with sockets.

Did a quick search in the forums, didn't see this idea yet. Although I did see alot of other great ideas.

Objective
To provide a reliable long term solution for storing a wallets. The solution should mitigate risk of theft, while also providing redundancy in case of data loss.

This is not to be a replacement for wallets themselves. It is intended for long term storage only.

Problems with existing backup solutions
1. If a cracker obtains your backup there is a possibility of it being decrypted and stolen
2. If you lose your backup you lose your coins
3. Each backup copy you make to prevent data loss increases your risk of being stolen

Proposed solution

This is a fairly standard concept, and the most similar technology that comes to mind is RAID. Essentially we create 3 files which represent the backup of the wallet. In order to rebuild the wallet you need a minimum of 2 parts, at that point you still need to know the key for decrypting. Should an attacker obtain one of your files he will not have enough data to build a complete file. Also, should one of your storage devices fail you will presumably still have 2 parts to rebuild the wallet.

How it works
1. First we begin by encrypting the wallet
2. Split up the encrypted bytes into 3 Parts
3. Organize them into 3 unique pairs, for example
File 1: Part1 + Part2
File 2: Part1 + Part3
File 3: Part2 + Part3
4. Distribute the 3 files among different secured storage mediums. USB Key, hard Drive, FTP, etc...


Additional Thoughts
1. Technically we aren't limited to 3 parts. This could be theoretically any number.
2. This concept could be applied to eWallets as well. Rather than having a single wallet provider users may store wallet parts with multiple providers. In order for an attacker to steal funds they would need to hack N number of providers, somehow correspond wallet parts with eachother, and then of course know the encryption method/key for the wallet itself.


Anyway, if you like this idea perhaps we can start getting a working standard together. I am building my own wallet and I want to use as many best practices as possible, and create practices where they are lacking. If this idea already exists I apologize for the duplicate thread.

We also need to keep in mind that Bitcoin exchanges occur at an international level. So the USA makes it a black market currency, then they need every other country on board. Probably starting with Canada and the UK.

If a single country anywhere decided to adopt Bitcoin as their nations currency that means the USA would need to sanction that country to prevent legal trades from occuring. A sanction is an act of war and currently I can only think of 3 countries who they could do that to... Cuba, Iran and North Korea. In short that basically means Bitcoin needs some countries to sponsor it.

The USA can try all it wants to regulate purchases internally if it goes that far, but they can't shutdown international trade without collapsing themselves.

Of course there is alot of wishful thinking in the OP, as I said this is hypothetical only.


Here is something to consider though. The majority of Bitcoin transactions are currently to exchange illegal goods/services, most of which are totally untraceable because the websites are only available through the TOR network. A significant number of Bitcoin purchases are done through cash in person, and is actually still a very strong network.

The services which you are concerned the government may attack could only scratch the surface and likely remove the only investors who aren't participating in organized crime(Minus Counterfitting of course, lol). Drug dealers continue business as usual, but now you can't buy DVDs online with Bitcoins. I hope that isn't what qualifies as a win for the US government.

Everytime the government tries to suppress freedom it backfires. Decentralized websites already exist and perhaps that will be the future. They remain forever out of reach from authorities.

The final play the government could make would be shutting down the internet. How likely is that to happen?

Everytime the government places restrictions on us we work around it through innovation. The latest example being Bitcoin...

The government will intervene, however the government can only fight back as long as they have purchasing power. Even as we speak Bitcoin as slowly eating away at their power, and every dollar the Federal Reserve prints only sets them back further.

The Government isn't the threat though, it is the Banks. They are the trillionaires of the world and stand to lose most. The ones who choose to fight back against Bitcoin will be a great threat to us and you are right, however people are greedy so there will be the ones who try to invest in Bitcoin to hedge their losses. These investors have been and will be the ones that make Bitcoin successful.

The ones who are late to the party can spend all their trillions on Bitcoin and still only end up as middle class.

This is a war on the currency monopoly maintained by central banks. We've fought for freedoms in the past, and we need to do it again.

I have been building my own Bitcoin networking API for .Net/WinRT. I have found these forums to be incredibly useful in figuring out how the protocol works, and I have also been using wireshark to ensure my messages are being formatted properly. I would like to be able to participate further in the developer forums, as I am sure I will have questions and I can likely help solve problems as well. I am familiar with sockets, threading and asynchronous programming.

As further proof I am familiar Bitcoin and how it works. I currency manage multiple wallets, experimented with the stock exchange, and I've used the OpenCL miner.

I've met my post requirement and reached the 4 hour minimum. Unfortunately I have no friends here that can refer me.

Please promote me to Jr Member.

Thanks

Anyone here a Libertarian in Canada? In the interest of remaining anonymous you don't need to answer that...

I just thought it was worth mentioning that they are now accepting donations in bitcoin. I noticed it on their site the other day.

I wonder if it is even legal for them to do that, they must face enormous amounts of scrutiny from elections Canada. More so than the average Canadian would face on their yearly taxes anyway... Regardless though there donations page it up, so I encourage fellow Libertarians to consider a BTC donation.