Hello all,

I just received the bitsafe device from alten. Fast shipping, device is working as expected. I got the basic test working with this firmware from alten https://www.dropbox.com/s/an5ej306snzbk51/bitsafe_tester.X.production.hex

With the first compilation I did (under ubuntu linux), the hex file failed to load properly with the PIC32 bootloader. I got the error message : "Verification failed". Alten then suggested I add a linker script called "app_32MX695F512H.ld" (it can be found in the bootloader source downloadable from Microchip). This linker
script will help the compiler to use the correct memory regions of the PIC32; otherwise, it will compile it to run in the same location where the bootloader resides in memory.

So I got my own bitsafe_tester firmware to work after that. Still trying to get the real firmware going.

I do not have a windows machine readily available, does anyone know of a good linux bootloader application?

Thanks!

rhkBt4tgr1Lt4qjghn1NXpWTcABUTQc6Cv

Bitcoin will become a settlement network, where as ripple will become a clearing mechanism. Both are complements of each other. But since ripple deals with fiat, I am afraid governments will attempt to control ripple before they attempt control on bitcoin.

In a few years, your grand kids will be asking you; Grampa, is it true that you had a whole bitcoin to yourself when you where young?

Hello brave new bitcoin world.

Hello

Full always-on wireless Internet connectivity cannot be taken for granted everywhere in the world. Even in advanced countries you have internet outages, hardware breaks, inteference, lack of coverage, power outages.. Having a POS that can validate a transaction in a semi offline mode is very usefull. In real life, when power or the VISA card reader is broken, sellers can still make a carbon copy of your card to bill the transaction later. The bitcoin POS could indicate when it has been too long since the last block was received. The seller can then take action to sync with the network, or at least he knows there is a security issue.

I was hoping to validate transactions with only the block headers to reduce the CPU processing. The processing power of smartphones seems to be a bit low to handle full blocks, but I need to run some tests.

What I gather from this discussion;
- RPC-JSON is nice but is a complicated setup that requires a PC running somewhere in the seller's shop, plus a reliable connection between the POS and the PC. Maybe modifying the RPC-JSON client to allow forwarding a transaction would be enough for my use case.
- I will read about the balance sheet proposal


Thank you for all your inputs,

Philippe

Thank you for all your answers,

Let me give you the scenario I am trying to implement.
- The use case does not require the light client to know the balance of its own account
- The light bitcoin client receives a transaction message from the p2p network or any other insecure source
- Without waiting for the transaction to be accepted by the network (by way of block creation) the light client wants to verify that the input transaction actually has money in it.

I understand that this introduces a security risk for the light client, but it is a tradeoff for usability that the user can live with since it is going to be used only for transactions with a physical presence.
Thus, I am trying check the following:
   1) Have the coins from the input transaction have already been accepted by the network
   2) The coins from the input transaction have never been redeemed (double spent) in another transaction

Any ideas are welcomed,

Philippe

Hello All,

I am working on the bitcoinj client and I am trying to implement the block header download in light mode.

From the protocol specification Wiki (https://en.bitcoin.it/wiki/Protocol_specification#Block_Headers) , it seems that only the merkle root hash is stored in the Block Header. Having the merkle root hash is not sufficient to validate a transaction contained in that block. I would need the full Merkle tree and not only the root hash.

IMO the full merkle tree should be sent with the block header, not just the merkle root. For the full blocks, we do not need to send any node of the merkle tree since the tree is computed from the transactions that we have. Maybe the protocol should have an additional command to download the merkle tree given a merkle root? I find that to be inefficient and I would prefer to have the merkle nodes inside the block header...

Did I miss something?

Philippe