Topic: Sigsafe: A NFC key tag for signing bitcoin transactions - page 3. (Read 23252 times)
Very interesting. The NFC standard seems to be available for most android phones. What about iphones and laptops?
I like that second option the best with required phone authentication.
Cool invention and way to make it available for cheap. Hardware and software that helps the broad public easily use bitcoin is a contribution to the growth of bitcoin for all. And of course you will make money doing it too
Cool invention and way to make it available for cheap. Hardware and software that helps the broad public easily use bitcoin is a contribution to the growth of bitcoin for all. And of course you will make money doing it too
Couldn't they just spend your coins whereever and on whatever they wanted? (if they had the sigsafe physically in their posession)
It depends on the signing rules used.
If your sigsafe is completely unlocked, then the security model is similar to cash--if someone finds your tag on the sidewalk they can probably spend your coins.
But if you set a password, require authentication from your phone, lock the spend address, or enforce daily spending limits, then it would be very difficult for someone to spend your coins even with physical possession of the tag.
In both cases, you've also significantly limited threats from malware and hackers.
But lets say I have this nfc Key your making in another place , meaning I take my phone make the transaction somehow and it asks me to tap the key to complete the transaction meaning no key password was typed , screen captured or anything. I wonder if this is possible, and what does the NFC data send? Any privkey data in an un-encrypted message that can be compromised with a trojan and then saved for retrieval? If not then this would be a seamless way to make transaction without worrying about Private key being kidnapped at the point of scanning or clipboarding whilst online.
The private keys never leave the Sigsafe's microcontroller. It is not possible for a trojan, key logger, NFC packet sniffer, or rogue camera to determine your private key when using the tag for signing.
In your case, your phone would pass an unsigned TX to the NFC tag, the tag would sign it (if authorized), and then relay the signed TX back to your phone for broadcasting. For increased security, you could add a password for the Sigsafe tag, limit the value of each transaction to 1 BTC "per tap," configure the tag to only sign TXs that spend coins to a pre-defined hot wallet, or authenticate your phone prior to signing.
Even if someone stole your tag, it would still be very difficult for them to steal your coins.
Couldn't they just spend your coins whereever and on whatever they wanted? (if they had the sigsafe physically in their posession)
But lets say I have this nfc Key your making in another place , meaning I take my phone make the transaction somehow and it asks me to tap the key to complete the transaction meaning no key password was typed , screen captured or anything. I wonder if this is possible, and what does the NFC data send? Any privkey data in an un-encrypted message that can be compromised with a trojan and then saved for retrieval? If not then this would be a seamless way to make transaction without worrying about Private key being kidnapped at the point of scanning or clipboarding whilst online.
The private keys never leave the Sigsafe's microcontroller. It is not possible for a trojan, key logger, NFC packet sniffer, or rogue camera to determine your private key when using the tag for signing.
In your case, your phone would pass an unsigned TX to the NFC tag, the tag would sign it (if authorized), and then relay the signed TX back to your phone for broadcasting. For increased security, you could add a password for the Sigsafe tag, limit the value of each transaction to 1 BTC "per tap," configure the tag to only sign TXs that spend coins to a pre-defined hot wallet, or authenticate your phone prior to signing.
Even if someone stole your tag, it would still be very difficult for them to steal your coins.
Great WRK!!!
I am wondering if it will work in the way I am thinking.. I wanted something that will make sending my funds from my coldwallet to a spend wallet but Without making the private key vulnerable to screenshot/key logger trojans.
Eg; I have a dedicated phone (No Sim, 99.9% in Airplane mode,only on home wifi when I want to broadcast transaction) In my Locked SAFE, I take out the phone and take a metal key next to it to open another safe in another location which has my encrypted private key....When I want to send money from my cold storage I scan my bip38 QR priv key and then enter my password sentence, now my read only wallet is now a send/receive wallet....
If somehow someone broke into my house without me noticing afterwards and then into my safe and planted a sophisticated trojan in my phone that scans captured qr codes and anything typed, its now compromised the next time I scan, i know "highly unlikely" lol .
But lets say I have this nfc Key your making in another place , meaning I take my phone make the transaction somehow and it asks me to tap the key to complete the transaction meaning no key password was typed , screen captured or anything. I wonder if this is possible, and what does the NFC data send? Any privkey data in an un-encrypted message that can be compromised with a trojan and then saved for retrieval? If not then this would be a seamless way to make transaction without worrying about Private key being kidnapped at the point of scanning or clipboarding whilst online.
Hope you understand what I am trying to say its very late and I am getting lazy, my explanation may be a bit vague and I'm a little lazy to explain in too much detail.
I am wondering if it will work in the way I am thinking.. I wanted something that will make sending my funds from my coldwallet to a spend wallet but Without making the private key vulnerable to screenshot/key logger trojans.
Eg; I have a dedicated phone (No Sim, 99.9% in Airplane mode,only on home wifi when I want to broadcast transaction) In my Locked SAFE, I take out the phone and take a metal key next to it to open another safe in another location which has my encrypted private key....When I want to send money from my cold storage I scan my bip38 QR priv key and then enter my password sentence, now my read only wallet is now a send/receive wallet....
If somehow someone broke into my house without me noticing afterwards and then into my safe and planted a sophisticated trojan in my phone that scans captured qr codes and anything typed, its now compromised the next time I scan, i know "highly unlikely" lol .
But lets say I have this nfc Key your making in another place , meaning I take my phone make the transaction somehow and it asks me to tap the key to complete the transaction meaning no key password was typed , screen captured or anything. I wonder if this is possible, and what does the NFC data send? Any privkey data in an un-encrypted message that can be compromised with a trojan and then saved for retrieval? If not then this would be a seamless way to make transaction without worrying about Private key being kidnapped at the point of scanning or clipboarding whilst online.
Hope you understand what I am trying to say its very late and I am getting lazy, my explanation may be a bit vague and I'm a little lazy to explain in too much detail.
(cont'd) Example command-line control of a Sigsafe device
This is a continuation of this post. Please refer here for background info.
Sigsafe as a cold wallet
Another application of sigsafe is as a cold wallet that can securely transfer funds to a hot wallet on a NFC-enabled phone (or computer). The user would request a transfer from a "watch-only address" and the phone would create the corresponding unsigned TX. When the user brings his sigsafe tag within NFC range of the phone, the phone makes a signature request from the tag. If the tag is authorized to sign the transaction, it does so and relays it back to the phone over NFC. The phone pushes the TX to the bitcoin network to complete the transaction. The user can configure the tag to require a password, lock the spend address to a pre-defined hot wallet, or require cryptographic authentication of the phone.
Once again, I am using Vitalik Buterin's "pybtctool" to act as the phone's hot wallet software (it looks up unspent outputs and creates unsigned transactions), and I have a simple utility that I've called "sigsafe" that echoes commands to my prototype sigsafe's microcontroller.
Let's add a new key to our sigsafe tag to act as an offline cold wallet:
The tag responds with the bitcoin address that corresponds to the key that was just loaded: 1co1dp6vy9h4bFLd6PMUYciEmYjgptHMQ
Now let's imagine that the user wants to lock this key so that it will only sign transactions that spend to a predefined hot wallet (which we'll assume is 1HotUGu9XBiKrPUZCv8Aiw4nwXLr15Udsf). To lock, the Android wallet would issue the lock_spendAddr command, and then the store_key command to burn the private key and the signing rules to EEPROM:
Let's check if our cold wallet has any unspent outputs:
Yup, we have 1100 bits. Like in our last example, the Android phone must load the parent TX onto the sigsafe so that it can determine the size of the mining fee:
Next let's try to spend this to the bitcoinEater address. The hot wallet creates an unsigned transaction that spends the coins:
The hot wallet passes this unsigned TX to the sigsafe for signing:
And we see that the Sigsafe refused to sign it, as it should because it's configured to only sign transactions to the hot address.
Let's try again with the real hot wallet address:
There was no error and the merchant can now push this transaction to the network:
Here's the verbatim bash shell inputs and outputs:
And here's the transaction picked-up at blockchain.info:
The user could have also set a password or required the phone to answer a "challenge question" independently for each key or keychain.
This is a continuation of this post. Please refer here for background info.
Sigsafe as a cold wallet
Another application of sigsafe is as a cold wallet that can securely transfer funds to a hot wallet on a NFC-enabled phone (or computer). The user would request a transfer from a "watch-only address" and the phone would create the corresponding unsigned TX. When the user brings his sigsafe tag within NFC range of the phone, the phone makes a signature request from the tag. If the tag is authorized to sign the transaction, it does so and relays it back to the phone over NFC. The phone pushes the TX to the bitcoin network to complete the transaction. The user can configure the tag to require a password, lock the spend address to a pre-defined hot wallet, or require cryptographic authentication of the phone.
Once again, I am using Vitalik Buterin's "pybtctool" to act as the phone's hot wallet software (it looks up unspent outputs and creates unsigned transactions), and I have a simple utility that I've called "sigsafe" that echoes commands to my prototype sigsafe's microcontroller.
Let's add a new key to our sigsafe tag to act as an offline cold wallet:
Code:
$ sigsafe new_key 86b7fe571bcf0f5cdccbd615a0b9f******************************30c6f92a 01
1co1dp6vy9h4bFLd6PMUYciEmYjgptHMQ
The tag responds with the bitcoin address that corresponds to the key that was just loaded: 1co1dp6vy9h4bFLd6PMUYciEmYjgptHMQ
Now let's imagine that the user wants to lock this key so that it will only sign transactions that spend to a predefined hot wallet (which we'll assume is 1HotUGu9XBiKrPUZCv8Aiw4nwXLr15Udsf). To lock, the Android wallet would issue the lock_spendAddr command, and then the store_key command to burn the private key and the signing rules to EEPROM:
Code:
$ sigsafe lock_spendAddr '"1HotUGu9XBiKrPUZCv8Aiw4nwXLr15Udsf"'
OK
$ sigsafe store_key
01
Let's check if our cold wallet has any unspent outputs:
Code:
$ pybtctool unspent 1co1dp6vy9h4bFLd6PMUYciEmYjgptHMQ
[{"output": "edd6e9f829778273b53506cbadc94835826f6a347d13309abce99b057048efd8:0", "value": 110000}]
Yup, we have 1100 bits. Like in our last example, the Android phone must load the parent TX onto the sigsafe so that it can determine the size of the mining fee:
Code:
$ pybtctool fetchtx edd6e9f829778273b53506cbadc94835826f6a347d13309abce99b057048efd8 | sigsafe load_utxo -s
D8EF4870059BE9BC9A30137D346A6F823548C9ADCB0635B573827729F8E9D6ED
Next let's try to spend this to the bitcoinEater address. The hot wallet creates an unsigned transaction that spends the coins:
Code:
$ tx=`pybtctool mktx edd6e9f829778273b53506cbadc94835826f6a347d13309abce99b057048efd8:0 1BitcoinEaterAddressDontSendf59kuE:100000`
The hot wallet passes this unsigned TX to the sigsafe for signing:
Code:
$ sigsafe sign $tx
Denied: spend address
And we see that the Sigsafe refused to sign it, as it should because it's configured to only sign transactions to the hot address.
Let's try again with the real hot wallet address:
Code:
$ tx=`pybtctool mktx edd6e9f829778273b53506cbadc94835826f6a347d13309abce99b057048efd8:0 1HotUGu9XBiKrPUZCv8Aiw4nwXLr15Udsf:100000`
$ stx=`sigsafe sign $tx`
$ echo $stx
0100000001D8EF4870059BE9BC9A30137D346A6F823548C9ADCB0635B573827729F8E9D6ED000000008B48304502204D143E395BE9DC3F3BBAD00EB7AE416CCD874087AB746A61B2945DC1140818360221009252FB05AEA74475B0926F1D48F95F87B2D25516964C9D8656063C74D8F8A7BB0141040B2778949907435B2CCC13E0F8806764ECEA2DA111EF849295445D693D5916EF61C646CDAC31F85C65E896D4E360DCECB69E6CF50C959100FEF869B07A9042F1FFFFFFFF01A0860100000000001976A914B8601CAA9C16B3345E7F3A963EC95356D3C5C14888AC00000000
There was no error and the merchant can now push this transaction to the network:
Code:
$ pybtctool pushtx $stx
Transaction Submitted
Here's the verbatim bash shell inputs and outputs:
And here's the transaction picked-up at blockchain.info:
The user could have also set a password or required the phone to answer a "challenge question" independently for each key or keychain.
Any idea when this will come out and what the price range will be?
I'm hoping to be in a closed-alpha phase in September (some initial devices distributed to partner wallet developers), and be selling to the bitcoin community in early 2015 in an open-beta phase.
I really want to get the cost of these devices down as much as possible, but of course for that you need volume. Realistically, I think these would need to initially sell for about $35-$50 in low production quantities, hopefully dropping closer to $20-$25 if we could produce a few thousand at a time. In very large quantities, similar devices could be made very inexpensively.
I would almost definitely buy one for $35. At $50 it depends on how my finances are but, especially if the come in pairs, I'd probably still buy one.
Of course, it would be cool to get in on the closed beta despite my lack of credentials
. You do want some consumer perspective right? Any idea when this will come out and what the price range will be?
I'm hoping to be in a closed-alpha phase in September (some initial devices distributed to partner wallet developers), and be selling to the bitcoin community in early 2015 in an open-beta phase.
I really want to get the cost of these devices down as much as possible, but of course for that you need volume. Realistically, I think these would need to initially sell for about $35-$50 in low production quantities, hopefully dropping closer to $20-$25 if we could produce a few thousand at a time. In very large quantities, similar devices could be made very inexpensively.
This is interesting innovation, I wish you the best of luck!
Any idea when this will come out and what the price range will be?
You are probably looking for http://bitcointrezor.com/ then. :-)
I'm happy to see that you've noticed this thread. I appreciate the great work Slush and you've done for bitcoin hardware wallets, and the Trezor Crypto library has been a useful resource to me while developing Sigsafe.
I would love to see something like this, only with two additions:
1) A small LCD display
2) A hardware button
1) A small LCD display
2) A hardware button
Sigsafe is designed to be an absolutely minimal bitcoin signing tag (hardware wallet). Like Stick pointed out, you are probably looking for something more like Trezor.
Quote
The reason being (and correct me if I'm wrong here), with the current model you have to trust the POS terminal to request payment for the same amount that its display shows. What if a POS terminal is hacked / modified to request larger payments than the display shows? Or what if malicious persons set up secret hotspot terminals to steal bitcoin from accidental proximity?
The immediate use for something like Sigsafe is a sort of "paper wallet that can sign transactions" to your hot wallet. I find my prototype very useful because I can sign coins from cold storage to my hot wallet without needing to load the private key onto a computer and without needing to keep an "offline computer" around. The coins can be moved with a simple gesture. Soon I hope to use Sigsafe as one of the signers in a m-of-n multisig wallet.
The signing rules for Sigsafe make this type of use very secure. For example, the device can be configured to only sign transactions that move coins to a hot wallet, require a password from the user, or require cryptographic authentication from the interface device.
In the future, should bitcoin payments over NFC become widespread, you would only want to use a tap-and-pay tag like Sigsafe with a merchant/payment terminal that you reasonably trusted for the reasons you mentioned (although daily and per TX spending limits will likely be implemented be default with Sigsafe). But also remember: if a merchant wants to scam you, they can also just take your payment and then pretend that they never received it or that you sent it to the wrong address--a screen doesn't prevent this attack.
Every design must make trade-offs. Sigsafe doesn't have a screen or buttons, but because of that it gains simplicity (just tap and the device will sign if authorized) and minimizes cost (in high quantity these devices could be very inexpensive). This will be a benefit for some applications and to some users, and a hindrance to others.
Quote
What I'd like to see is a two-pass system: one wave "receives" transaction data from the terminal, and displays the requested payment amount on the LCD screen suggested in point 1. If you'd like to confirm the payment, you simply press the button mentioned in point 2 and a second wave will "send".
Work is underway on an open NFC protocol to do exactly this. And you won't actually need special bitcoin hardware: you could use an Android phone with NFC. The interface device makes a payment request over NFC, the wallets signs it if authorized, relays the signed transaction back to the interface device which then pushes it to the bitcoin network. Whether the user authorizes the payment manually be pressing "send," or whether the wallet itself auto-authorizes payments using trust lists, certificates and signing rules, is a decision that would be application and user dependent. But we want this protocol to be flexible and open so that anyone can design compatible hardware to act as either the interface device that makes requests, or the wallet that receives and responds to requests (or both).
1) A small LCD display
2) A hardware button
2) A hardware button
You are probably looking for http://bitcointrezor.com/ then. :-)
IT looks interesting,
depending on the price of course but it is really nice that everyday we have new options for bitcoin payments
depending on the price of course but it is really nice that everyday we have new options for bitcoin payments
I would love to see something like this, only with two additions:
1) A small LCD display
2) A hardware button
The reason being (and correct me if I'm wrong here), with the current model you have to trust the POS terminal to request payment for the same amount that its display shows. What if a POS terminal is hacked / modified to request larger payments than the display shows? Or what if malicious persons set up secret hotspot terminals to steal bitcoin from accidental proximity?
What I'd like to see is a two-pass system: one wave "receives" transaction data from the terminal, and displays the requested payment amount on the LCD screen suggested in point 1. If you'd like to confirm the payment, you simply press the button mentioned in point 2 and a second wave will "send".
1) A small LCD display
2) A hardware button
The reason being (and correct me if I'm wrong here), with the current model you have to trust the POS terminal to request payment for the same amount that its display shows. What if a POS terminal is hacked / modified to request larger payments than the display shows? Or what if malicious persons set up secret hotspot terminals to steal bitcoin from accidental proximity?
What I'd like to see is a two-pass system: one wave "receives" transaction data from the terminal, and displays the requested payment amount on the LCD screen suggested in point 1. If you'd like to confirm the payment, you simply press the button mentioned in point 2 and a second wave will "send".
Great progress looks awesome.
looking nice 
I'll try to have a real look on the APDU specification this time
I'll try to have a real look on the APDU specification this time
Example command-line control of a Sigsafe device
Sigsafe as a tap-and-pay tag
One application of sigsafe is a tap-and-pay tag (similar to Visa PayWave) for low-value transactions from trusted merchants. Although the user simply "taps and pays," a bunch of low-level communication takes place between the merchant's PoS terminal and the sigsafe. The PoS terminal must first read a spend address from the tag, look for unspent outputs, create a TX, pass it to the sigsafe for signing, receive the signed TX, and then push the TX to the network. In this post, I cover the very basics of completing such a transaction. This post doesn't cover any of the security features such as Diffie-Hellman exchanges for secure password transmission or cryptographic authentication of interface devices.
I am using Vitalik Buterin's "pybtctool" to act as the PoS terminal's software (it looks up unspent outputs and creates unsigned transactions), and I have a simple utility that I've called "sigsafe" that echoes commands to my prototype sigsafe's microcontroller.
The user brings his tag up to the terminal, and, when the terminal senses the presence of the tag, it issues a "stickerAddr" command to get the tag's default spend address (this will be a BIP32 keychain in the future):
The tag responds with its default spend address: 1sTKRtNPbtiLLB79gfvbuz9zKTkdGPsNp
Now let's imagine that the merchant's terminal wants to charge this tag 500 bits for a donation to P2Pool. The first thing the merchant's terminal needs to do is look up the unspent outputs for this address:
We see that there is one unspent output available with a balance of 600 bits. Next, the merchant's terminal constructs an unsigned transaction that spends 500 bits from this output to P2Pool, and uses the remaining 100 bits for a transaction fee.
The transaction looks like this:
Before the sigsafe will sign this transaction, it needs a bit more information. The merchant's terminal passes it the complete parent TX for the output being spent in order for the sigsafe to know the value of all the inputs. The -s option allows me to pass the sigsafe the stdout from pybtctool:
The sigsafe responds with the transaction hash (in little endian).
Next, the merchant's terminal makes a signing request to the sigsafe:
The sigsafe's response was:
There was no error and the merchant can now push this transaction to the network:
Here's the verbatim bash shell inputs and outputs:
And here's the transaction picked-up at blockchain.info:
Later this week I'll show how the sigsafe can act as a cold wallet, programmed with signing rules to only sign transactions that spend coins to a pre-defined hot wallet.
If anyone goes through this example with a fine-toothed comb, they'll notice that I've used uncompressed pubkeys rather than compressed. The sigsafe defaults to compressed pubkeys to save room in the blockchain, but this post is part of a bunch of work I just did (and will post later) that uses some vanity addresses (1co1d, 1hot, etc) and I couldn't find an easy way to generate a vanity address that used a compressed pubkey! I got sigsafe to start working on it, but I think it will take about a year to find anything
Sigsafe as a tap-and-pay tag
One application of sigsafe is a tap-and-pay tag (similar to Visa PayWave) for low-value transactions from trusted merchants. Although the user simply "taps and pays," a bunch of low-level communication takes place between the merchant's PoS terminal and the sigsafe. The PoS terminal must first read a spend address from the tag, look for unspent outputs, create a TX, pass it to the sigsafe for signing, receive the signed TX, and then push the TX to the network. In this post, I cover the very basics of completing such a transaction. This post doesn't cover any of the security features such as Diffie-Hellman exchanges for secure password transmission or cryptographic authentication of interface devices.
I am using Vitalik Buterin's "pybtctool" to act as the PoS terminal's software (it looks up unspent outputs and creates unsigned transactions), and I have a simple utility that I've called "sigsafe" that echoes commands to my prototype sigsafe's microcontroller.
The user brings his tag up to the terminal, and, when the terminal senses the presence of the tag, it issues a "stickerAddr" command to get the tag's default spend address (this will be a BIP32 keychain in the future):
Code:
$ sigsafe stickerAddr
1sTKRtNPbtiLLB79gfvbuz9zKTkdGPsNp
The tag responds with its default spend address: 1sTKRtNPbtiLLB79gfvbuz9zKTkdGPsNp
Now let's imagine that the merchant's terminal wants to charge this tag 500 bits for a donation to P2Pool. The first thing the merchant's terminal needs to do is look up the unspent outputs for this address:
Code:
$ pybtctool unspent 1sTKRtNPbtiLLB79gfvbuz9zKTkdGPsNp
[{"output": "d511b9d6b05f8f9dbac56b632acafeffb40c6025f694ae1d738c0d5edaab5308:0", "value": 60000}]
We see that there is one unspent output available with a balance of 600 bits. Next, the merchant's terminal constructs an unsigned transaction that spends 500 bits from this output to P2Pool, and uses the remaining 100 bits for a transaction fee.
Code:
unsigned_tx=`pybtctool mktx d511b9d6b05f8f9dbac56b632acafeffb40c6025f694ae1d738c0d5edaab5308:0 1KxvX5Hx8nh36ig2gT5bpeEcqLQcwJsZGB:50000`
The transaction looks like this:
Code:
$ echo $unsigned_tx
01000000010853abda5e0d8c731dae94f625600cb4fffeca2a636bc5ba9d8f5fb0d6b911d50000000000ffffffff0150c30000000000001976a914d005d127e286f1527cf8faff5e58d0395c2b20b188ac00000000
Before the sigsafe will sign this transaction, it needs a bit more information. The merchant's terminal passes it the complete parent TX for the output being spent in order for the sigsafe to know the value of all the inputs. The -s option allows me to pass the sigsafe the stdout from pybtctool:
Code:
$ pybtctool fetchtx d511b9d6b05f8f9dbac56b632acafeffb40c6025f694ae1d738c0d5edaab5308 | sigsafe load_utxo -s 00
0853ABDA5E0D8C731DAE94F625600CB4FFFECA2A636BC5BA9D8F5FB0D6B911D5
The sigsafe responds with the transaction hash (in little endian).
Next, the merchant's terminal makes a signing request to the sigsafe:
Code:
$ signed_tx=`sigsafe sign $unsigned_tx`
The sigsafe's response was:
Code:
$ echo $signed_tx
01000000010853ABDA5E0D8C731DAE94F625600CB4FFFECA2A636BC5BA9D8F5FB0D6B911D50000000089463043022030FBA161092B46B5BD2B4525E3CEADDA14DF20A01D55060EE83F246768A1E9E2021F291B247E89BEA3B17B1F25D91BDF98B9606ADC9CDFB014706F1DFEAB0B1E5D0141043EA1805BAB032366050116A08E5113E5261079C8B102CC369D2489E2F3C0AFFBCF9EA4B7433AEA2E2F85606E7667E00994BAB5EA39F844031279F60FF0DB3FB2FFFFFFFF0150C30000000000001976A914D005D127E286F1527CF8FAFF5E58D0395C2B20B188AC00000000
There was no error and the merchant can now push this transaction to the network:
Code:
$ pybtctool pushtx $signed_tx
Transaction Submitted
Here's the verbatim bash shell inputs and outputs:
And here's the transaction picked-up at blockchain.info:
Later this week I'll show how the sigsafe can act as a cold wallet, programmed with signing rules to only sign transactions that spend coins to a pre-defined hot wallet.
If anyone goes through this example with a fine-toothed comb, they'll notice that I've used uncompressed pubkeys rather than compressed. The sigsafe defaults to compressed pubkeys to save room in the blockchain, but this post is part of a bunch of work I just did (and will post later) that uses some vanity addresses (1co1d, 1hot, etc) and I couldn't find an easy way to generate a vanity address that used a compressed pubkey! I got sigsafe to start working on it, but I think it will take about a year to find anything
First nine αlpha-model sigsafes
Below are two pictures of the PCBs (gerber files generated by forum member Bonam) for our first nine alpha-model sigsafe bitcoin-signing tags. The first image shows all nine lined up in two rows with a penny and a ruler for a scale reference. Most of the board space is NFC antenna--the sigsafe electronics are very simple.
This picture shows the top (right) and back-side (left) of a sigsafe. The components on the top side include a low-cost microcontroller, a NFC transceiver, two bi-color LEDs, a few MOSFETs, supporting passive components, and solder pads to attach the optional 0.5mm thick battery.
The NFC loop antenna is visible from the backside of the circuit board. NFC antennas are very simple, consisting of one or more loops of copper PCB trace. The antenna is designed to detect the change in magnetic field produced by the NFC reader by taking advantage of Faraday's Law of Induction (a changing magnetic field produces an EMF in the wire loop antenna). The shape of the antenna also causes it to act like an inductor. This inductor forms a resonator circuit with the input capacitance of the NFC transceiver. To achieve maximum power transfer, it is important for the resonance to be tuned to the modulation frequency of the NFC reader. IS0 14443-2 defines a common standard of 13.56 MHz; this standard is used by most RFID and all NFC devices.
To tune the sigsafe's antenna to 13.56 MHz, I hand etched a PCB with a bunch of wire loops, soldered a capacitor equal to the NFC transceiver's input capacitance, and then used a function generator and an oscilloscope to find the resonance frequency. I shorted the extra "loops" in my prototype antenna until I got the resonance close to 13.56 MHz. (If you're wondering what the black thing on the circuit board is, it's sintered ferrite that helps shield the antenna from the optional battery's lithium anode).
Below are two pictures of the PCBs (gerber files generated by forum member Bonam) for our first nine alpha-model sigsafe bitcoin-signing tags. The first image shows all nine lined up in two rows with a penny and a ruler for a scale reference. Most of the board space is NFC antenna--the sigsafe electronics are very simple.
This picture shows the top (right) and back-side (left) of a sigsafe. The components on the top side include a low-cost microcontroller, a NFC transceiver, two bi-color LEDs, a few MOSFETs, supporting passive components, and solder pads to attach the optional 0.5mm thick battery.
The NFC loop antenna is visible from the backside of the circuit board. NFC antennas are very simple, consisting of one or more loops of copper PCB trace. The antenna is designed to detect the change in magnetic field produced by the NFC reader by taking advantage of Faraday's Law of Induction (a changing magnetic field produces an EMF in the wire loop antenna). The shape of the antenna also causes it to act like an inductor. This inductor forms a resonator circuit with the input capacitance of the NFC transceiver. To achieve maximum power transfer, it is important for the resonance to be tuned to the modulation frequency of the NFC reader. IS0 14443-2 defines a common standard of 13.56 MHz; this standard is used by most RFID and all NFC devices.
To tune the sigsafe's antenna to 13.56 MHz, I hand etched a PCB with a bunch of wire loops, soldered a capacitor equal to the NFC transceiver's input capacitance, and then used a function generator and an oscilloscope to find the resonance frequency. I shorted the extra "loops" in my prototype antenna until I got the resonance close to 13.56 MHz. (If you're wondering what the black thing on the circuit board is, it's sintered ferrite that helps shield the antenna from the optional battery's lithium anode).
Jump to: