Deterministic wallet tools - Bitcoin Wiki

Have you exceeded your Gap Limit?

What the hell!? Just got my first cold card so I am learning tons of new shit.
We are strongly encouraged to use a new receive address every time. But how does one not run afoul of the dreaded “gap limit?”
Simple. Don’t let multiple sources derive wallet addresses. If you have watch-only wallets, they could be deriving addresses beyond the gap limit from the “HOME” wallet. This could lead to addresses bearing btc not being detected when using the home wallet, and from what I am reading, access to those addresses could get very difficult.
So should we actually encourage using the same address over and over again, to be sure we aren’t getting screwed up by the gap limit? Better to reuse an address than generate an address from a non-home wallet.
Similar to the Gap limit, in the realm of generating receive addresses: ColdCard even has concerns about strange or custom derivation of new addresses by other wallets. This goes a step further from the gap limit in potentially complicating your future bitcoin access. Because your main wallet may not recognize the derivation pattern of those addresses and you won’t have access. Main point: use the same wallet to derive/verify receive addresses that will be ultimately doing outgoing transactions.
Correct me if i am wrong in the comments, thanks.
Cold Card website citation:
Although the subkey derivation will be correct, and we have researched the BIP32 derivation paths in use by these popular systems, we make no guarantees about what they are using at present, and some are configurable.
Do not make deposits to these payment addresses without confirming they match the wallet in question, and in general, please only use addresses produced by the wallet which will be responsible for tracking the UTXO on the blockchain. These can be verified using the "Address Explorer", found on the Advanced menu.
LEDGER website citation:
Address gap limit The address gap limit refers to the standard number of public addresses that are checked for transactions in the blockchain in order to calculate an account's balance. Transactions received on an address beyond the address gap limit are not detected. This can only happen when using an external wallet to derive addresses.”
Address gap limit example
If you receive a transaction on the first address, address 1, Ledger Live will scan addresses 2 to 21 for any additional transaction history. If nothing is found, it will stop looking. If address 22 has received, Ledger Live will not see it because it stopped at address 21.
submitted by dreftylefty to Bitcoin [link] [comments]

Bottos 2020 Research and Development Scheme

Bottos 2020 Research and Development Scheme
As 2020 is now here, Bottos has solemnly released its “2020 Research and development scheme”. On one hand, we adhere to the principle of transparency so that the whole community can comprehend our next step as a whole, but more importantly, it also helps our whole team to think deeply about the future and reach consensus. It is strongly believed that following these consistent follow-ups will help us to in order to achieve the best results.
Based on the efficient development of Bottos, the team’s technical achievements in consensus algorithms and smart contracts are used to deeply implement and optimize the existing technical architecture. At the same time using the community’s technical capabilities, horizontal development, expanding new functional modules and technical directions it stays closely integrated with the whole community.
In the future, we will keep on striving to achieve in-depth thinking, comprehensive planning, and flexible adjustment.

Overview of Technical Routes
User feedback within the community is the driving force behind Bottos progress. In the development route of the community and industry we have formulated a roadmap for technical development, pointing out the right path for the team towards the right direction among the massive routes of modern technology.
As part of our 2020 research and development objective we have the following arrangements:
1. Intensifying enormous number of smart contracts and related infrastructures
After many years of development, smart contracts have gradually become the core and standard function in blockchain projects. The strength of smart contracts, ease of use, and stability represent the key capabilities of a blockchain project. As a good start, Bottos has already made great progress in the field of smart contracts. In smart contracts we still need to increase development efforts, making the ease of use and stability of smart contracts the top priority of our future development.
Reducing the barriers for developers and ordinary users to use, shortening the contract development cycle and saving users time is another important task for the team to accomplish. To this end, we have planned an efficient and easy-to-use one-stop contract development, debugging, and deployment tool that will provide multiple access methods and interfaces to the test network to support rapid deployment and rapid debugging.
2. Establishing an excellent client and user portal
The main goal here is to add an entrance point to the creation and deployment of smart contracts in the wallet client. To this end, the wallet needs to be transformed, a local compiler for smart contracts must be added, and an easy-to-use UI interface can be provided for the purpose of creating, deploying, and managing contracts to meet the needs of users with a single mouse click only.
3. Expanding distributed storage
Distributed storage is another focus of our development in the upcoming year. Only by using a distributed architecture can completely solve the issue of performance and scalability of stand-alone storage. Distributed storage suitable for blockchain needs to provide no less than single machine performance, extremely high availability, no single point of failure, easy expansion, and strong consistent transactions. These are the main key points and difficulties of Bottos in field of distributed storage in the upcoming days.
4. Reinforcing multi party secured computing
Privacy in computing is also a very important branch to deal with. In this research direction, Bottos has invested a lot of time and produced many research results on multi-party secured computing, such as technical articles and test cases. In the future, we will continue to give efforts in the direction of multi-party secured computing and apply mature technology achievements into the functions of the chain.

2020 Bottos — Product Development

Support for smart contract deployment in wallets
The built-in smart contract compiler inside the wallet supports compilation of the smart contracts in all languages provided by Bottos and integrates with the functions in the wallet. It also supports one-click deployment of the compiled contract source code in the wallet.
When compiling a contract, one can choose whether to pre-execute the contract code. If pre-execution is selected, it will connect to the remote contract pre-execution service and return the execution result to the wallet.
When deploying a contract, one can choose to deploy to the test network or main network and the corresponding account and private key of the test network or main network should be provided.

2020 Bottos-Technical Research
1. Intelligent smart contract development platform (BISDP)
The smart contract development platform BISDP is mainly composed of user-oriented interfaces, as well as back-end compilation and deployment tools, debugging tools, and pre-execution frameworks.
The user-oriented interface provides access methods based on WEB, PC, and mobile apps, allowing developers to quickly and easily compile and deploy contracts and provide contract template management functions. It can also manage the contract remotely by viewing the contract execution status, the consumed resources and other information.
In the compilation and deployment tool a set of smart contract source code editing, running, debugging, and deployment solutions as well as smart contract templates for common tasks are provided, which greatly reduces the threshold for developers to learn and use smart contracts. At the same time, developers and ordinary users are provided with a smart contract pre-execution framework, which can check the logical defects and security risks in smart contracts before actual deployment and promptly remind users a series of problems even before the smart contracts are actually run.
In the debugging tool, there are built-in local debugging and remote debugging tools. Multiple breakpoints can be set in the debugging tool. When the code reaches the breakpoint, one can view the variables and their contents in the current execution stack. One can also make conditional breakpoints based on the value of the variable. The code will not execute until the value reaches a preset value in memory.
In the pre-execution framework, developers can choose to pre-execute contract code in a virtual environment or a test net, checking out problems in some code that cannot be detected during compilation time and perform deeper code inspection. The pre-execution framework can also prompt the user in advance about the time and space resources required for execution.
2. Supporting Python and PHP in BVM virtual machine for writing smart contracts
We have added smart contract writing tools based on Python and PHP languages. These languages can be compiled into the corresponding BVM instruction set for implementation. These two reasons are used as the programming language for smart contracts.
For the Python language, the basic language elements supported by the first phase are:
- Logic control: If, Else, Eli, While, Break, method calls, for x in y
- Arithmetic and relational operators: ADD, SUB, MUL, DIV, ABS, LSHIFT, RSHIFT, AND, OR, XOR, MODULE, INVERT, GT, GTE, LT, LTE, EQ, NOTEQ
Data structure:
- Supports creation, addition, deletion, replacement, and calculation of length of list data structure
- Supports creation, append, delete, replace, and calculation of length of dict data structure
Function: Supports function definition and function calls
For the PHP language, the basic language elements supported by the first phase are :
- Logic control: If, Else, Eli, While, Break, method calls
- Arithmetic and relational operators: ADD, SUB, MUL, DIV, ABS, LSHIFT, RSHIFT, AND, OR, XOR, MODULE, INVERT, GT, GTE, LT, LTE, EQ, NOTEQ
Data structure:
- Support for creating, appending, deleting, replacing, and calculating length of associative arrays
Function: Supports the definition and calling of functions
For these two above mentioned languages, the syntax highlighting and code hinting functions are also provided in BISDP, which is very convenient for developers to debug any errors.
3. Continuous exploration of distributed storage solutions
Distributed storage in blockchain technology actually refers to a distributed database. Compared with the traditional DMBS, in addition to the ACID characteristics of the traditional DBMS, the distributed database also provides the high availability and horizontal expansion of the distributed system. The CAP principle of distributed system reveals that for a common distributed system there is an impossible triangle, only two of them can be selected among its three directions, consistency, availability, and partition fault tolerance. Distributed databases in China must require strong consistency. This is due to the characteristics of the blockchain system itself, because it needs to provide reliable distributed transaction capabilities. For these technical issues, before ensuring that the distributed storage solution reaches 100% availability, we will continue to invest more time and technical strength, do more functional and performance testing, and conduct targeted tests for distributed storage systems.
4. Boosting secured multi-party computing research and development
Secured multi-party Computing (MPC) is a cryptographic mechanism that enables multiple entities to share data while protecting the confidentiality of the data without exposing the secret encryption key. Its performance indicators, such as security and reliability are important for the realization of the blockchain. The transparent sharing of the data privacy on the distributed ledger and the privacy protection of the client wallet’s private key are truly essential.
At present, the research and development status of the platform provided by Bottos in terms of privacy-enhanced secured multi-party computing is based on the BIP32 / 44 standard in Bitcoin wallets to implement distributed management of client wallet keys and privacy protection.
Considering the higher level of data security and the distributed blockchain account as the public data of each node, further research and development are being planned on:
(1) Based on RSA, Pailliar, ECDSA and other public key cryptosystems with homomorphic attributes, as well as the GC protocol, OT protocol, and ZKP protocol to generate and verify transaction signatures between two parties;
(2) Introduce the international mainstream public key system with higher security and performance, national secret public key encryption system, and fewer or non-interactive ZKP protocols to achieve secured multi-party computing with more than two parties, allowing more nodes to participate Privacy protection of ledger data.


After years of exploration, we are now full of confidence in our current research and development direction. We are totally determined to move forward by continuous hard work. In the end, all members of Bottos also want to thank all the friends in the community for their continuous support and outstanding contributions. Your certainty is our greatest comfort and strongest motivation.

Be smart. Be data-driven. Be Bottos.
If you aren’t already in our group, please join now!
Join Our Community and Stay Updated!
Bottos Website | Twitter |Facebook | Telegram | Reddit
submitted by BOTTOS_AI to Bottos [link] [comments]

What risks do a stolen private key mean to the rest of a BIP39 Ethereum keychain?

Update: I found the resources to this from 4 years ago, linked them below. The vulnerability is that if an attacker knows one of the child private keys and the master public key, they can calculate the master private key easily and thus get access to all the addresses in the key chain. This applies to key chains created with the version of Electrum at the time and all BIP32 key chains. Not sure if it still applies to Electrum -- u/ghost43_ ? -- but most tools I know have long transitioned to BIP44.
Bitcoin magazine article (fun fact: written by none other than Vitalik, who publicized this before anyone else)
Bitcointalk thread
Bitcoin post
*Obviously BIP32, not 39. Sorry.
Assume a properly seeded BIP32 key chain of Ethereum keys. The private key belonging to one (only one) of the Ethereum addresses becomes compromised by an attacker.
Scenario A: the attacker doesn't know anything else.
Scenario B: the attacker knows some of the other addresses (but only the addresses).
In each scenario, how endangered is the master private key or other private keys in the key chain?
A long time ago there was a discussion about this in Bitcoin, and the take-away was (if my memory is not too foggy) that the leaking of one private key makes it easier to guess the master private key. I wonder if this is the case for Ethereum BIP32 key chains as well.
submitted by PolarOne to ethereum [link] [comments]

I made an app to charge with bitcoin aimed to merchants (specially Venezuelans)

I made an app to charge your clients or friends with Bitcoin. That means, you type the amount you want to charge in fiat, choose a destination wallet, and the app give you a Bitcoin payment link that you can show to your clients with a QR code, copy to the clipboard or share with other apps.
The app does not handle your private keys, so it’s ideal to use with your employees' own devices or with a store shared computer. You add wallets to the app with their public addresses.
Other things that you can do:
Why it is aimed specially to Venezuelans?
The app is aimed to any merchant, but could be interesting for Venezuelans because of the Bolivar / Bitcoin exchange rates. Most apps out there use the official VEF/USD exchange rate and then convert to Bitcoin. That would mean huge loses for the seller, given that the official rate differs in several orders of magnitude from any market-based rate. But my app uses the exchange rates given by Bitcoin Venezuela’s API (, a web that estimate the exchange rates from market prices at Local Bitcoins (
The app is localized in English and Spanish (named “Pay me with Bitcoin” and “Págame con Bitcoin” respectively).
Available in…
Google Play and the Microsoft Store (for Windows 10 desktop mobile). I developed the app with Xamarin Forms with iOS in mind, so it should be trivial to port to iOS, but I cannot afford the Apple Store fee and I don’t have access to a Mac at the moment.
If there is any interest in the app, I would like to:
Either support Coinbase Commerce or implement Bip32 myself, so every ticket (charge) that you generate with the app go to a different wallet, derived from a master public key. In this way you client won’t know how much money you make / have, and you would get confirmations for every ticket, avoiding confusions.
The app should also use notifications for when a payment is received.
And of course, iOS.
Download links:
Windows 10 desktop/mobile
submitted by SalvadorJesus to Bitcoin [link] [comments]

Mycelium Bitcoin Wallet 2.0 (HD) is out!!!

Mycelium 2.0 HD - Welcome to the future
Address reuse is not for me So I am waiting for HD For even greater satisfaction I want to label my transaction And then there is a third temptation Cold spend with zero confirmation That's why I beg you, please: Release! -- Jan Dreske (Mycelium Developer anxious to get this thing out to the public, who's birthday is today) 
Over the summer the Mycelium dev team has been working hard to make Mycelium 2.0 a reality. Our 200+ beta testers have given us great feedback and today, our biggest and most significant wallet update has finally been released for everyone.
Direct download: On Google Play we use staged rollout, where it is released gradually over the next few days:
New Features:
What does HD mean?
HD is short for Hierarchical Deterministic. Typically, bitcoin wallets generate each new bitcoin address from a unique random number, requiring a separate backup of each new address. To avoid losses from lack of backups, such wallets use a single bitcoin address for all your transactions. HD wallets instead use a “master seed” (a single large random number), to derive all future bitcoin addresses sequentially from that single seed. This means that you only need to make a backup once, and all the keys generated by an HD wallet can be restored at any time in the future just from that single master seed. HD wallets greatly improve your privacy by being able to keep generating new addresses. If you use the same address continuously all your transactions will be associated with a single address, and because all bitcoin transactions are public anyone can see what addresses you are sending funds to, and calculate your total balance. With an HD account new addresses are created whenever you send and receive funds, making your transaction activity and total balance very hard to track.
But I liked it the way it was! Will I have to change the way I use it?
All your keys, addresses and address book entries will be retained when you upgrade your app. The tab previously named “Keys” has been renamed to “Accounts.” Your old bitcoin addresses will become single address accounts, and you can continue to use them as before. We do advise that you switch to new HD accounts, though. You will also see your first empty HD account, which you can start using right away.
What about previous backups? Do my old ones still work?
Yes. You can still import keys and addresses you backed up with the previous version of Mycelium Wallet. However, we have removed the ability to create backups of single keys, or create new single addresses accounts. Instead, we advise you to backup your master seed and move your funds to the new HD wallet. As long as you keep your old backups, though, you will be able to recover your legacy accounts using Mycelium. To import a private key, switch to the “Accounts” tab, tap the icon with a key and plus symbol in the upper right corner, and select “Advanced”. Then scan your encrypted private key and enter the password.
Will I be able to continue to use my current Local Trader identity?
Yes. Your Local Trader identity will get carried over to the new version when upgrading along with your private keys.
How do I make a backup?
To create a backup, either tap the “Secure My Funds” button on the main page, or choose “backup” from the menu. You will be shown a list of words, one after the other. Write those words down with pen & paper. You then have to type in the words again, to make sure you got everything right. Store this word list in a safe place! Anybody who obtains this list can access current and future funds in your wallet! Note: The backup procedure only backs up your HD accounts. Your classic single address accounts are not part of this backup procedure.
How do I restore a backup?
If your phone is lost or damaged you can make a fresh install of the mycelium wallet on a different device. Upon startup, choose “Restore Backup”. Choose 12 as the length of your word list, and let the “password” checkbox unchecked, and proceed to enter your word list. This recreates your master seed and automatically creates and synchronizes your first HD account. It might take some time until your first account is synchronized and the balance updates. If you had more than one account, navigate to the “Accounts” tab, tap the button with a key icon and plus on the upper right corner, and choose “Add HD Account” to re-create your second account, etc. Note: This procedure only restores your HD accounts. To restore your classic accounts you have to manually import each key/address by going to the Accounts tab, click the + button, select Advanced, and then Import. If your previous Mycelium installation had a Local Trader account you can recreate your trader account and data by clicking “Buy/Sell Bitcoins”, select the “My Info” tab, click “Create” and select the account that your local trader identity was associated with.
Can I restore a BIP44 wallet created with other software?
Yes. When you start a fresh install of the app you get the option to restore a backup. You can choose between word lists lengths of 12, 18, or 24 words, and also supply an optional password in accordance with BIP39. This way you can restore all HD accounts generated by other wallets compatible with BIP44 and BIP39. For instance, this allows you to import your TREZOR word list in case your device was lost or damaged so you can quickly move your funds to safety.
submitted by Rassah to Bitcoin [link] [comments]

Groestlcoin Christmas Release!

Groestlcoin Dec 2018 Christmas Release Update

As per usual the 3 months has been all hand-on-deck, helping to bring further adoption utilities to Groestlcoin. The markets have been red but as always that doesn't stop the show from going on with regards to the development since the last release update on 24th September. Here's a recap of what has happened so far:


What’s New Today?

Groestlcoin on Trezor Model T

As of the latest version of the Trezor Model T firmware, Groestlcoin is now officially supported! The Trezor Model T is the next-generation cryptocurrency hardware wallet, designed to be your universal vault for all of your digital assets. Store and encrypt your coins, passwords and other digital keys with confidence. The Trezor Model T now supports over 500 cryptocurrencies.

Blockbook MainNet & TestNet Block Explorer

Blockbook is an open-source Groestlcoin blockchain explorer with complete REST and websocket APIs that can be used for writing web wallets and other apps that need more advanced blockchain queries than provided by groestlcoind RPC.
Blockbook REST API provides you with a convenient, powerful and simple way to read data from the groestlcoin network and with it, build your own services.


Blockbook is available via Testnet: Source code:

Edge Wallet

Groestlcoin has been added to the Edge wallet for Android and iOS. Edge wallet is secure, private and intuitive. By including support for ShapeShift, Simplex and Changelly, Edge allows you to seamlessly shift between digital currencies, anywhere with an internet connection.


Direct Android:

CoinID Wallet

We are excited to announce that Groestlcoin has been added to CoinID! With integrated cold and hot wallet support, and a host of other unique wallet features, CoinID can easily become your go-to wallet for storing Groestlcoin. More details can be found here:



Groestlcoin Sentinel - Windows Released

Groestlcoin Sentinel is the easiest and fastest way to track balances of your Groestlcoin addresses.
You can download it using the links below.
Download the Windows Wallet (64 bit) here:
Download the Windows Wallet (32 bit) here:
Source code:

Groestlcoin BIP39 Tool 0.3.9 Update

The Groestlcoin BIP39 tool is an open-source web tool for converting BIP39 mnemonic codes to addresses and private keys. This enables the greatest security against third-party wallets potentially disappearing – You’ll still have access to your funds thanks to this tool.
What’s New
Download the Groestlcoin BIP39 tool here:
Source code:
Or use hosted version:

Electrum-GRS 3.2.3 Update

Electrum-GRS is a lightweight "thin client" Groestlcoin wallet Windows, MacOS and Linux based on a client-server protocol. Its main advantages over the original Groestlcoin client include support for multi-signature wallets and not requiring the download of the entire block chain.
What’s New

Electrum + Android Version 3.2.3:

Windows & OSX:
sudo apt-get install python3-setuptools python3-pyqt5 python3-pip python3-dev libssl-dev sudo pip3 install groestlcoin_hash sudo pip3 install electrum-grs
GitHub Source server:
Github Source server installer:
Github Source client:

Groestlcoin ivendPay Integration

ivendPay and Groestlcoin cryptocurrency have announced the start of integration.
IT company ivendPay, the developer of a universal multicurrency payment module for automatic and retail trade, intends to integrate Groestlcoin cryptocurrency — one of the oldest and the most reputable Bitcoin forks into the payment system. Groestlcoin is characterized by instant transactions with almost zero commission and is optimal for mass retail trade where micropayments are mostly used.
According to Sergey Danilov, founder and CEO of ivendPay, Groestlcoin will become the 11th cryptocurrency integrated into the payment module. The first working vending machines for the sale of coffee, snacks and souvenirs, equipped with ivendPay modules, served the visitors of the CryptoEvent RIW exhibition at VDNKh in Moscow and accepted Bitcoin, Go Byte, Dash, Bitcoin Cash, Ethereum, Ethereum Classic, Zcash, Bitcoin Gold, Dogecoin and Emercoin. ivendPay terminals are designed and patented to accept payments in electronic money, cryptocurrencies and cash when connecting the corresponding cash terminal. Payment for the purchase takes a few seconds, the choice of the payment currency occurs at the time of placing the order on the screen, the payment is made by QR-code through the cryptocurrency wallet on the smartphone.
The interest in equipping vending machines with ivendPay terminals has already been shown by the companies of Malaysia and Israel, where first test networks would be installed. ivendPay compiles a waiting list for vending networks interested in buying terminals and searches for an investor to launch industrial production. According to Sergey Danilov, the universal payment terminal ivendPay for the vending machine will cost about $500. The founder of ivendPay has welcomed the appearance of Groestlcoin among integrated cryptocurrencies, as it is another step towards the realization of the basic idea of digital money - free and cross-border access to goods and services for everybody.
submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

BIP 32/39/44 Seed Portability?

This article - Why do my BIP32 wallets disagree? is a bit disconcerting.
Results below provide evidence by example that Trezor and libbitcoin's bitcoin-explorer (bx) command line interface have seed portability.
I thought I would try using the bitcoin-explorer (bx) command to see results generated to contrast to the article for m/44'/60'/0'/0/0.
% echo "radar blur cabbage chef fix engine embark joy scheme fiction master release" | bx mnemonic-to-seed | bx hd-new -v 76066276 | bx hd-private -d -i 44 | bx hd-private -d -i 60 | bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec
*For an uncompressed public key:*
% echo b96e9ccb774cc33213cbcb2c69d3cdae17b0fe4888a1ccd343cbd1a17fd98b18 | bx ec-to-public -u
After dropping the leading 0x04 from the uncompressed public key, a keccak hash function (used by both Ethereum and Monero; is not NIST's SHA3-256) is applied.
% ./keccak -256 05b7d0996e99c4a49e6c3b83288f4740d53662839eab1d97d14660696944b8bbe24fabdd03888410ace3fa4c5a809e398f036f7b99d04f82a012dca95701d103 0AB3387A148B3C4B18C333FCAC39B311DCEB2A4B2F5D8461C1CDAF756F4F7AE9
The bolded 20 byte Ethereum address immediately above matches the "Otherwise" result in the article up top.
*For a compressed public key:*
% echo b96e9ccb774cc33213cbcb2c69d3cdae17b0fe4888a1ccd343cbd1a17fd98b18 | bx ec-to-public
After dropping the leading 0x03 from the compressed public key,
% ./keccak -256 05b7d0996e99c4a49e6c3b83288f4740d53662839eab1d97d14660696944b8bb 1BE3816C914DCFF6C350BBFB1AEC8694FC4F546191026031FEFFB312D342B93B
For grins, I decided to generate a comparable situation for Trezor using its web interface. I used the Trezor (with firmware v1.3.6 and v1.4) recovery instructions for the pertinent 12 word recovery seed, "radar blur cabbage chef fix engine embark joy scheme fiction master release", to see what the results are for an extended M/44'/0'/0'/0 xpub key to contrast to bx calculations. The resulting xpub key resulting from two restores is:
% echo "radar blur cabbage chef fix engine embark joy scheme fiction master release" | bx mnemonic-to-seed | bx hd-new -v 76066276 | bx hd-private -d -i 44 | bx hd-private -d -i 0 | bx hd-public -d -i 0 xpub6DHi64TFkDPx2AH4q2ku3vX9LJYNpTis5tLrET8Sb9irp174eCkgtAnvBpyzQXgrtmF31Lrq4gTMGFUGcjJicMu9LdueVdqt6FZ2Wzcg8Fj
Seed word results from Trezor and libbitcoin are consistent!!!
submitted by greatskaht to TREZOR [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]

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]

QR code alternatives (was: Proposal: extend bip70 with OpenAlias) | Mike Hearn | Jul 20 2015

Mike Hearn on Jul 20 2015:
Hey Thomas,
Here are some thoughts on a third way we can tackle our BIP 70 usability
problem sans servers: by finding an upgrade to QR codes that give us more
space and then optimising the hell out of BIP70 to make it fit.
Better QR codes
Let's start with this paper, High Capacity Colored Two Dimensional Codes
<>. It develops an upgrade to
standard QR codes that extend them with the use of colour. The resulting
codes have ~4x the capacity but similar levels of scanning robustness.
This paper is also interesting: DualCodes
It works by overlaying one QR code on top of another using shades of grey.
The resulting code is still scannable by older applications (backwards
compatibility!) but an enhanced reader can also extract the second code.
They explicitly mention digital signatures as a possible use case.
In both cases the code does not appear to be available but the same
approach was used: extend libqrcode for creation and ZXing for decoding
(Android). We could ask the authors and see if they're willing to open
source their work.
BIP 70 has the potential to add many features. But most of them, even the
extensions currently proposed only as ideas, can be expressed with
relatively few bytes.
So with a 4x boost in capacity, or a 2x boost with backwards compat, what
could we do?
Optimised BIP70
If we define our own certificate formats and by implication our own CAs,
then we can easily make a certificate be 32 bytes for the ECC
signature+length of the asserted textual identity, e.g. email address.
Can we go smaller? Arguably, yes. 32 bytes for a signature is for Really
Strong Security™ (a 256 bit curve), which gives 128 bits of security. If we
are willing to accept that a strong adversary could eventually forge a
certificate, we can drop down to a weaker curve, like a 128 bit cure with
64 bits of security. This is well within reach of, say, an academic team
but would still pose a significant hurdle for run of the mill payment
fraudsters. If these short CA keys expired frequently, like once a month,
the system could still be secure enough.
As we are defining our own PKI we can make CA keys expire however
frequently we like, up to the expiry period of the BIP70 request itself.
Thus certificates that expire monthly is not an issue if the wallet has a
way to automatically refresh the certificate by using a longer term
stronger credential that it keeps around on disk.
If we accept a single payment address i.e. no clever tricks around merge
avoidance, such a QR code could look like this:
However this requires text mode and wastes bytes at the front for the URI
If we're willing to accept QR codes that can't be read by a standalone app
and which requires an embedded reader, then we can just scrap the legacy
and serialise a binary BIP70 request directly into the QR code. Andreas'
wallet, for example, can already handle this because it has an embedded QR
reader. I don't know what the situation on iOS is like.
If we were to use the DualCodes system we could define the primary QR code
as being an unsigned payment request, and the second layer as being the
signature/pki data.
Getting response data back to the recipient
One reason to have a store/forward network is the "forward" part: we don't
only want to host a static PaymentRequest, but also receive a private
response e.g. for the memo field, or to implement the well known "Stealth
Address" / ECDH in the payment protocol proposals:
Stealth addresses try and (ab)use the block chain as a store/forward layer
and break SPV in the process as well as wasting lots of resources. ECDH in
BIP70 avoids those issues but at the cost of requiring a separate
store-and-forward network with some notion of account privacy.
These ideas come with another steep price: restoring a wallet from seed
words is no longer possible. You must have the extra random data to
calculate the private keys for money sent to you :( If you lose the extra
data you lose the money. It can be fixed but only by having wallets
regularly sweep the sent money to keys derived from the BIP32 seed, meaning
privacy-hurting merging and extra traffic.
I don't know of any way to solve this except by using some servers,
somewhere, that store the Payment messages for people: potentially for a
long period of time. If we have such servers, then having them host BIP70
requests is not a big extra requirement.
I have imagined this being a p2p-ish network of HTTPS servers that accept
POSTs and GETs. But if we are thinking about alternatives, it could also be
a separate service of the existing Bitcoin P2P network. That's what
OP_RETURN (ab)use effectively does. But as these messages don't really have
to be kept forever, a different system could be used: Payment messages
could be broadcast along with their transactions and stored at every node,
waiting for download. But unlike regular transactions, they are not stored
forever in a block chain. They are just written to disk and eventually
erased, perhaps, ordered in a mempool like way where more fee attached ==
stored for longer, even though the nodes storing the data aren't actually
receiving the fee.
A signature over the Payment metadata using the same output keys as the
transaction would bind them together for the purposes of broadcast, but
doesn't need to be stored after that.
As the data storage is just a helpful service but not fundamentally
required, nodes could shard themselves by announcing in their addr messages
that they only store Payment metadata for e.g. the half which have a hash
starting with a one bit. And when outputs are seen being spent, the
associated Payment metadata can be erased too, as by then it's fair to
assume that the users wallet has downloaded the metadata and no longer
cares about it.
Of course you have then all the regular DoS issues. But any P2P network
that stores data on the behalf of others has these.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Announcing -- Price History reporting for your wallet transactions plus HD Wallet Address Discovery. ( 2 new open source tools )

Hey folks. I've created a couple new command-line tools and a simple website interface for them that requires no registration or signup. At this point, I think they are ready for some public testing and feedback. Maybe you will find them useful. ;-)
The website is The site provides two related tools:
1) Price History Reporting: Enter your wallet addresses and view customizable transaction reports with historic price information, as well as present day price, and the difference (gain/loss). Euros and other major fiat currencies are supported, in addition to USD.
Also available is a disposal (sales) report showing realized gains in schedule D format. Disclaimer: This is for informational purposes only and should NOT be submitted with your taxes. Consult with a qualified tax professional. Author not responsible for any calculation error, etc.
This reporting uses data from the blockchain via btcd as well historic price information from
2) HD Wallet Address Discovery: Enter your HD wallet's master XPub key and the tool will automatically find all of your wallet addresses that have been used to date, including change addresses. These addresses can then be used in the Price History tool, or for your own purposes.
Many (most?) HD Wallets do not provide a complete list of used addresses, but do provide the master XPub key. So this tool empowers users by providing information kept hidden by their own wallet software.
This tool supports CoPay multi-sig wallets (which use multiple XPub keys) and in theory should work with other multi-sig wallets that implement Bip44.
--- Command line tool: bitprices ---
The price history reporting is powered by bitprices, a new open-source tool with a lot of flexibility.
The tool can connect to multiple blockchain API's including btcd, toshi and insight. btcd is fastest as the btcd developers were kind enough to accept a patch I wrote that speeds up the necessary query by orders of magnitude for some cases.
--- Command line tool: hd-wallet-addrs ---
The HD Wallet Discovery is powered by hd-wallet-addrs. This tool automatically derives wallet addresses and then queries a blockchain API to determine if the addresses have been used or not. The supported blockchain APIs are: toshi, insight, and The Bip32 heavy lifting is done by the fantastic BitWasp bitcoin-php library.
These are open source projects and I welcome feedback, suggestions, bug reports, and contributions.
submitted by danda to Bitcoin [link] [comments]

Dynamic Bitcoin Payment Button Use Blockchain API to Calculate Time Until Next Bitcoin Block Halving Building Bitcoin Websites - YouTube NEWS: Bitcoin Unlimited. BIP 47. Overstock stocks up. Bitcoin Payments For Your Website - Complete Step By Step Guide (Electrum Software Wallet & Windows) provides Bitcoin explorer web service allowing to track transactions, blocks and address balances. Bitcoin tools, payment processing and open API. Bitcoin BIP32 calculator BIP32 calculator. Calculate addresses and keys from BIP32 extended keys. BIP32 calculator. Inheritance. Is bitcoin recession proof? crypto briefing. four apk = #BUY #USING #DEBIT OR #CREDIT #CARD APK VERSION : PC VERSION : Bitcoin Generator 1. An extended public key as defined by the BIP32 specification. New wallets will use hd/bip32 (enabling hd only possible during wallet creation/first start) HD can be disabled with --usehd=0 Only hardened key derivation Fixed ... Public Keys Calculator. v0.4.2. Mnemonic. You can enter an existing BIP39 mnemonic, or generate a new random one. Typing your own twelve words will probably not work how you expect, since the words require a particular structure (the last word is a checksum). Generate a random mnemonic: GENERATE. words, or enter your own below. Mnemonics with less than 12 words have low entropy and may be ...

[index] [21312] [34709] [37677] [35866] [25073] [23822] [567] [9480] [4234] [43422]

Dynamic Bitcoin Payment Button

btc, btc script, bitcoin 2020, btc 2020, free satoshi, bitcoin india, bitcoin usa, bitcoin indi, bitcoin hindi, earn free bitcoin, earn free btc, #BITCOIN #BTC #HACK # EARN Use Blockchain API to Calculate Time Until Next Bitcoin Block Halving by m1xolyd1an. 9:10. Blockchain Receive Payments API v2 HD BIP32 xpub by m1xolyd1an. 11:36. How to Use Blockchain Receive ... Quy trình làm dự án phác họa người máy thông minh có tính khả thi trong tương lai với que tăm - Duration: 1:01:27. minor960 Recommended for you Use Blockchain API to Calculate Time Until Next Bitcoin Block Halving - Duration: 9:10. m1xolyd1an 723 views. 9:10. ... Hierarchical Deterministic wallet - BIP32 and BIP44 - Duration: 25:55 ... How To Start A Clothing Line With $0 Dollars Legit Step by Step Tutorial - Duration: 32:01. John Santos Recommended for you