Yes! That's exactly it!  Thank you.
We're working on allowing them to accept fiat credit and debit cards as well.  However, at the moment the model is to pull out the tablet when someone wants to purchase with bitcoin.  If they have the card, it's just like a regular fiat debit card.  Swipe 3464 you're done, transferred bitcoin to the merchant.

How should I do it?

We stealth launched our limited beta app for consumers last week in the Android Play Store, and we are less than three weeks away from having cards and readers ready to distribute.  We believe strongly in improving the current financial systems by creating entirely different structures, and our security and integrity are inspired by the blockchain.  Without advertising any more to you guys, I'd appreciate any and all words regarding what you have to think.

https://play.google.com/store/apps/details?id=coinbeyond.pythagoras
https://coinbeyond.com/
https://www.youtube.com/watch?v=FRkgyVj13L4

Firstly, I appreciate your consideration of this system and value your feedback.

I think there may be some confusion on how it works, which is my fault. Let me try redescribing certain points.

The sequence is not stored. The key pair can be recomputed by following the path through the separate servers' separate database tables. The key pair is only good while funds are at that associated address, since all funds are moved to the next computed address by incrementing a row index that points to an encrypted random child index. So one sequence is not like part of the root private key. Each server only knows the next server's row to look up, the decryption key for that next row, and the extended key at its level. When a transaction is made, some layer after the customer layer increments its row index to the random encrypted child index, which tells it which child index to use for derivation at that layer and what the child server's row lookup index should be for the same actions.

It's also to protect from someone getting access to an extended key and being able to iterate through its derivations to find and retrieve funds trapped below that key. In this new system, an account's addresses are spread randomly through a subtree on many different extended keys. So access to a key lower in depth is needed to have a better chance of having an address with funds in its subtree, but then because there are several additional layers, iterating and finding those funds is not practical.

Hey guys,

I'm working with HDM structures and have been growing concerned about how to secure a master key.

HD is great, but if the master key is ever nabbed, you could lose everything.  The concept of how to secure the master key, or any non-hardened extended key, has been on my mind a lot lately.  Today I came up with something, and I'd like your feedback.

Something-like-an-abstract: The concept to protect your master key or extended keys by purposefully make your hierarchy complex and obscure with multiple layers and scrambled child indices.  So even if an attacker does form the master key, they have a more difficult time figuring out how to use it properly than randomly guessing a private key to an address.

Let me describe the scrambled child indices first:
In (I assume) normal hierarchical deterministic wallets that use a different address for each transaction, every transaction has change sent to a new address created using the next child index.  So they will start with an address derived from child index 0, do a transaction, and change will be sent to an address derived from child index 1.  If the child indices were scrambled, then they might start with an address derived from child index 617492810, do a transaction, and change will be sent to an address derived from child index 741109822.  At a simple level, this can be implemented with a simple table lookup:

TxIndex	ChildIndex
0	617492810
1	741109822
2	1840569824
3	1056489135

...

I imagine that you'd have one of these at every depth-level of your hierarchy and keep each of these secure.

Right away I thought that might be handy, but if someone were to get the private master/extended key to a tree of addresses, it would only slow them down slightly.  It wouldn't take long to fish for bitcoin for 2^31 keys.

But where I think this comes in handy is when there are multiple layers of the hierarchy. 

Say you have a master key where every child is a key for an address that you use to transact.  OK, not great.  Your tree has a depth of 2.  If someone steals your master key, you lost your funds because they'll iterate through 2^31 keys until they find your bitcoin. 

Now say you have a master key where every child has multiple children that have multiple children that ... that have have multiple children that might contain one of your transactions.  Your tree has a depth of D, with scrambled child index lookups at depth level.  So your first address with bitcoin might start with child index 1196412278 of child index 908842762 of child index 462865495 of child index 1386578953 of the master key.  When you do a transaction, your change address might be child index 33856490 of child index 2054789123 of child index 654982640 of child index 1445834988 of the master key.  Etc.

In the example just shown, with a depth layer of 5, there is a (2^31)^4 chance of guessing where the bitcoin are that this person has hidden in his 5-layer HD tree.  So even if a hacker gets this person's master key, they have an approximately 2.13 * 10^37 chance of finding that extended key that contains the private key to their funds.  One could have several more layers before things start to feel too slow.

One could have these layers being run by different servers accessible by different people. Because these tables would be vulnerable to leaking, and an attacker would know the layout of an entire scrambled layer(s) of the hierarchy, the values could be encrypted.  One could even go so far as to encrypt each row of a table with a key provided by a server running one level higher in the hierarchy, with each of these rows having a different encryption key.  So there'd be one more column to this child index scrambling table, ChildTableRowEncryptionKey. 

I really ought to go to bed though.  I'm waking up in 6 hours, with 4 hours of sleep last night.  Such is the life of a co-founder of CoinBeyond though.  We're trying hard to setup a system that customers will trust, or better yet, not have to trust, before we make the partnerships with card service companies.

What do you guys think?  Should I pursue this idea?

Cheers, 7f522408bd170dbc236a27dfca036f9bdc7248f09d3264e3c92ba20f94529fdf

You rock Nicolas.  Seriously, your code is helping me make so much more sense of the implementation.

By the way, you should add a link to your code in the Implementations section of bip-0032.  https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#implementations
I thought there was currently no C# implementation before.

And way to go porting the entire bitcoin core code to C#!  How complete would you say it is?

I'm honored to be in a community with such helpful people, thanks for being so awesome.

mcaizgk2, are you George Kimionis?!  Congrats on your open source project!  It must feel pretty good knowing you made something for the world to have and use. 

You've all convinced me to take much more time evaluating the open source options available.  I'm looking to do some multisignature and hierarchical deterministic work with keys.  I may end up forking your code and building it off of that.

Thanks guys,

Yeah!  I actually found BitcoinLib and bitcoinrpcsharp during development, and then decided to finish anyway.  I made sure to give them, BitSharp, and Bitcoin.NET props in the README's summary section. 

There's a lot of great stuff in those libraries, yet there's also a lot that we might never need.  CoinBeyond doesn't plan on using wallets or the accounts system.  We also can't risk having customers' private keys used in any way that we're not intimately knowledgeable about.  It's going to take some time and effort to look deep into each of the open source projects for our requirements and knowing exactly the way private keys are handled, so I'm not sure whether to do that or make our own, or both.  Are any of these other projects regarded as extremely secure?

It's possible that we'll use MonoBitcoind or one of the other projects in our backend where we process the bitcoin part of card transactions.  Regarding libraries that are under the GPL license, does that mean we'll need to open source GPL-license anything that uses a GPL-licensed library if and only if we distribute something that comes packaged with some GPL-licensed code?  In other words, is it fine if we use GPL-licensed code in closed-source code on the backend?

Thanks u/archit, that helps a lot!

Hey Community,

I needed a way to automate raw transactions with multisig accounts, and I was used to using bitcoind, so I created a few functions in C# to make doing this a lot easier.  Now I don't have to touch the outgoing JSON-RPC calls, so no more stupid syntax errors for me.

In order to prevent other future headaches, I started doing this for a bunch of the bitcoind commands.  

Then thinking it would be cool to create a library of all the bitcoind commands so other bitcoin automation noobs wouldn't have to suffer like I did, I powered through and implemented simple C# methods for every command (except 3: getblocktemplate, getwork, and submitblock; I feel like I need to learn more about these first).

Here it is: https://github.com/nrjudson/MonoBitcoind

So it's super easy to pick up, I gave examples for every call too.  And none of the names of the bitcoind functions have changed (for better or for worse).

Because all of the bitcoind commands are in a single class, you only have to Ctrl+f one file to find what you're looking for.  You also only need to copy this one file and the json.NET library to have a full interface to bitcoind.

Enjoy~

Noah

Thanks for the clarity!  With the rising popularity and power-limitation of multisig, I guess that the accounts feature wouldn't be worth investing to be modified to use industrially, since we may be moving away from online bitcoin hosts having direct control over one's bitcoins.


I learned this the hard way too.  Does this mean that any unspent TxOut in the new transaction are sent as miner's fees?

Good to know it's a problem with accounts and not me. Has anyone filed a big report?

I've been attempting to do transactions to and from a multisig address for a couple of days, but I'm finding that my default account "" keeps paying for things, even though I'm explicitly saying other accounts should pay for things via the txid field in createrawtransaction.

For a quick example, if I create a transaction like:

bitcoind createrawtransaction [{\"txid\":\"504aa16418fbb871d307249448bcecdaa5699872a4d22b84d170ae64a2fe89ca\",\"vout\":0}], {\"2NASaVRks1dFupX1e6y3SK8BomjhvSv7xGh\":50}

(It's formatted this way because I'm running this in a windows command prompt at the moment, hope to be able to run linux soon!)

the account associated to the address in the transaction's vout where n=0 is "test", but after I sign and send this raw transaction and check listaccounts, "" is debited 50 instead of "test".

If it helps at all, 2NASaVRks1dFupX1e6y3SK8BomjhvSv7xGh is a 2 of 3 address of which "test" is a part of.

Am I doing something wrong, or is this just how bitcoind handles situations where all of the addresses in a (multisig) transaction are associated with accounts in my wallet? And if so, why??

It's also all being done in regtest mode, but I wouldn't expect bitcoind to handle transactions differently in that mode.