12/28/14

3 Multi-Sig wallets for the price of 1 -maybe more

3 Multi-Sig wallets for the price of 1 -maybe more

a new Multi-Sig address scheme -Maybe- let me back-up —//|| A transactions has 2 parts – the LOCKING (INPUTS) of the ownership of the coins and the UN-LOCKING (OUTPUTs) of the ownership of the coins. multi-sig or not all TX are the same in the Bitcoin protocol.

id_99

Multi-Sig Sub-Wallets give business safety, management and accountability with my HD-BIP32 Business wallet

gAtO tEsTing  - my HD-wallet system adding multi-sig wallets to the mix. One of the strange but wonderful things I found is when you create a multi-sig wallet, the order of the INPUTS creates different addressed and redeemScripts. So I test it at the BitcoinD command line just to make sure.

A Mutli-sig wallet is different because it’s created out of other sub-wallets,  but the order in INPUTS makes a difference but the strange thing is to cash the multi-sig and sign them, you can still use any other of OUTPUTs – this test shows that any combination of signed OUTPUTs will unlock all 3 different multi-sig addresses for the price of 1.

I included the example below for you to test: Science is repeatable by anyone and so is the crypto and the math of Multi-sigs-

What I did was change the order of the sub-wallet INPUTS   – _01 – _02 – _03 – and - _02 – _03 – _01  -but the biggest surprised was when I tried to cheat -_03 – _01 –  _03  –   I used the 3rd wallet twice and it generated a Multi-sig. So in affect I just created a Multi-sig that only one (1) wallet has to sign it and it counts and 2.

By all rights the – _03 – _01 –  _03   – or any double of the sub-wallets defeats the purpose of 2 out of 3 signatures but working out new smart transactions multi-sig or not. Soon we will be able to do 3 out of 15 multi-sigs and other cool transactions stuff.

The other cool thing is my HD-wallet system will be able to manage, communicate and create any combination of multi-sig 2-n-3 sub-wallets for today, but as Bitcoin and others like Litecoin, DogeCoin or even an NxT transaction systems for really smart intelligent digital contracts. Business that work in this new digital coin game need a HD-BIP32 wallet system that works with their system. Without accountability even multi-sig wallets will not solve things in business. But when you can create and manage all transactions multi-sigs or regular sub-wallets, with accounting being able to safely get reports of all sub-wallets of all Multi-sig wallets and the coins or contracts they hold.

I’ll get of my soapbox -mEoW – play with the examples below – the cool thing it works, the beauty of crypto and math is you can’t cheat – it works or it doesn’t –

A new Multi-Sig address scheme – maybe -yes/no but by using multi-sig wallets the right way we Bitcoin can become safer – in my HD-BIP32 wallet you will be able to manage thousands if not millions of Multi-sig sub-wallets with 1 application - gAtO -oUt 

EXAMPLE:

———————————————————————————————–

_01 sw_key_pair_as_sec: 03a7d8fbe19c3b9aba3b21cab655253bb954702e938312ff9141ee76700a3316ea

_02 sw_key_pair_as_sec: 022bcd0edd96fffae1d59853a5139948e632968d16240ee8bbedd8e964368ace1f

_03 sw_key_pair_as_sec: 02396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e086061685

_01 – _02 – _03

bitcoind createmultisig 2 ‘[“03a7d8fbe19c3b9aba3b21cab655253bb954702e938312ff9141ee76700a3316ea“, “022bcd0edd96fffae1d59853a5139948e632968d16240ee8bbedd8e964368ace1f”, “02396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e086061685“]’

{

“address” : “3MbDdx56fVjgsMWW7VmZhnxas4UJxAQbgf“,

“redeemScript” : “522103a7d8fbe19c3b9aba3b21cab655253bb954702e938312ff9141ee76700a3316ea21022bcd0edd96fffae1d59853a5139948e632968d16240ee8bbedd8e964368ace1f2102396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e08606168553ae”

}

 _02 – _03_01

bitcoind createmultisig 2 ‘[“022bcd0edd96fffae1d59853a5139948e632968d16240ee8bbedd8e964368ace1f”, “02396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e086061685“, “03a7d8fbe19c3b9aba3b21cab655253bb954702e938312ff9141ee76700a3316ea“]’

{

“address” : “3McoaAaTQR8NX4u1y1BxHf3FrWxqjzycHj“,

“redeemScript” : “5221022bcd0edd96fffae1d59853a5139948e632968d16240ee8bbedd8e964368ace1f2102396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e0860616852103a7d8fbe19c3b9aba3b21cab655253bb954702e938312ff9141ee76700a3316ea53ae”

}

_03_01 –  _02

bitcoind createmultisig 2 ‘[“02396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e086061685“, “03a7d8fbe19c3b9aba3b21cab655253bb954702e938312ff9141ee76700a3316ea“, “022bcd0edd96fffae1d59853a5139948e632968d16240ee8bbedd8e964368ace1f”]’

{

“address” : “3LYZsV7NaMaGhdbtdwvBwFJcs63QiYzzeF“,

“redeemScript” : “522102396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e0860616852103a7d8fbe19c3b9aba3b21cab655253bb954702e938312ff9141ee76700a3316ea21022bcd0edd96fffae1d59853a5139948e632968d16240ee8bbedd8e964368ace1f53ae”

}

_03 – _01 –  _03

bitcoind createmultisig 2 ‘[“02396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e086061685“, “03a7d8fbe19c3b9aba3b21cab655253bb954702e938312ff9141ee76700a3316ea“, “02396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e086061685“]’

{

“address” : “3FEAsZ8KDvodHmTQy2rnWKknQWKCuazdLC“,

“redeemScript” : “522102396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e0860616852103a7d8fbe19c3b9aba3b21cab655253bb954702e938312ff9141ee76700a3316ea2102396b913639612c603471a39c780a49afabf9a45ea62d1edfda77e2e08606168553ae”

}

———————————————————————————

12/13/14

Using Bitcoin Multi-Sig Wallets in Business

gAtO wOrKiNg - on his HD-BIP32 business wallet and I was working on how to design the Multi-Sig wallets came up and I needed to ask a lot of questions first: We can use the HD-BIP32 business wallet and Bitcoin 2.0 technology with Multi-Sigs to manage all kinds of assets class?

Motivation:

In a business context we can create Multi-Sig sub-wallets as revenue stream or as an INCOME Wallet. With our Multi-Sig Sub-wallet  we will be able to do 2 things pretty easy. First -1st- It will prevent anyone -employees- from stealing funds from that wallet because you need 2 out of 3 signatures to release the funds. Second -2nd- Security has now becomes harder for a hacker to steal your Bitcoin even if they get one PrivateKey-

From a consumers point of view they can now monitor a Multi-Sig in the public BlockChain to make sure TX-transactions were made. Example —> Using the HD-BIP32 wallet with divined payments:

With a Multi-Sig wallet you can have your accounting people set up a multi-address transactions to the people who get payed and sign it. Next the CFO can now come in and add the second signature to the Multi-Sig sub-wallet to release the funds to people expecting their divined payments. Like I said they can check the BlockChain to verify that the payment was made.

The management of a Multi-Sig sub-wallet’s for any business is essential to keep your Bitcoins in your business managed by the people that YOU trust but allowing others to use it to add any revenue stream that takes in Bitcoins. Since my wallet manages all Multi-Sig wallets just like any other sub-wallet in a HD-BIP32 wallet. Your in total control of all your wallets and all your coins. Plus our HD-BIP32 business wallet will give you 100% backup and management off millions of Multi-Sig sub-wallets with just 1 one-backup… That’s sweet. 

So managing hundreds of thousands of Multi-Sig sub-wallets has to be an easy job and with my HD-BIP32 Business wallet it can do the job and give you control of all your Bitcois in your Business

here is a Video of my HD-BIP32 business development wallet — http://youtu.be/gOPdFPHNByk — still a work in progress and I have much to learn – but working on it- looking for investors — Cheers – gAtO OuT

12/7/14

Looking for Investors in my BIP32 Business wallets.

gAtO bAcK - I am almost finished with my BIP32 Business wallet and I need investors to finish it up and make it pretty and then get it into the business community so they can also have a Bitcoin Business wallet designed for business not an individual.

If you want to see a video of the wallet demo just come on over and check out my Wallet Demohttp://youtu.be/gOPdFPHNByk If you have any comment or suggestions please contact me. - gAtO oUt

11/21/14

Bitcoin and Tor Support

Bitcoin and Tor Support

It is possible to run Bitcoin as a Tor hidden service, and connect to such services.

The following directions assume you have a Tor proxy running on port 9050. Many distributions default to having a SOCKS proxy listening on port 9050, but others may not. In particular, the Tor Browser Bundle defaults to listening on a random port. See Tor Project FAQ:TBBSocksPort for how to properly configure Tor.bitcoin-gollum

1. Run bitcoin behind a Tor proxy

The first step is running Bitcoin behind a Tor proxy. This will already make all outgoing connections be anonymized, but more is possible.

-socks=5        SOCKS5 supports connecting-to-hostname, which can be used instead

of doing a (leaking) local DNS lookup. SOCKS5 is the default,

but SOCKS4 does not support this. (SOCKS4a does, but isn’t

implemented).

-proxy=ip:port  Set the proxy server. If SOCKS5 is selected (default), this proxy

server will be used to try to reach .onion addresses as well.

-onion=ip:port  Set the proxy server to use for tor hidden services. You do not

need to set this if it’s the same as -proxy. You can use -noonion

to explicitly disable access to hidden service.

-listen         When using -proxy, listening is disabled by default. If you want

to run a hidden service (see next section), you’ll need to enable

it explicitly.

-connect=X      When behind a Tor proxy, you can specify .onion addresses instead

-addnode=X      of IP addresses or hostnames in these parameters. It requires

-seednode=X     SOCKS5. In Tor mode, such addresses can also be exchanged with

other P2P nodes.

In a typical situation, this suffices to run behind a Tor proxy:

./bitcoin -proxy=127.0.0.1:9050

2. Run a bitcoin hidden server

If you configure your Tor system accordingly, it is possible to make your node also reachable from the Tor network. Add these lines to your /etc/tor/torrc (or equivalent config file):

HiddenServiceDir /var/lib/tor/bitcoin-service/

HiddenServicePort 8333 127.0.0.1:8333

HiddenServicePort 18333 127.0.0.1:18333

The directory can be different of course, but (both) port numbers should be equal to your bitcoind’s P2P listen port (8333 by default).

-externalip=X   You can tell bitcoin about its publicly reachable address using

this option, and this can be a .onion address. Given the above

configuration, you can find your onion address in

/var/lib/tor/bitcoin-service/hostname. Onion addresses are given

preference for your node to advertize itself with, for connections

coming from unroutable addresses (such as 127.0.0.1, where the

Tor proxy typically runs).

-listen         You’ll need to enable listening for incoming connections, as this

is off by default behind a proxy.

-discover       When -externalip is specified, no attempt is made to discover local

IPv4 or IPv6 addresses. If you want to run a dual stack, reachable

from both Tor and IPv4 (or IPv6), you’ll need to either pass your

other addresses using -externalip, or explicitly enable -discover.

Note that both addresses of a dual-stack system may be easily

linkable using traffic analysis.

In a typical situation, where you’re only reachable via Tor, this should suffice:

./bitcoind -proxy=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -listen

(obviously, replace the Onion address with your own). If you don’t care too much about hiding your node, and want to be reachable on IPv4 as well, additionally specify:

./bitcoind … -discover

and open port 8333 on your firewall (or use -upnp).

If you only want to use Tor to reach onion addresses, but not use it as a proxy for normal IPv4/IPv6 communication, use:

./bitcoin -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover

07/30/14

Tor Traffic Confirmation Attack

Tor Traffic Confirmation Attack -Roger Dingledine Report
SUMMARY:
  On July 4 2014 we found a group of relays that we assume were trying
  to deanonymize users. They appear to have been targeting people who
  operate or access Tor hidden services. The attack involved modifying
  Tor protocol headers to do traffic confirmation attacks.gato_signal_02

  The attacking relays joined the network on January 30 2014, and we
  removed them from the network on July 4. While we don't know when they
  started doing the attack, users who operated or accessed hidden services
  from early February through July 4 should assume they were affected.

  Unfortunately, it's still unclear what "affected" includes. We know
  the attack looked for users who fetched hidden service descriptors,
  but the attackers likely were not able to see any application-level
  traffic (e.g. what pages were loaded or even whether users visited
  the hidden service they looked up). The attack probably also tried to
  learn who published hidden service descriptors, which would allow the
  attackers to learn the location of that hidden service. In theory the
  attack could also be used to link users to their destinations on normal
  Tor circuits too, but we found no evidence that the attackers operated
  any exit relays, making this attack less likely. And finally, we don't
  know how much data the attackers kept, and due to the way the attack
  was deployed (more details below), their protocol header modifications
  might have aided other attackers in deanonymizing users too.

  Relays should upgrade to a recent Tor release (0.2.4.23 or
  0.2.5.6-alpha), to close the particular protocol vulnerability the
  attackers used -- but remember that preventing traffic confirmation in
  general remains an open research problem. Clients that upgrade (once
  new Tor Browser releases are ready) will take another step towards
  limiting the number of entry guards that are in a position to see
  their traffic, thus reducing the damage from future attacks like this
  one. Hidden service operators should consider changing the location of
  their hidden service.

THE TECHNICAL DETAILS:
  We believe they used a combination of two classes of attacks: a traffic
  confirmation attack and a Sybil attack.

  A traffic confirmation attack is possible when the attacker controls
  or observes the relays on both ends of a Tor circuit and then compares
  traffic timing, volume, or other characteristics to conclude that the
  two relays are indeed on the same circuit. If the first relay in the
  circuit (called the "entry guard") knows the IP address of the user,
  and the last relay in the circuit knows the resource or destination
  she is accessing, then together they can deanonymize her. You can read
  more about traffic confirmation attacks, including pointers to many
  research papers, at this blog post from 2009:
  https://blog.torproject.org/blog/one-cell-enough

  The particular confirmation attack they used was an active attack where
  the relay on one end injects a signal into the Tor protocol headers,
  and then the relay on the other end reads the signal. These attacking
  relays were stable enough to get the HSDir ("suitable for hidden
  service directory") and Guard ("suitable for being an entry guard")
  consensus flags:
  https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1775
  Then they injected the signal whenever they were used as a hidden
  service directory, and looked for an injected signal whenever they
  were used as an entry guard.

  The way they injected the signal was by sending sequences of "relay"
  vs "relay early" commands down the circuit, to encode the message they
  want to send. For background, Tor has two types of cells: link cells,
  which are intended for the adjacent relay in the circuit, and relay
  cells, which are passed to the other end of the circuit.
  https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt#l364
  In 2008 we added a new kind of relay cell, called a "relay early"
  cell, which is used to prevent people from building very long paths
  in the Tor network (very long paths can be used to induce congestion
  and aid in breaking anonymity):
  http://freehaven.net/anonbib/#congestion-longpaths
  https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/110-avoid-infinite-circuits.txt
  But the fix for infinite-length paths introduced a problem with
  accessing hidden services:
  https://trac.torproject.org/projects/tor/ticket/1038
  and one of the side effects of our fix for bug 1038 was that while
  we limit the number of outbound (away from the client) "relay early"
  cells on a circuit, we don't limit the number of inbound (towards the
  client) relay early cells:
  https://lists.torproject.org/pipermail/tor-commits/2009-July/014679.html

  So in summary, when Tor clients contacted an attacking
  relay in its role as a Hidden Service Directory to publish
  or retrieve a hidden service descriptor (steps 2 and 3 on
  https://www.torproject.org/docs/hidden-services), that relay would
  send the hidden service name (encoded as a pattern of relay and
  relay-early cells) back down the circuit. Other attacking relays,
  when they get chosen for the first hop of a circuit, would look for
  inbound relay-early cells (since nobody else sends them) and would
  thus learn which clients requested information about a hidden service.

  There are three important points about this attack:

  A) The attacker encoded the name of the hidden service in the injected
  signal (as opposed to, say, sending a random number and keeping a local
  list mapping random number to hidden service name). The encoded signal
  is encrypted as it is sent over the TLS channel between relays. However,
  this signal would be easy to read and interpret by anybody who runs
  a relay and receives the encoded traffic. And we might also worry
  about a global adversary (e.g. a large intelligence agency) that
  records Internet traffic at the entry guards and then tries to break
  Tor's link encryption. The way this attack was performed weakens Tor's
  anonymity against these other potential attackers too -- either while
  it was happening or after the fact if they have traffic logs. So if
  the attack was a research project (i.e. not intentionally malicious),
  it was deployed in an irresponsible way because it puts users at risk
  indefinitely into the future.

  (This concern is in addition to the general issue that it's probably
  unwise from a legal perspective for researchers to attack real users
  by modifying their traffic on one end and wiretapping it on the
  other. Tools like Shadow are great for testing Tor research ideas out
  in the lab: http://shadow.github.io/ )

  B) This protocol header signal injection attack is actually pretty neat
  from a research perspective, in that it's a bit different from previous
  tagging attacks which targeted the application-level payload. Previous
  tagging attacks modified the payload at the entry guard, and then
  looked for a modified payload at the exit relay (which can see the
  decrypted payload). Those attacks don't work in the other direction
  (from the exit relay back towards the client), because the payload
  is still encrypted at the entry guard. But because this new approach
  modifies ("tags") the cell headers rather than the payload, every
  relay in the path can see the tag.

  C) We should remind readers that while this particular variant of
  the traffic confirmation attack allows high-confidence and efficient
  correlation, the general class of passive (statistical) traffic
  confirmation attacks remains unsolved and would likely have worked
  just fine here. So the good news is traffic confirmation attacks
  aren't new or surprising, but the bad news is that they still work. See
  https://blog.torproject.org/blog/one-cell-enough for more discussion.

  Then the second class of attack they used, in conjunction with their
  traffic confirmation attack, was a standard Sybil attack -- they
  signed up around 115 fast non-exit relays, all running on 50.7.0.0/16
  or 204.45.0.0/16. Together these relays summed to about 6.4% of the
  Guard capacity in the network. Then, in part because of our current
  guard rotation parameters:
  https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters
  these relays became entry guards for a significant chunk of users over
  their five months of operation.

  We actually noticed these relays when they joined the network, since
  the DocTor scanner reported them:
  https://lists.torproject.org/pipermail/tor-consensus-health/2014-January/004134.html
  https://gitweb.torproject.org/doctor.git
  We considered the set of new relays at the time, and made a decision
  that it wasn't that large a fraction of the network. It's clear there's
  room for improvement in terms of how to let the Tor network grow while
  also ensuring we maintain social connections with the operators of all
  large groups of relays. (In general having a widely diverse set of relay
  locations and relay operators, yet not allowing any bad relays in,
  seems like a hard problem; on the other hand our detection scripts did
  notice them in this case, so there's hope for a better solution here.)

  In response, we've taken the following short-term steps:

  1) Removed the attacking relays from the network.
  2) Put out a software update for relays to prevent "relay early" cells
     from being used this way.
  3) Put out a software update that will (once enough clients have
     upgraded) let us tell clients to move to using one entry guard
     rather than three, to reduce exposure to relays over time.
  4) Clients can tell whether they've received a relay or relay-cell.
     For expert users, the new Tor version warns you in your logs if
     a relay on your path injects any relay-early cells: look for the
     phrase "Received an inbound RELAY_EARLY cell".

  The following longer-term research areas remain:

  5) Further growing the Tor network and diversity of relay operators,
     which will reduce the impact from an adversary of a given size.
  6) Exploring better mechanisms, e.g. social connections, to limit the
     impact from a malicious set of relays. We've also formed a group to
     pay more attention to suspicious relays in the network:
     https://blog.torproject.org/blog/how-report-bad-relays
  7) Further reducing exposure to guards over time, perhaps by extending
     the guard rotation lifetime:
     https://blog.torproject.org/blog/lifecycle-of-a-new-relay
     https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters
  8) Better understanding statistical traffic correlation attacks and
     whether padding or other approaches can mitigate them.
  9) Improving the hidden service design, including making it harder
     for relays serving as hidden service directory points to learn what
     hidden service address they're handling:
     https://blog.torproject.org/blog/hidden-services-need-some-love

OPEN QUESTIONS:
  Q1) Was this the Black Hat 2014 talk that got canceled recently?
  Q2) Did we find all the malicious relays?
  Q3) Did the malicious relays inject the signal at any points besides
      the HSDir position?
  Q4) What data did the attackers keep, and are they going to destroy it?
      How have they protected the data (if any) while storing it?

  Great questions. We spent several months trying to extract information
  from the researchers who were going to give the Black Hat talk, and
  eventually we did get some hints from them about how "relay early"
  cells could be used for traffic confirmation attacks, which is how
  we started looking for the attacks in the wild. They haven't answered
  our emails lately, so we don't know for sure, but it seems likely that
  the answer to Q1 is "yes". In fact, we hope they *were* the ones doing
  the attacks, since otherwise it means somebody else was. We don't yet
  know the answers to Q2, Q3, or Q4.
07/20/14

DELL, NEW YORK STATE AND BLOOMBERG ON BITCOIN AND VIRTUAL CURRENCIES

DELL, NEW YORK STATE AND BLOOMBERG ON BITCOIN AND VIRTUAL CURRENCIES

 

  • Last week, New York State released a proposed regulatory framework for virtual currencies and Benjamin Lawsky, Superintendent of Financial Services said: “We have sought to strike an appropriate balance that helps protect consumers and root out illegal activity – without stifling beneficial innovation. Setting up common sense rules of the road is vital to the long-term future of the virtual currency industry, as well as the safety and soundness of customer assets.” Note: “Virtual currencies” include bitcoin and other digital currencies, but excludes online gaming platforms and customer affinity or rewards programs such as airline miles. The review and comment period is open for 45-days.
  • In addition, Dell said it is starting a pilot test to support bitcoin as a purchase option on Dell.com for consumer and small business shoppers in the U.S. According to Adam White, of payment processor Coinbase, there will be no processing fees for Dell on the first $1 million in sales and a 1% flat fee for sales above that level.
  • Finally, a Bloomberg survey of 562 of its subscribers found that 55% said the price of bitcoin was unsustainable, 14% said it was on the verge of a bubble, 5% said a bubble was not forming and 25% were unsure.
07/18/14

Speaking at the NYC Bitcoin Center -HD-BIP32 Multi-sig Business Wallet

gAtO - will be Ringing the Trading Bell and presenting his HD-BIP32 Multi-sig Business wallet at the NYC Bitcoin Center with my good friend Dr. Nicolas T. Courtois from the University College London on Monday July 21 2014. If anyone is in the NYC area and wants to come on down for the show and after do a little Bitcoin trading – Come on Down. - gAtO oUt

poster_NYC

06/18/14

Business HD-BIP32 sub-wallet and Multi-Sig

Business HD-BIP32 sub-wallet and Multi-Sig -the Safest Wallet Anywhere!

gAtO hear- Business are all hot and heavy about the security of business Multi-Sig Bitcoin wallets. But in fact you need 3 different wallets and the ability to control them and the private keys and if it’s a long term like a cold storage wallet who knows the status of those wallets.bip32-Multi-sig_01

Your financial security while using Bitcoins needs help and Multi-sig wallets are a major improvements to it’s safety and security, but controlling 3 different wallets with 3 different backups and 3 different places can get a little confusing. With my new business HD-BIP32 wallets you control all the sub-wallets with just 1 master-wallets and just 1 backup. You control every sub-wallet you create. This assures you that only you can extract the funds in your business multi-sig wallets.

With my new business HD-BIP32 wallet allows you control of all the sub-wallets and you can create millions of sub-wallets and use them to create and release funds from any Multi-Sig wallet you create.

You can save the salt/genesis of your business HD-BIP32 master-wallet and with 1 backup you can always recreate your wallets from scratch. So now even if something happens to you, your family or business can take the backup and re-create the master-wallet and all the sub-wallets you control and always get your money out of my multi-sig HD-BIP32 sub-wallet I created.

the kinda geek side of HD Bip32 wallets:

The OLD normal Bitcoin reference wallet uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such “neutered” wallets lose the power to generate public keys as well.

Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).

However, deterministic wallets typically consist of a single “chain” of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant’s wallet; only to those addresses which are used to receive customer’s payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root. -gAtO OuT…  

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

 

06/14/14

How To Bitcoin Multi Signature Address -Wallet

multi-sig-01gAtO ThInK – Multi-Sig will help Bitcoins, but it’s all about the blockchain since it is the one that keeps the Multi-sig Address and the release of the funds by 2 of the 3 signing of the escrow transaction and recording it in the blockchain and it get’s confirmed by the miners like all good Bitcoin transactions so try and give the miners a little fee in any transactions.

Multi-Sig TX

Multi-Sig TX

BUT it’s kinda complicated and most wallets do not support Multi-Sig. The few that do allow Multi-Sig almost require you to be a programmer of sort to even generate the Multi-Sig Address yet alone spend your money once you have them in the wallet.

  1. - First thing is to generate the Multi-sig Wallet address: 
  2. - Register the wallet in the blockchain by sending some money to this address to verify it is working.   
  3. - To get you money out of a Multi-Sig address you need to: signrawtransaction
  4. - We have to get 2 of the 3 to sign the transaction and submit it to the blockchain. – Of course 1 ? 2 – or 3 privateKeys too authorize the transaction. Depending on how you set it up in the first place.   
    • RedeemScript
    • TXid
    • ScriptPubKey
  5. Spend you Bitcoins

So let’s try to decode all this horse-play and do some Multi-Sig Wallet Stuff— BEFORE YOU BEGIN Questions— Pre-Multi-sig Wallet Creation – How many users must sign to release the coins in this Multi-sig wallet – 1 ? 2 ? 3 – make sure you have access to the PrivateKeys of these. You must have access to the PrivateKey of the wallet address you use. Because of the Version of Bitcoin code you can only create a 1 ? 2 or 3 user Multi-Sig wallet- the code will not support a more complex Multi-Sig structure right now, in the future you will be able to create 5 of 7 or 8 of 15 or what ever weird way you want to release your  money from these Multi-Sig Wallets. Todays code only allows 1-2 or 3 signatures to release funds. So once you have this figured out we can begin to generate the NEW Wallet ADDRESS:

Pay to Script

Pay to Script code’s it all and delivers it to the blockchain

PRE-Multi-Sig Address Generation: For our example below I will use 3 different Wallets I generate for this test, these are throw away addresses but you can use them to test it your self.

  1. 1Pum4jukypYddQDywoQDcgdkz7NMKKHXGR
  2. 1L7xm1TrwpsNBCrAaNUw8eBwD115Tr7tpC
  3. 145dwy7fvmRJwMpXDVzuZpNSd6UwEbabk2

I am assuming that you are running BitcoinD on your server – if you run Bitcoin-qt you will have access to this command. You can use the “CreateMultiSig” or the “AddMultiSigAddress” commands // they  will generate the Multi-Sig Bitcoin Address, but “CreateMultiSig” is the only one that will give you back the  – “redeemScript” –  and you need this script to get your Bitcoins out of the Multi-Sig address wallet. (Bitcoin Ver 8.9)

1.createmultisig <nrequired> <‘[“key,”key”]’> Creates a multi-signature address and returns a json object “redeemScript”

 

2. addmultisigaddress <nrequired> <‘[“key”,”key”]’> [account] Add a nrequired-to-sign multisignature address to the wallet. Each key is a bitcoin address or hex-encoded public key. If [account] is specified, assign address to [account]. ”NO-redeemScript”

Step 1 – Generate Bitcoin Wallet Address //  It will starts with a number “3”. nRequired you need 1, 2 or 3 signatures to release the funds I have chosen any 2 of the 3 Bitcoin Address listed in the command below can release the coins in the NEW Multi-Sig address—

CREATEMULTISIG

COMMAND:

bitcoind createmultisig 2 ‘[“1Pum4jukypYddQDywoQDcgdkz7NMKKHXGR“, “1L7xm1TrwpsNBCrAaNUw8eBwD115Tr7tpC“, “145dwy7fvmRJwMpXDVzuZpNSd6UwEbabk2“]’

OUTPUT: {     “address” : “3DLwoeBuoQRMUDvqvbwQCiYnpauxwC1i71″,    

redeemScript” : “5221022934c1f3ddc25426fc057ca706d66d818f63f00f3bb4ad4762947ec23b8c316e210343e871878f6a66728c2a8bec2ae0bffbd4c862968e20280526645f4157de7fca21022a453e7eea23207f87c46881b2e63f56c5ec2e59b30fe887ef29bd21ed67c15d53ae” }

So now you can give this new Multi-Sig address to people – 3DLwoeBuoQRMUDvqvbwQCiYnpauxwC1i71 –  Now you have your NEW Bitcoin Multi-Sig address and people can start to send money to this wallet address. I sent some Bitcoins to this NEW Multi-Sig address from my Wallet . Then I went to my Bitcoin console and typed in:

GETRECEIVEBYADDRESS

COMMAND: bitcoind getreceivedbyaddress 3DLwoeBuoQRMUDvqvbwQCiYnpauxwC1i71

OUTPUT: 0.00300000

Now I know my NEW Multi-Sig Wallet is in working order and registered in the blockchain remember if it not registered in the blockchain then it nothing NADA-one zip. Rules of the Muliti-Signature Wallet

  • All MultiSig address start with the number “3” a regular Bitcoin address start with the number “1”.
  • You can only have a 1-2 or 3 part Multi-Sig wallet. We cannot do a 5 or 7 part Multi-sig transaction today do to the core Bitcoin CODE.

So now I have a NEW Bitcoin Address —3DLwoeBuoQRMUDvqvbwQCiYnpauxwC1i71  —  and now people can send Bitcoins to that address as much as they want and it acts just like a normal Bitcoin Wallet.

Step 2 – GET MONEY OUT of a Multi-Sig address Wallet — So now i can look at my Multi-sig wallet and check to see if I have any money in my account

LISTUNSPENT COMMAND:

bitcoind listunspent OUTPUT:     {        

txid” : “c45c8c00243c703412e207646d51bf6878444537c37372528012f412f552b9cd”,        

“vout” : 0,        

“address” : “3DLwoeBuoQRMUDvqvbwQCiYnpauxwC1i71″,        

“account” : “”,        

scriptPubKey” : “a9147fd5c07649707498b47a50039bdcadc703e7e85e87″,        

redeemScript” : “5221022934c1f3ddc25426fc057ca706d66d818f63f00f3bb4ad4762947ec23b8c316e210343e871878f6a66728c2a8bec2ae0bffbd4c862968e20280526645f4157de7fca21022a453e7eea23207f87c46881b2e63f56c5ec2e59b30fe887ef29bd21ed67c15d53ae”,        

“amount” : 0.00300000,        

“confirmations” : 1,        

“spendable” : true     }

As you can see by the output and remember this is all in the blockchain  https://blockchain.info/tx/c45c8c00243c703412e207646d51bf6878444537c37372528012f412f552b9cd

SINGRAWTRANSACTION Now we need to sign the release of funds from this address with the

signrawtransaction COMMAND this is the syntax but if you look carefully you will see txid scriptPubKey”, redeemScript and if you look above OUTPUT: with my LISTUNSPENT command you will see this information.

Now you just need the PrivateKey to sign the transaction. signrawtransaction <hex string> [{“txid“:txid,”vout”:n,”scriptPubKey“:hex,”redeemScript“:hex},…] [<privatekey1>,…] [sighashtype=”ALL”]

  • Sign inputs for raw transaction (serialized, hex-encoded).
  • Second optional argument (may be null) is an array of previous transaction outputs that this transaction depends on but may not yet be in the block chain.
  • Third optional argument (may be null) is an array of base58-encoded private keys that, if given, will be the only keys used to sign the transaction.
  • Fourth optional argument is a string that is one of six values; ALL, NONE, SINGLE or ALL|ANYONECANPAY, NONE|ANYONECANPAY, SINGLE|ANYONECANPAY.
  • Returns json object with keys:
    • hex : raw transaction with signature(s) (hex-encoded string)
    • complete : 1 if transaction has a complete set of signature (0 if not)

SENDRAWTRANSACTION  Once all signed the TX it will produce a HEX string – we take that info and add it to

SENDRAWTRANSACTION and I will finally get my Bitcoins and spend them from my Multi-sig wallet. You can keep putting money into this wallet and just have them signed and you can keep getting money out forever- this is just another  Bitcoin wallet address with a few gatekeepers, it harder but more secure in the long run. hope this helps a little – In my new BIP32 wallet I have all this out in a nice GUI to Keep it simple but still have the power of an escrow Multi-sig Wallet- gAtO OuT

3. signrawtransaction <hexstring> [{“txid”:txid,”vout”:n,”scriptPubKey”:hex},…] [<privatekey1>,…] version 0.7 Adds signatures to a raw transaction and returns the resulting raw transaction. Y/N

 

sendrawtransaction <hexstring> version 0.7 Submits raw transaction (serialized, hex-encoded) to local node and network. N

 

4. createrawtransaction [{“txid”:txid,”vout”:n},…] {address:amount,…} version 0.7 Creates a raw transaction spending given inputs. N

 

decoderawtransaction <hex string> version 0.7 Produces a human-readable JSON object for a raw transaction. N

 

listunspent [minconf=1] [maxconf=999999] version 0.7 Returns array of unspent transaction inputs in the wallet.

 

listlockunspent version 0.8 Returns list of temporarily unspendable outputs

 

lockunspent <unlock?> [array-of-objects] version 0.8 Updates list of temporarily unspendable outputs

https://gist.github.com/gavinandresen/3966071