Bitcoin Forum
February 27, 2015, 04:02:54 AM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 »
1  Bitcoin / Development & Technical Discussion / Re: Ledger Theory Coq Development on: February 10, 2015, 06:32:33 PM
Still reading through this and so far it's very interesting but I wanted to make one comment. The paper should make clear up front that your use of the term "forge" is related to mining a block and not related to creating an illegal block.  You mean forge as in create not forgery.
2  Bitcoin / Alternative clients / Re: Mycelium Bitcoin Wallet on: December 18, 2014, 07:53:41 PM

Good work! I'm very pleased.
3  Bitcoin / Development & Technical Discussion / Re: Child key derivation function on: November 11, 2014, 09:06:40 PM
Ok, so that follows my primary key hash concat logic that i striked out in OP (only BIP-32 calls it index, or sequence here), but then I need to store that index/sequence next to my child key... also I need to make sure the index/sequence is used only once too! hm, was looking for something cleaner.

Thx!

Depending on how many child keys you want you could search for child keys where the index is encoded in the bits of the child key. No need to store the index with the child key.

Most child keys would not have this property, but those that do are obviously children of the master key. You extract the index from the child key and re-derive the child key from the master key.

For example you could start generating child keys with index i starting at 1 and going up. The first few bits of the hash of the child key could be compared to i. If it matches, this is a usable child key.

Unfortunately, you'd be lucky to find a key with this property. You can increase the probability of finding a child key if you allow yourself more child key candidates per index. You could hash n times for example and if the first few bits of any of those hashes matches i you have a usable child key. Of course you have to check possibly all n candidate indexes to show that the child is derived from the master.

Probably too complicated for your application, but then, I don't know your application.


4  Bitcoin / Development & Technical Discussion / Re: Cryptographic Protocol on: November 11, 2014, 07:53:18 PM
Look at how BIP0032 does it.

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
5  Economy / Economics / Re: Defiatize the unit of value on: November 08, 2014, 03:26:41 AM
There is nothing called "total fiat money", only two types of money: base money and checkbook money. Banks usually add them together and call it money supply, but this is to confuse normal people

You may not call checkbook money "money", but it's 90% of what most people and industry needs for commerce. Some countries are exploring eliminating paper money altogether. Base money will then just be numbers in checkbooks between the fed and the banks.  That will certainly "confuse" normal people.

I'm not saying base money isn't important. It keeps the banks honest. In practice they never have to hand out more than a small fraction of their liabilities in base money. But they do have to produce it on demand hence they need to keep their reputations intact so they can borrow some when they need it.  This makes the correspondence between checkbook money and base money very tight.

My comments on the desirability of being able to borrow fiat (base or checkbook) still hold. My comments on the opinion that fiat (base or checkbook) is backed by loan contracts representing promises to labor also still hold. Banks will shun a bank that has ruined its own credit by not balancing its liabilities (checkbook accounts) with assets (loan contracts and the associated income).

Base money, of course, can be printed as needed by the fed. They print the right amount to target inflation at under 2%. That's the "if it's well managed" part of my comments. As far as I can tell, the fed seems to be pretty conservative in this regard.

An intersting alternative setup is to get rid of the fed and allow banks to issue their own paper money. See the literature on free banking for how that works. The idea is that if a bank abuses its power to print it is punished by the market when their paper bills are not accepted. The owners will have a market incentive to be responsible.
6  Economy / Economics / Re: Defiatize the unit of value on: November 07, 2014, 06:56:29 PM
Commercial banks does not create money, I mean base money, not some check book numbers in their database. When you ask for a loan, if commercial bank does not have base money, they can not give you a loan, that's a liquidity problem. Otherwise there will never be any bank failure, they could just loan to each other and create trillions of dollars

I'm afraid that's not right.

http://www.bankofengland.co.uk/publications/Documents/quarterlybulletin/2014/qb14q1prereleasemoneycreation.pdf

Commercial banks do create money. It may not be base money but base money is only a small fraction of total fiat money. They create a loan on their books and balance it with an asset which is the contract you sign for a loan, not any base money they may or may not have. Base money is only used for cash withdrawals, a very small value relative to their normal volume. If they run short they're allowed to run to the fed and borrow some.

They don't over borrow from the fed because they have to pay interest. They can't just have base cash sitting in their vaults if they have to pay interest on it.

Base money is small part of the total fiat money we use.
7  Economy / Economics / Re: Defiatize the unit of value on: November 07, 2014, 04:25:25 PM
If you regard fiat currency the unit of value, then your slavery will never end, you will forever working to earn some paper printed by a few while they take the ownership of your wealth by simply printing or adding zeros to their account

You know, of course that most money is not printed by the central bank. Most money is created by the stroke of a pen by normal banks when someone comes in asking for a loan. 90% of our economy runs on money created this way.

In reality fiat is not without backing. Fiat is backed by the promises we make to each other to pay back loans. Personally, I can't think of a better backing for the money I hold. Much better than some arbitrary faith in a yellow metal or some cryptography.

If the Government paid back all it's loans it would have to do it by taxing everyone today, making us poorer today. We are getting richer as a society all the time so it makes sense to pay our loans in the future when we are wealthier. Government borrowing is being paid off all the time. We do borrow as well so it just appears that we are not paying our debt. The amount we can wisely collectively borrow is also going up because we are getting richer. It makes sense that the balance goes up. We can afford it.

You may disagree with how much society spends through Government. That's politics. Just don't blame fiat. Fiat enables Government. It enables Industry. It enables you and me. It's just a tool and a good one if well managed.
8  Economy / Economics / Re: When will the USA pay their debts, if ever? on: November 03, 2014, 07:09:00 PM
In a related note, is there any major country that is completely debt-free?

Everyone seems to be owing something to someone else.

Yet those countries all seem to be growing. Year in and Year out. Owing is just the promise to labor for someone else in the future. Also we mostly owe ourselves regardless of the China myth. So we're promising to labor for ourselves in the future.

The downturn in 2007 was because the fed allowed NGDP to fall 10% instead of growing at 5% as it was for the previous 20 years. If the downturn hadn't happened government debt would be much smaller today.

What do you think would happen today if the fed froze the money supply? We'd have a crash in NGDP much larger than the one in 2007. Why would you want that kind of pain for people? Some sort of moral code that says "don't print more money" because it's evil?

If you want to save and hate 2% inflation than save in real assets, stocks, land, etc. Don't hoard cash and declare that any inflation is evil. And remember, 2% inflation means income is growing by at least 2% as well (actually higher if productivity is growing.)
9  Economy / Economics / Re: Defiatize the unit of value on: November 03, 2014, 06:47:24 PM
One problem is incomes are defined in Fiat. Valuing everything in Bitcoin is not useful when you can't tell if you can afford to buy something.

Your mind automatically goes to Fiat to compare to your income.
10  Bitcoin / Project Development / Re: CoinStar on: October 21, 2014, 09:58:51 PM
- and I'm 99% sure they are internet connected.  I'm not sure if distributing private keys at the location is feasible or if some sort of redemption code would make it simpler.

Even without internet the machine could print a dollar denominated voucher for Coinbase or a similar operator. The user would go to the website and be guided through setting up an account if he doesn't have one. His dollars would be converted to Bitcoin at the time he enters the voucher number on the site at the then current rate. Coinbase would collect dollars from CoinStar.

11  Bitcoin / Alternative clients / Re: Mycelium 2.0 HD - Welcome to the future on: October 19, 2014, 02:57:05 AM
Does the HD wallet use compressed keys? As in, the private keys start with the letters L or K?

Breadwallet doesn't seem to expose the private keys, only the twelve word seed generator. My installation's current (public) address starts with 16E. This is the second address it generated. The first (which received some funds) started with 1PL.

The first address showing on Mycelium (using the same 12 word seed generator) starts with 1EJ.


breadwallet isn't using the same BIP32 tree structure as mycelium, so the backups are not compatible. I have heard that hive is using the same structure as breadwallet, though I don't recommend typing your backup phrase into multiple wallets and devices. Security of your wallet seed is absolutely critical. Every wallet and device you use it with increases the chances that one of them has a security hole or is infected with malware. breadwallet is built to a very high standard of security. Your seed is only stored in the iPhone secure enclave which is hardware encrypted and even hardened against EM side-channel attacks. Other wallets decrypt your keys in the browser with javascript, and other platforms are far more susceptible to malware.

Ah.. Thanks for the clarification.

As for your other comments, I agree, but I absolutely need to know I CAN go to another platform if I have to. Preferably many platforms. With paper cold store I can, but with 12 word seeds I still can't.

There is nothing wrong with trying to restore backups on another platform when the wallet has trivial amounts in it. That way I know I can do it if I have to some day. For example, what if Breadwallet is pulled from the AppStore?
12  Bitcoin / Alternative clients / Re: Mycelium 2.0 HD - Welcome to the future on: October 18, 2014, 03:42:54 PM
Does the HD wallet use compressed keys? As in, the private keys start with the letters L or K?

Breadwallet doesn't seem to expose the private keys, only the twelve word seed generator. My installation's current (public) address starts with 16E. This is the second address it generated. The first (which received some funds) started with 1PL.

The first address showing on Mycelium (using the same 12 word seed generator) starts with 1EJ.
13  Economy / Economics / Re: Now one million merchants will drive selling pressure! on: October 17, 2014, 04:57:36 PM
..but in terms of price, it is going to be always a negative pressure.

Absolutely not. If a million merchants each have 10 customers who want to try bitcoin that's 10 million new users buying bitcoin. They will probably keep a small balance in their wallets pulling those coins off the market.

And if they get comfortable using bitcoin and see there are a million ways to use it, they may move part of their savings into bitcoin; pulling those coins off the market as well.

Net positive all around.
14  Bitcoin / Alternative clients / Re: Mycelium 2.0 HD - Welcome to the future on: October 17, 2014, 05:18:18 AM
* Added support for BIP32/BIP44 compliant HD accounts based on a single master seed
* A much simpler backup that uses a word list to backup all your HD accounts (BIP39)

Has anyone tried taking the 12 word backup between Breadwallet(for iPhone) and Mycelium?

I can't seem to get it to work. I have a BIP32/BIP44 wallet on Breadwallet and I have the 12 word BIP39 backup. I downloaded a fresh Mycelium and asked it to restore from those 12 words. It shows as a zero balance wallet with a different receive address than the first one that was shown by Breadwallet.

Any ideas? compressed vs uncompressed? Anything else?
15  Bitcoin / Development & Technical Discussion / Re: A solution to a collusion flaw in Deterministic Wallets on: October 11, 2014, 04:56:54 PM
I'm curious. I've never used the IRC where this was discussed. Is there a reference I can refer to to get on there.

If you don't have an IRC client:

https://webchat.freenode.net/

for your client, if you have one, it's irc.freenode.net

join #bitcoin-dev

Thanks dabura
16  Bitcoin / Development & Technical Discussion / Re: A solution to a collusion flaw in Deterministic Wallets on: October 11, 2014, 04:20:57 PM
You're right. r0 and r1 aren't truly independent random variables.

You would need a separate r for sub key at each level.
Something like rn = H(n,a,1) instead of r=H(a)
Then pass a separate Rn for each sub key to the auditor.      Ugh


never mind

Yeah, at which point... it would be better just to give the Auditor a list of the pubkeys for each department and not just the master pubkey.

it's a rough problem...

No. not quite that bad. You could protect from up to m-collusions by utilizing ri for i from 1 to m and using the equation

                 xn = (sn)a + rn1 + ... + rnm

to protect "a".  Each rni would be calculated from tni and ri

          tni = H(n,Ri)
          rni = (ri)(tni)

The auditor would need R1 thru Rm for his work but he would have to find  m  colluding managers to solve for "a".

With an "m" near 3 or 5 it would be practical I suppose.

17  Bitcoin / Development & Technical Discussion / Re: A solution to a collusion flaw in Deterministic Wallets on: October 11, 2014, 04:04:38 PM
You're right. r0 and r1 aren't truly independent random variables.

You would need a separate r for sub key at each level.
Something like rn = H(n,a,1) instead of r=H(a)
Then pass a separate Rn for each sub key to the auditor.      Ugh


never mind
18  Bitcoin / Development & Technical Discussion / Re: A solution to a collusion flaw in Deterministic Wallets on: October 11, 2014, 02:50:14 PM
I'm curious. I've never used the IRC where this was discussed. Is there a reference I can refer to to get on there.
19  Bitcoin / Development & Technical Discussion / Re: A solution to a collusion flaw in Deterministic Wallets on: October 11, 2014, 02:48:10 PM
From IRC:

Quote
18:28:54 <sipa> xn = sn*a + tn*r
18:29:14 <sipa> Xn = sn*A + tn*R
18:31:10 <sipa> if you know sn and tn and xn for 2 different n, you can solve it
18:31:43 <sipa> as you now have 2 equations with 2 unknowns (a and r)
18:32:17 <sipa> and given A and R you can compute sn and tn for any n
18:33:56 <sipa> so give me A and R and xn1 and xn2, and i can find a and r

So your method would effectively lower the risk from "One Master Public Key and one derived private key" to "One Master Public Key and two derived private keys"

Wait. If you know the equations for 2 different n, you now have _three_ unknowns: "a", r0, and r1. You still can't solve for "a".  You know Rn but not rn for different n's.

I chose the form xn = sn*a + rn carefully to match how Schnorr's signature algorithm for elliptic curves protects the secret key. If this doesn't protect "a" then Schnorr's algorithm is in trouble.
20  Bitcoin / Development & Technical Discussion / A -failed- solution to a collusion flaw in Deterministic Wallets on: October 11, 2014, 04:11:09 AM
edit  Fails as it doesn't adequately protect the secret master key from two collusions. See the comments.



http://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/

As described in the article above (go down to the section “An Understated Problem”), deterministic wallets have a flaw with a solution best described in the following quote:


The idea is that if you give the auditor the watch only wallet, he could conspire with one of the holders of the private keys below it to create the master private key and run away with all the money.

M = master public key
m = master private key

m/ = CEO holds it

M/ = Auditor holds it. With it, they can view all company funds, but not spend.

m/m1 = Department A head holds it, and can generate further chains with it.
m/m2 = Department B head holds it, and can generate further chains with it.
m/m3 = Department C head holds it, and can generate further chains with it.

combining M/ with m/mx would give me m/ ... so an auditor would have to conspire with one corrupt department head to run away with the company's entire finances.


With the solution provided says that the CEO would make

m1/
m2/
m3/

Then

Dept A:
m1/m1
m2/m1
m3/m1

Dept B:
m1/m2
m2/m2
m3/m2

Dept C:
m1/m3
m2/m3
m3/m3

Each dept using the three public keys generated by those chains to generate deterministic 2of3 chains.

The Auditor would ONLY receive:

M1/

Then they could check the blockchain for redeemscripts that included
M1/M1
M1/M2
M1/M3

Then they would know how much money each department SPENT without being able to collude to get 2 private keys.

Downside: They could only find SPENT funds, as the redeemscript is only revealed on the blockchain when funds are spent from the multi-sig address.

imo, the best way to do an audit for business would be to use a dual-key Stealth Address, and give the scan_privkey to the auditor... but this is a topic slightly unrelated to BIP32.

You could set up so your company's stealth addresses are generate on a per-department basis, but that all scan_keypairs are generated by a separate BIP32 chain.

Give that master private key to the auditor, as that keypair is only used to generate shared secrets to discover funds, not to spend it.

I think I have a solution that doesn’t depend on 2 of 3 keys as described above.

The owner of the Master Private Key (call it “a”) generates another secret from that (call it “r”) where r = H(a), a hash of “a”.

He passes the public sides, A = [a]Q and R = [r]Q, to the auditor and combined, they become the Master Public Key.

The owner generates the “n”th private key as follows:

   sn = H(n,A)
   tn = H(n,R)

   rn = (r)(tn)    the product of the two private parts modulo a large prime. Note, this remains secret to the owner by virtue of keeping “r” private.

   xn = (sn)a + (rn)    where xn becomes the “n”th private key.

The idea is that “rn” will not be known to the auditor or to the holder of “xn” as we will see in a second. It therefore “covers” the Master Private Key in case of collusion between the auditor and the holder of “xn”.

The Auditor:

The auditor knows A, R, and n  (Furthermore, he knows “xn” for any and all “n” due to collusion.)

He can generate the “n”th public key as follows:

   sn = H(n,A)
   tn = H(n,R)

   Rn = [tn]R    the public part of the private “rn” which he doesn’t know since he doesn’t know “r”.

   Xn = [sn]A + Rn    where Xn is the public side of “xn”, the “n”th private key.

Knowing “xn” does not give him “a” since “a” is protected by the unknown “rn” in the equation     xn = (sn)a + (rn)


edit  Fails as it doesn't adequately protect the secret master key from two collusions. See the comments.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!