Copay Team Broadcasts First BIP32 P2SH Multisig ...

Please help alpha test Ninki Wallet, the worlds first social, BIP32 MultiSig Bitcoin wallet!
Here is a screenshot:
We currently only support Chrome, Safari and Firefox
Ninki Wallet
Hi, been working on this like madmen for the last few months. Looking for people to help out with an Alpha test. The wallet currently runs on a private TestNet, sign up and in "Add a Contact" put in ninki and hit "Add Contact" I'll send you some coin
Some basic specs: Secure - Multi-sig 2 of 3 wallet, the user has 2 keys, we have 1. We do not know your private keys (or even your public keys), all data is encrypted with your password.
Private - BIP32- addresses are never reused, communication between contacts uses RSA public/private key encryption
Social- BIP32 Social, add contacts and automatically assign them to a BIP32 node. You never need to see a Bitcoin address again to send them coin, and they never need to ask you for an address to send! Master public key exchange is done via RSA public/private key encryption with an optional out of band validation code available.
Transfer Limits- You can setup transfer limits which we control via our part of the multi-sig addresses. You need to setup 2FA to change these limits. They currently default to: Daily Transaction Limit: 0.1 Single Transaction Limit: 1 Number Of Transactions Per Day: 10 Number Of Transactions Per Hour: 4 The philosophy behind the wallet is bringing these advanced features of the Bitcoin protocol to a well designed and usable site.
I'm sure there will be lots of questions and I am here to answer!
Would really appreciate any bug reports / opinions on what needs to be improved / features to add.
submitted by Ninki-Ben to Bitcoin [link] [comments]

Unsplit BCH/BSV current best way to split these?

Hello, Found an older wallet that I forgot about. It has PRE BSV split BCH in it.
Can you still send these to CoinEx and the split appears with your BSV?
Is there anything easier than that?
I don't have the 12 word seed. (BIP 39?) I have an older version seed. This wallet was created many years ago on extraction tool is failing on me. I had that problem in the past.

I HAVE NOT SENT THE BALANCE back to me so from what I understand I have not done any replay protection
submitted by NewFlipPhoneWhoDis to btc [link] [comments]

Groestlcoin 6th Anniversary Release


Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

How to Upgrade?

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.

Other Linux


Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here


ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.





ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.



Main Release (Main Net)
Testnet Release


ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.


Live Version (Not Recommended)



ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).





ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).




Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.


Remastered Improvements



ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.



Linux :
 pip3 install -r requirements.txt python3 bip39\ 


ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.



Linux / OSX (Instructions)


UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.



Main Net
Main Net (FDroid)
Test Net


UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.




UPDATED – P2Pool Test Net



Pre-Hosted Testnet P2Pool is available via


submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Multisig Done Right: Launching Co-Sign Pages and Multisig API (M-of-15) [AMA]

Multisig Done Right: Launching Co-Sign Pages and Multisig API (M-of-15) [AMA] submitted by rnvk to Bitcoin [link] [comments]

bitWallet is a solid choice for iOS users wanting a free mobile wallet on the App Store. Very polished and feature rich, with minor pushtx workaround for spending. Not enough Apple/iOS users know about this app yet.

bitWallet is a solid choice for iOS users wanting a free mobile wallet on the App Store. Very polished and feature rich, with minor pushtx workaround for spending. Not enough Apple/iOS users know about this app yet. submitted by BashCo to Bitcoin [link] [comments]

DarkWallet Update

One of the wallet main devs here. Sorry about not having posted much status on reddit, but we've been very busy with the firm goal of releasing soon.
(note about perks, I think Cody will be updating soon on those, we're not managing that so please keep this topic for wallet development questions or feedback)
Anyways, we have been starting more public communications, starting from the mailing list:
We also have the wiki, that for those interested hosts a lot of information about previous investigation, specs for what we're doing etc:
Regarding the dark wallet planned schedule, we wanted to do an alpha this week, as explained in the following email:
This week we have been delayed due to personal reasons, but hope we can meet the deadline for next week (sorry ppl). Alpha will mean big features are complete (multisig, coinjoin, stealth) and must support testnet.
We are very close to "feature complete" on the chrome version, firefox version shouldn't take much once we have the chrome one running where we're basing our testing. The idea is as soon as we can finish off coinjoin (missing just a few things there) we will be looking into testnet release in order to release an alpha where ppl can test with fake coins. There is also some details about multisig spending we need a few days to finish off (at least to make it more automatic like the coinjoin).
All in all, most of the hard work is already behind us, we have the following:
Not to forget the work done also on the backend that Amir is leading:
Some screenshots of current state (thanks zodman for taking the time to take those):
We are aiming for a full featured wallet, and I think we're delivering soon, maybe it can take a bit more of time in development, but we're putting an incredible amount of effort and love into the wallet. Also, this is just the beginning, this is a infrastructure where soon we can layer much more functionality and we will do it. Also, don't think the project is the kind where we want to do a rushed release, rather delay a bit for really good testing and hardening.
For people that want more specific dates, we can say we will release "when it's ready" and it's the right thing to do, but as said, I think we can take one week to release an alpha on testnet, then about two more weeks to stabilize and tie up things for a beta. During that period we will also be releasing technical documents on bitcointalk to validate our approaches to cryptographic techniques.
We welcome ppl who want to test or check the code: But only recommend it for more technical ppl at the moment (several reasons, check the readme where it says Pre-Alpha!). When we can release the alpha we'll make it better so it's safe to test for anyone.
We are already at the point where the wallet is always working, just features are still dropping.
If you want to support us, you can send BTC to the following multisig address:
( for details)
Of course, all feedback or questions welcome!
Kisses and thanks to all the supporters, we couldn't be doing this without you!!
submitted by caedesv to Bitcoin [link] [comments]

[Tutorial] How to ballpark your transaction fee.

A lot of apps do this automatically for you now, but I just wanted to share my old grandpa way of ballparking fees with anyone in case it ever comes in handy.
Note this will differ with multisig and whatnot.
Most transactions are using one or two inputs and generate two outputs, keeping the overall size of the transaction under 1 kb.
However, some people who receive tons of small inputs from faucets are shocked to find that they are paying huge fees, or in the case of (which you can set your own fees if you want) they set a low fee and are shocked when it doesn't confirm.
First let's make an assumption, you are creating two outputs. One is your sending amount, and the other is sent back to your wallet.
This takes up 34 bytes x number of outputs (for normal bitcoin addresses with a 1, for multisig, it's actually one byte less, but negligible.)
So now we have 68 bytes.
Then, we add up all the metadata, input counts, output counts etc... that will add up to 10 bytes in almost any transaction I've seen.
So now we have 78 bytes.
Then we have to consider whether the keys we're using are compressed or not... the most difficult part.
  1. if you're using or Electrum (any wallet generated pre-2.0), they're uncompressed.
  2. if you're using any wallet with BIP32 enabled (recently Bitcoin Wallet, Mycelium, etc. have switched over) and the bitcoin you received is bitcoin received to one of those addresses, they're compressed.
  3. if your WIF private key starts with a 5, uncompressed... with a K or L, it's compressed.
For each input, there are 2 bytes of wiggle room for the signatures. (this is due to padding of the DER encoded signatures based on the numbers that resulted)
Uncompressed inputs: 179 - 181 bytes
Compressed inputs: 147 - 149 bytes
If we assume the largest every time just to err on the side of too much fees, just in case... that means to fill up 1 kb, we take out 78 bytes and add inputs to get:
Uncompressed: 5 inputs x 181 bytes + 78 bytes = 983 bytes
Compressed: 6 inputs x 149 bytes + 78 bytes = 972 bytes
So think of how many receiving transactions you have, and whether those are uncompressed or not, and if you wanted to move the whole balance, you will need to divide that number by 5 or 6 and then you'll get a super rough estimate of how many kb your transaction will be.
Then just multiply kb times 0.00001, and maybe add a little extra to account for the small amount of pre-0.9.0 nodes, and you should be good.
Edit: Included the fact that Electrum (pre-2.0) is uncompressed. Some people seem to think pre-2.0 Electrum is BIP32, but it's not... (it was the INSPIRATION for BIP32 in fact)
submitted by kinoshitajona to Bitcoin [link] [comments]

Electrum 2.0 has been tagged | Thomas Voegtlin | Mar 01 2015

Thomas Voegtlin on Mar 01 2015:
Hash: SHA1
Dear Bitcoin devs,
I just tagged version 2.0 of Electrum:
The website will be updated later today. The release
notes are a bit dense, due to the large amount of changes and new
features in this release. In the coming weeks we will be adding more
detailed documentation to the wiki and to the website.
There has been a very long hiatus in Electrum releases, because it
took me a lot of time to decide about the new seed derivation method
and wallet structure. Now that this part is done, I hope that we will
resume to a faster release pace.
I would like to thank all the people who contributed to this release,
developers, beta testers, but also people from this list who provided
useful feedback.

Release 2.0

phrase includes a version number, that refers to the wallet
structure. The version number also serves as a checksum, and it
will prevent the import of seeds from incompatible wallets. Old
Electrum seeds are still supported.
and use a gap limit of 20.
P2SH addresses ("2 of 2", "2 of 3").
transactions, that includes the BIP32 master public key and
derivation needed to sign inputs. Serialized transactions can be
sent to cosigners or to cold storage using QR codes (using Andreas
Schildbach's base 43 idea).
"2 of 3" multisig wallets and Google Authenticator. Note that
wallets protected by this service can be deterministically restored
from seed, without Trustedcoin's server.
wallets, to send and receive partially signed transactions.
window that pops up if you click on the QR code
outputs, and raw hexadecimal scripts.
start the daemon if it is not already running, and the GUI will
connect to it. The daemon can serve several clients. It times out
if no client uses if for more than 5 minutes.
keys. A watching-only wallet is created by entering a list of
addresses in the wizard dialog.
wallet files cannot be read by older versions of Electrum. Old
wallet files will be converted to the new format; this operation
may take some time, because public keys will be derived for each
address of your wallet.
the command line:
stable. Another script was added to Android, called Authenticator,
that works completely offline: it reads an unsigned transaction
shown as QR code, signs it and shows the result as a QR code.
Version: GnuPG v1
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

New BIP32 structure for P2SH multisig wallets [BIP-45] | Jean-Pierre Rupp | Oct 03 2015

Jean-Pierre Rupp on Oct 03 2015:
I have been reviewing BIP-45 today. There is a privacy problem with it
that should at least be mentioned in the document.
When using the same extended public key for all multisig activity, and
dealing with different cosigners in separate multisig accounts, reuse of
the same set of public keys means that all cosigners from all accounts
will be able to monitor multisig activity from every other cosigner, in
every other account.
Besides privacy considerations, HD wallet's non-reuse of public keys
provide some defence against wallets that do not implement deterministic
signing, and use poor entropy for signature nonces.
Unless users are expected to establish a single cosigning account, this
scheme will result in reuse of public keys, and degradation of privacy.
I understand that for convenience it is useful to have a single extended
public key that can be handed to every cosigner. This makes setting up
accounts or recovering from data loss a easier.
I suggest that privacy & potential security degradation due to increased
public key reuse in the case of users with multiple multisig accounts
should get a mention in the BIP-45 document.
On 25/04/14 23:27, Manuel Araoz wrote:
Hi, I'm part of the team building copay
<>, a multisignature P2SH HD
wallet. We've been following the discussion regarding standardizing the
structure for branches both on this list and on github (1
<>, 2
<>, 3
<>, 4
<>, 5
<>). Soon, we realized the
assumptions in the discussions were not true for a multisig hd wallet,
so we wanted to share our current approach to that, to get feedback and
see if we can arrive to a new standard (and possibly a new BIP)
These are our assumptions:
use the P2SH address for that.
other parties. (Thus, all parties must be able to generate all public keys)
parties, of course.
Following BIP43, we're be using:
m / purpose' / *
where /purpose/ is the hardened derivation scheme based on the new BIP
We then define the following levels:
m / purpose' / cosigner_index / change / address_index
Each level has a special meaning detailed below:
/cosigner_index/ <>: the index of
the party creating this address. The indices can be determined
independently by lexicographically sorting the master public keys of
each cosigner.
/change/: 0 for change, 1 for receive address.
/address_index/: Addresses are numbered from index 0 in sequentially
increasing manner. We're currently syncing the max used index for each
branch between all parties when they connect, but we're open to
considering removing the index sync and doing the more elegant
used-address discovery via a gap limit, as discussed in BIP44
We feel 20 might be too low though.
Wallet high-level description:
Each party generates their own extended master keypair and shares the
extended purpose' public key with the others, which is stored encrypted.
Each party can generate any of the other's derived public keys, but only
his own private keys.
General address generation procedure:
When generating an address, each party can independently generate the N
needed public keys. They do this by deriving the public key in each of
the different trees, but using the same path. They can then generate the
multisig script and the corresponding p2sh address. In this way, each
path corresponds to an address, but the public keys for that address
come from different trees.
Receive address case:
Each cosigner generates addresses only on his own branch. One of the n
cosigners wants to receive a payment, and the others are offline. He
knows the last used index in his own branch, because only he generates
addresses there. Thus, he can generate the public keys for all of the
others using the next index, and calculate the needed script for the
/Example: /Cosigner #2 wants to receive a payment to the shared wallet.
His last used index on his own branch is 4. Then, the path for the next
receive address is m/$purpose/2/1/5. He uses this same path in all of
the cosigners trees to generate a public key for each one, and from that
he gets the new p2sh address.
Change address case:
Again, each cosigner generates addresses only on his own branch. One of
the n cosigners wants to create an outgoing payment, for which he'll
need a change address. He generates a new address using the same
procedure as above, but using a separate index to track the used change
Example: /Cosigner #5 wants to send a payment from the shared wallet,
for which he'll need a change address. His last used change index on his
own branch is 11. Then, the path for the next change address is
m/$purpose/5/0/12. He uses this same path in all of the cosigners trees
to generate a public key for each one, and from that he gets the new
p2sh address.
Transaction creation and signing:
When creating a transaction, first one of the parties creates a
Transaction Proposal. This is a transaction that spends some output
stored in any of the p2sh multisig addresses (corresponding to any of
the copayers' branches). This proposal is sent to the other parties, who
decide if they want to sign. If they approve the proposal, they can
generate their needed private key for that specific address (using the
same path that generated the public key in that address, but deriving
the private key instead), and sign it. Once the proposal reaches m
signatures, any cosigner can broadcast it to the network, becoming
final. The specifics of how this proposal is structured, and the
protocol to accept or reject it, belong to another BIP, in my opinion.
Final comments:
  • We're currently lexicographically sorting the public keys for each
address separately. We've read Mike Belshe's comments about sorting the
master public keys and then using the same order for all derived
addresses, but we couldn't think of any benefits of doing that (I mean,
the benefits of knowing whose public key is which).
  • We originally thought we would need a non-hardened version of purpose
for the path, because we needed every party to be able to generate all
the public keys of the others. With the proposed path, is it true that
the cosigners will be able to generate them, by knowing the extended
purpose public key for each copayer? (m/purpose')
  • The reason for using separate branches for each cosigner is we don't
want two of them generating the same address and receiving simultaneous
payments to it. The ideal case is that each address receives at most one
payment, requested by the corresponding cosigner.
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
Bitcoin-development mailing list
Bitcoin-development at
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Segwit integration

I've done some work to get segregated witness working for Joinmarket. Here's a summary of the status of that.
Some highlights of what we need to think about:
Transactions can have mixed segwit/non-segwit inputs and outputs, of course. But that raises:
The obvious issue is about different addresses as markers. The first maker bot to use P2SH addresses stands out and has a trivial marker on his outputs and inputs. And let's say all the makers use P2SH - now we have an even worse problem for takers that don't! The obvious solution is: if you're a taker, and you use P2SH (which could be segwit, or could also just be ordinary multisig) in your wallet, then you respond to swrelorder and swabsorder only; that way, all your inputs and outputs are P2SH. One tiny problem: Joinmarket doesn't yet support P2SH inputs! :)
So effectively, today, it becomes a partitioned joinmarket pit: segwit-enabled taker bots join with segwit-enabled maker bots, and the other non-segwit bots just ignore them. I think that works fine, and quite likely there would be a rapid migration, because segwit will be significantly cheaper. But, lots to think about before that :)
If you'd like to help test, you'll need sipa's segwit branch built and then grab some segnet coins, run my segwit branch of joinmarket above, and use the channel mentioned above on freenode.
Lastly, a note on timing: this is a way off! the PR of segwit into Core is apparently fairly imminent, but we are probably looking at some meaningful amount of time before this is available (and of course, it's not required)
This is just a first effort (although it has "cleared" the issue of the underlying bitcoin code). Thoughts welcome on how to proceed, help even more so.
submitted by waxwing to joinmarket [link] [comments]

Synala -- Feature Suggestions?

Hi everyone,
Well, since I'm upgrading Synala ( right away, whether I like it or not, I thought I'd open the floor for suggestions. For those who don't know, Synala is an excellent little open-source wallet you can install on your server, and easily accept payments from others (eg. clients, customers, etc.). Fully supports products, invoices, multiple BIP32 wallets, multisig, and more.
If wanted, full details and online demo at:
I've been using it myself for a couple years now since I first developed it, and it's a great little wallet. I use it for all my personal funds, and have never had a problem.
Just looking for any feature suggestions you'd like to see implemented, since I have to do an upgrade on it anyway due to Segwit. Obviously, it's a free, open-source system so I'm not going to go overkill, but happy to add some cool features. Here's a few I can personally think of:
1.) Obviously, replace the requirement of Bitcoin Core to built-in SPV node or similar. 2.) Coin management, so you can select which inputs to use for outgoing txs. 3.) Escrow support, so multiple parties can sign a tx separately on their own time.
Aside from that, not really sure. I don't want to bloat the functionality too much, and would prefer to keep it a "clean & mean" system. For example, I'm not going to add support for fiat payments and buy / sell coin features, as that's what the commercial packages are for.
If anyone has any suggestions though, please feel free to post them below. I'll see what I can add in. If anyone wants to help out on the project, please don't hesitate. :)
PS. If you're going to download Synala, please grab the archive from the Github page ( as there's a couple minor fixes (eg. high S-value error) that are fixed in Github, but not in the archives available on the Envrin site.
submitted by Envrin to Bitcoin [link] [comments]

Is there a greasemonkey script that can sign transactions?

That seems rather useful for bitcoin, especially when it comes to multisig. It could greatly simplify it, making multisignature transactions way user friendly and it would work just fine with NoScript installed. I am sure that such a tool would become an instant hit with the DarkNet Markets.
All the user would need to do is enter their BIP32 passphrase, and let the script make the transaction which would then be entered into the proper location on the site.
submitted by Vespco to Bitcoin [link] [comments]

Brainwallet idea: Please pick it apart and tell me why this won't work.

Premise: Brain wallets have a bunch of gotchas in that people are not as random as they think. But truly random brain wallets are not as easily remembered. I am looking for something easy to memorize and still very secure. My first thought is to add process to further obfuscate but I know that you can get too clever and actually introduce collisions that make the whole thing less secure. In any case, here is my idea for a brainwallet.
Description: The idea is to combine BIP32 and 3 of 3 multisig addresses. The user enters two strings. The first is the brainwallet phrase, the second is a password or PIN. The BIP32 masterKey is derived from the brainwallet phrase. The three public keys that are used to create the multisig address are derived from the masterKey. The way the ordinals are determined is that you get a HMAC-512 hash using the brain wallet phrase as the message and the passphrase as the key. Just take 9 digits from different parts of the hash and use those as the indexes for the derived keys. This is better explained with code. I am using pybitcointools:
import sys, os sys.path.append('pybitcointools') import bitcoin import hmac, hashlib bip32seed = raw_input('Your secret phrase: ').strip() pin = raw_input('Your passphrase (or PIN): ').strip() indexFrom = bitcoin.changebase(,bip32seed,hashlib.sha512).hexdigest(),16,10) // get hash and change it to decimal keyIndex = [int(indexFrom[:9]), int(indexFrom[9:18]), int(indexFrom[-9:])] masterKey = bitcoin.bip32_master_key(bip32seed) // each key is derived from the previous level1Priv = bitcoin.bip32_ckd(masterKey, keyIndex[0]) level2Priv = bitcoin.bip32_ckd(level1Priv, keyIndex[1]) level3Priv = bitcoin.bip32_ckd(level2Priv, keyIndex[2]) // get the public keys pubKey1 = bitcoin.privtopub(bitcoin.bip32_extract_key(level1Priv)) pubKey2 = bitcoin.privtopub(bitcoin.bip32_extract_key(level2Priv)) pubKey3 = bitcoin.privtopub(bitcoin.bip32_extract_key(level3Priv)) // make the 3 of 3 multisig address script = bitcoin.mk_multisig_script(pubKey1, pubKey2, pubKey3, 3, 3) myAddress = bitcoin.scriptaddr(script) 
My Conclusion: The reason brain wallets are attacked so effectively is because you are attacking a local copy of the blockchain and you are attacking all targets at once and not selecting a target. This process increases the surface area that must be attacked and requires additional processing time for each attack. The brain wallet phrase is what is typically attacked and just appending a passphrase increases entropy by itself. This process does not do that. Instead it uses BIP32 to spread the correct answer over an additional (109 * 109 * 109 = 1027) options. HMAC-512 is used to prescribe the random nature of the indexes. I would also assume that a 3 of 3 multisig address would be harder to break just as a matter of course.
Anyway, there it is. I would definitely appreciate any insight on why this scheme or schemes like this might be one of those things that erroneously makes you feel safe.
submitted by bitscavenger to Bitcoin [link] [comments]

BIP32 Index Randomisation | Matias Alejo Garcia | Mar 13 2015

Matias Alejo Garcia on Mar 13 2015:
Hello everyone,
We are working on bitcore-wallet-server (BWS), a HD multisig wallet
'facilitator'. We have a couple of questions regarding BIP32 path usage,
and we would love to have feedback from you before moving forward.
Currently the BWS instances hold the set of extended public keys of the
wallet's peers to be able to derive addresses.
Since this is a problem from the privacy point of view, we thought using
pseudo-random BIP32 paths, with a seed only known be the peers, so the
server will be able to verify that addresses submitted by peers belong to
the wallet, but will not be able to derive future wallet addresses.
The workflow would be something like:
Peer > getCurrentIndex
< Server [index]
pathSeed = PRNG(seed, index);
Peer > createAddress(index, pathSeed);
derives the address and add it to the wallet.
< Server new address
Peer: Verifies the address and inform it the user.
This way, accessing server data won't reveal future wallet addresses. The
seed (only known by the peers) could
be derived from hashes of their xprivs, so wallet funds can still be
recover with:
1) The complete set of xprivs
2) The quorum of xprivs + the complete set of xpubs + the address seed.
Thanks a lot in advance for any comment on this schema.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Future proof cold storage solution needed

I know this has been asked many times before and I've read many of those answers. I have been thinking about this for well over a year and I cant decide on the best solution ...
How do you future proof (15 - 20 years!) your bitcoin cold storage? Multiple decades without touching them!
And I'll preface this question with the following statement:
Making backups with a future-obsolete solution makes it a non-starter. I'm not impressed with "backup your backups" - I'm not looking for redundancy!
Solution #1: Paper wallet with QR code.
Problem: QR code scanning device may become obsolete and hard to obtain. Also data inside QR code may change (?) requiring old QR scanning software.
Solution #2: Hardware wallet, ie Trezor or USB drive
Problem: Shit happens. Hardware can break over time. If your only device holding coins is this hardware, you're screwed. Also, it may be the case where connector cables become incompatible with modern computers or in 20 years computers wont have any inputs (ie wireless all the things!)
Solution #3: Multi-sig that shit!
Problem: Whoa hold up there! How exactly am I storing the keys? QR codes on paper? Multiple hardware devices? Hold one or multiple keys with different 3rd party companies? Give one key to your parents for safe-keeping?
Does multi-sig only compound the problem of future proofing cold storage??
Solution #4: 12 words written on a piece of paper
BIP39 & BIP32 Hierarchical Deterministic Wallet allows for a list of 12 words to create a seed that can be used to generate deterministic wallets. The simplicity of human-readable words on a piece of paper not reliant on any other technology (such as qr scanners) and the future compatibility of BIPs make this one of the best solution I've found so far.
But ....
Solution #5: Write down the private key (Base58 Wallet Import Format) on a piece of paper
This may sound shockingly insecure, but I really think it could be the best future proof solution.
This solution relies on nothing more than being able to import a private key or sign a message offline and broadcast to the network.
I would love to read a discussion about this and how you'd go about future-proofing your bitcoin cold storage.
Specifically, if you agree with my assessment that writing down a single (non-multisig) private key is the best way to go:
  1. how would you store that paper?
  2. what instructions would you include for your future-self?
  3. could you include maths instructions to manually sign a transaction? (please show me how!!)
  4. what "failsafes" should you include in your package? ie an old computer pre-installed with x, y and z
submitted by bitpotluck to Bitcoin [link] [comments]

Some (or a lot) of ease of life suggestions

Hello! I am back again and after experimenting and tinkering with various different bitcoin wallets, I feel like GreenAddress has the most potential and I want to help, so here goes:
1) A fingerprint-free mode: This is something that electrum and carbonwallet does best for someone who's paranoid. What it does is that you don't have an "account" on the server, but rather your wallet are generated on the spot through your mnemonic, and in GreenWallet case, its your mnemonic + server BIP32 public key.
-> Pros: - In case the server gets hacked, the user's private information isn't exposed (especially if they linked their social media account).
-> Cons: - Lack of 2FA since 2FA is tied to an account. This can be circumvented by having the user input what they want to set as their 2FA whether it be email, SMS, or Google Authenticator, then whatever they put in becomes part of the mnemonic seed (kind of like the encrypted seed) during account setup, so in order to login and access the account they'd have to decrypt it with their 2FA first.
2) ..nLockTime, something that should be a useful safety net becomes something really cumbersome for an average bitcoin user by having to download and update their every time a transaction occurs, and it becomes a nightmare for bitcoin miners who receives periodic rewards everyday. I know you can ignore this feature but it clogs up your mail box and if you disable it, you can't recover funds if the server get hit with an asteroid.
Which brings me to the only reasonable solution: 2of3 multisig, ..dun dun DUNNNNNN! But rather than asking the user to save some long xpriv616Aw.... key, they can simply save an encrypted mnemonic version of it, then they could write it out on paper or remember it. And the best part is, the recovery process can be done through the same UI by simply prompting for the backup seed if they can't reach the server.
P.S. I know you already mentioned this feature is being worked on as part of subwallet but it couldn't come any sooner!
3) Longer PINs (say 4-12), can't see why not.
4) Sending to multiple addresses at once. (You can't even bypass this currently because the server forces you to wait for previous transaction to get confirmed before sending another).
5) Online storage integration like Google Drive and Dropbox. Instead of having GreenAddress sign our transaction, we could optionally encrypt and store it on a secure google drive and use it's API to sign transactions for full independence from GreenAddress, still be secured as an attacker would have to compromise both your computer and Google themselves. Just a thought.
P.S. I'll be back with more suggestions muwahahaha!
submitted by ZionHikari to greenaddress [link] [comments]

Выбор биткоин кошелька

После того как упал решил все свои накопления перевести в кошелек на своем компютере. На сайте есть несколько решений, но именно какой выбрать?
Bitcoin Core Bitcoin Core - это полноценный клиент, составляющий основу сети. Для него характерен высокий уровень безопасности, конфиденциальности и стабильности. Однако, у него меньше опций и он занимает довольно много места на диске и оперативной памяти.
mSIGNA mSIGNA - это продвинутый кошелек, который сочетает скорость, простоту и удобство с масштабируемостью уровня корпораций и отличной защищенностью. Он поддерживает BIP32, транзакции с несколькими подписями, оффлайн-хранение, синхронизацию нескольких устройств и зашифрованные онлайн и оффлайн бэкапы.
Bither Bither is a simple and secure wallet on many platforms. With special designed Cold/Hot modes, user can easily get both safety and simplicity. Bither's XRANDOM uses different entropy sources to generate true random number for users. Also with HDM, users can have HD's advantages and Multisig's security
MultiBit MultiBit - это легковесный клиент, главное преимущество которого - он быстр и прост в использовании. Синхронизация с сетью и подготовка к использованию происходит в течение нескольких минут.
Armory Armory это продвинутый биткойн-клиент, который расширяет функционал для продвинутых биткойн-пользователей. Он предлагает много функций по шифрованию и созданию резервных копий, а также позволяет использование безопасного оффлайн-хранения на отключенных от сети компьютерах.
Electrum Electrum быстр и прост в использовании и требует мало ресурсов. Использует удаленные сервера, которые обрабатывают наиболее сложные операции, позволяет вам восстановить кошелек с помощью пароля
BitGo BitGo - это кошелек с мульти-подписью и крайне высоким уровнем безопасности. Каждая транзакция требует двух подписей, что защищает ваши биткойны от вредоносных программ и серверных атак. Секретные ключи находятся у пользователя, так что BitGo не имеет доступа к вашим биткойнам. Это хороший выбор для нетехнических пользователей.
GreenAddress GreenAddress является удобным кошельком с мульти-подписью, улучшенной безопасностью и конфиденциальностью. Ваши ключи не передаются на сервера, даже в зашифрованном виде. По соображениям безопасности, вы всегда должны использовать 2-факторную авторизацию и расширение для браузера или Android приложение.
Кто каким пользуеться? Может были замечены баги траблы? Я пока качаю биткоин кор, еще 30 недель осталось. И еще вопрос, как мне перевести свой валет в офлайн? Ну вопросы буду задавать по мере их поступления Wink
submitted by privatedicks to BitRussia [link] [comments]

Huge update, too many changes too list!

Hi all,
The Marketplace has recently released a slew of updates targeted at decreasing the learning curve for new users. We feel that Multi Sig is an important tool and it is up to providers like The Marketplace, not customers, to make this transition bearable and to keep innovating.
Our recent break has given us a new passion for TMP and we have listened to our users concerns. We know that many users have wished to try The Marketplace but have been scared that their funds may be lost due to the complexity of multi sig and we feel that our continued innovations have made this now impossible.

For customers:

A large complaint from users is recording transaction ids.

Automatic transaction recording

We have now implemented an internal transaction recorder which automatically detects new transactions and records the transaction details. To pay for your order, you are now simply required to send funds to your multisig escrow address and your order page will instantly update to let you know the transaction was recorded when your payment is received, no need to click buttons or reload the page. It's almost easier than a traditional centralized marketplace with all the benefits of provable multi sig security to boot!

Updated UI & improved vendor search

Our new UI is also cleaner and easier to navigate, with fully responsive design that works even for small screen sizes. We have implemented changes to our search to recognize common variations of a vendors name so users searching for a specific vendor will be sent to their shop immediately.

For vendors:

A key concern for vendors is loss of their private keys or transactions going unredeemed when The Marketplace is seized.

Wallet Management

To alleviate one of these concerns, we have implemented BIP32 and Electrum Deterministic address generation using Master Public Keys. Vendors must now only record a single master public key and The Marketplace will automatically generate a new deterministic address for every transaction, this removes the complexity of vendors wallet management which many vendors have complained about.

Time locked transactions

Another key concern is the ability to redeem transactions should The Marketplace be seized. Many vendors worry about their ability to redeem transactions because they cannot reach customers or private keys are lost. We have now released the first ever (clearnet & darknet) Time locked transaction implementation (see Time locked transactions are specially crafted transactions which are not valid till a specific date or block.
This feature of the Bitcoin Protocol allows The Marketplace to provide verified vendors with a special transaction when they ship orders which is not valid for 2 months (sequence 0). This allows the vendor to know that upon shipping a product, they will be able to claim their payments if The Marketplace is seized in that time, albeit some months later. By utilizing the Bitcoin protocol, we are removing the need to trust third parties to help claim payments in the future and makes us the first marketplace to provide provable dead man switches in preparation for any seizure attempts.
Many users will say that The Marketplace is one of the hardest to use marketplaces and will thus stay away, we have listened to all their concerns and feedback and we think it's now one of the easiest!
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - iQIcBAEBCgAGBQJTyQV6AAoJEDke4vmlZMwqbMkP+wb56iiAfESZbInfGg4cLnBG /zS84SQZ7kK2XrjeLRB90PjISv01WpOrIsDpI6jwSd7RWZ/uipSi73xWA4jHm/bR dRcDKcAmoip4uup2DlBwW+AkwiBpzYHO2HW5BzbpzAPUqluh6AM0gRzhWmJjrA k/tsMEeHBiP2mPOQqh6x6cPc69siqPfctRMoZJgBLp3pnYGWLBccfeELfo1n8kKi av0X6tesfdvFTQRr5hS+Cd9kJyvOwtCxOb1rSuewk/MWV86ezieqWgG7exP+bLFu yfEAT2iKmFeWLowTC50TxZ5E46PIg1lfESkyLYgUbzx1L9/0BjdF5T+gwBVHGPRg P8FSF29VKho2HnTeYwstVDaUM/ujihSFbMcojpF6olLu/vrTgIkeLqEAOYSHENGc VDaXsACinq/WvPBdj6xv/Fz/Dbug3cRbeeqzowCzi4uOCR+DRZkEFbbu1Ij+y+ZX aoIvsQ3SL1johjcktGbD2XeHlGpql2iDkt2277MShcLAlm21LFRJkIexYGA5RH8Z p3pmJmS263usnJRlNObym8OEUCApEndQ5LNzeyG72+u69PZxGhaJYW0FaRzAx9pG PesWQrGK0lGQnZOt6Y7GG6zH5D/G3NTP9hI4FuyGWnahBU7/Xj6NXumu7FKyNOGE ar0O+Lml40XZXeKtey9W =SiuJ -----END PGP SIGNATURE----- 
Source: http://43y5mwjvhxd6zf7v.onion/forum/index.php?topic=971.msg5623#new
submitted by TMPSchultz to themarketplace [link] [comments]

Question about multisig (P2SH)

Last time I submitted a post about moving funds to a cold storage multisig wallet using and I was met with people claiming that its not safe, as P2SH is still in alpha and might change in the future.
If P2SH is dropped from bitcoin core wouldn't that create a huge loss in confidence as then there would be people with multisig holdings that couldn't access their funds. Am I not correct in assuming that P2SH will now be here forever, and creating a multisig wallet along with saving the private keys and redemption script will allow me access to those funds at any point in the future? Even if and disapear i'm sure there will be similar tools available to take my private keys and redemption script and create the necessary raw transaction data to sign and propagate to the bitcoin network.
Any informed advice would be highly appreciated.
submitted by slvbtc to Bitcoin [link] [comments]

bitWallet for iOS has been updated to v1.3 to include a Night theme. PushTx workaround remains intact. No jailbreak required.

Three screenshots
A dark theme was one of my original feature requests, so it's cool to see it implemented. I think it looks pretty stylish.
My big feature request is for bitWallet to become hierarchally deterministic (BIP32). I'm not satisfied with relying on iTunes backups, and since bitWallet is not deterministic, there's no good way to back up my private keys. At first I was importing private keys from paper wallets so I would at least have an offline copy, but I've taken it a step further to make it kind of deterministic. All I've done is created a new Electrum wallet (and seed) on my desktop machine, and imported 5-10 of the private keys into a fresh bitWallet. I will simply use those addresses instead of any generated by bitWallet, because I know that I can retrieve the keys easily from my desktop if necessary. This should make transaction management and record keeping much easier as well, since I can just export an Electrum .csv like I normally do.
Please remember that no mobile or web wallet is a suitable substitution for proper cold storage. They should generally be used for daily spending, and not for storing hundreds or thousands of dollars!
For anyone curious how long this bitcoin wallet will be available on the App Store, that's anybody's guess. I have placed a friendly bet with fellow user Introshine, who predicted Apple would pull bitWallet or force the removal of the pushtx workaround within three months (August 25th). For shits and giggles, we decided to place a friendly wager of 0.01 BTC using a multisig address via Bitrated. If that 0.01 BTC increases in value to $100, I'm perfectly okay with that whether I win or lose. ;)
Here's a screenshot of our agreement.
submitted by BashCo to Bitcoin [link] [comments]

Bitcoin Key Management Techniques SF Bitcoin Devs Seminar: The BitGO API: A deep dive into Advanced Multisig! Ethereum Wallet Parity Hit by Second Critical Vulnerability $150+ Million Frozen - Bitcoin News Blockchain - Use cases MultiSignature Wallets a brief intro Blockchain Receive Payments API v2 HD BIP32 xpub

Bitcoin Core ist ein Bitcoin-Client, der wie Peer-to-Peer funktioniert. Diese Software ist völlig von Dritten unabhängig. Sie nimmt gesamte Blockchain, mit der sie dann arbeitet. Es ist also nicht notwendig (im Vergleich zu anderen Klienten), mit dem Server verbunden zu werden, wo Blockchain durchgehen sollte. Sie ist daher sehr widerstandsfähig gegen Serverfälschung In this tutorial, we are going to create a 2 of 2 multisig wallet for bitcoin cash (BCH) storage using the Electron Cash wallet. ... key is part of the BIP32 address standard, which gives a user ... BIP32 implementation library Electrum implementation library Bitcoin key processing library Raw transaction crafting library for CodeIgniter . Examples. There is. a script with sample usage of the bitcoin library. a script with sample usage of the electrum library. a script with sample usage of the BIP32 library. a script demoing BIP32 key derivation for multisig. Licence. This is free and ... OK, ich habe es mit pybitcointools zum Laufen gebracht.. Der Befehl bip32_hdm_script, wie man schließen kann, ein Hex des P2SH-Redeemscript unter Verwendung der angegebenen öffentlichen / privaten BIP32-Hauptschlüssel zurück (was sich nicht von der Verwendung von mk_multisig_script(pubkey1 pubkey2 pubkey3 2) für ein 2-aus-3-P2SH unterscheidet). ). Ebenso gibt bip32_hdm_addr die P2SH ... Today we are happy to announce that we have successfully broadcast the first BIP32 P2SH multisig transaction using Copay. It can be viewed on Insight here.(Technical jargon "BIP32" and "P2SH" will be explained in future blog posts.) Copay is not the only multisig wallet in development. We fully support all efforts to improve the security of bitcoin, including BitGo, CryptoCorp, and ...

[index] [14320] [22269] [25115] [2180] [44305] [40301] [35879] [30875] [2443] [39194]

Bitcoin Key Management Techniques

Ethereum Wallet Parity Hit by Second Critical Vulnerability $150+ Million Frozen Makers of the Parity multi-sig Ethereum wallet have announced a critical vulnerability that has led to millions of ... Slides: Ben Chan from BitGo discusses P2SH and the concepts behind many different multi-sig models that a... Blockchain tutorial 29: Hierarchical Deterministic wallet - BIP32 and BIP44 - Duration: 25 ... DIY Multisig with Your Bitcoin Node & XAMPP - Duration: 14:32. m1xolyd1an 729 views. 14:32 . How does ... Demonstration of creating a new key for a multisig account without sharing that secret key with us. I used to make the key, and Brainwallet to sign the verification message. This video is unavailable. Watch Queue Queue. Watch Queue Queue