Bitcoin Forum
May 25, 2024, 03:42:17 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Economy / Service Announcements / Re: [ANN] Bitfinex Passes Proof of Solvency Audit on: April 07, 2014, 04:38:29 PM
It would be nice if we could standardise those proofs. Me along with iwilcox and others (https://github.com/olalonde/proof-of-liabilities#implementations) have put a lot of time and effort in standardising our tools so that they are interoperable and secure. It's a bit painful and frustrating to see this scheme re-implemented again and again with no attempt follow a common standard. I understand that it was not possible for you to follow the proof-of-liabilities standard due to the requirements imposed by bitfinex, but why not contact us / open a GH issue / send a pull request / etc. and explain why the standard needs to be modified / extended to support your use case? Without a standard and multiple independent verification tool implementations, it will be difficult to expect end users to actually verify the proof.

That being said, congrats to bitfinex for getting audited.

PS: I also think the choice of wording here is a bit misleading ("passes proof of solvency audit"). I think "submits to proof of solvency audit" would be more adequate as the proof of solvency is only really "passed" when users individually verify the proof.
2  Bitcoin / Development & Technical Discussion / Re: Why is there a target field in block headers? on: April 01, 2014, 05:47:36 AM
> For efficiency sake nodes validate the header values first.

Makes sense. Thanks.
3  Bitcoin / Development & Technical Discussion / Re: Why is there a target field in block headers? on: March 31, 2014, 01:04:27 PM
Sure, I know that. I know what the target is and how it is computed.

What I wonder is why is the target is stored in block headers when it should be calculated independently by verifiers? Seems like redundant information at best and a potential pitfall for naive client implementations at worse.
4  Bitcoin / Development & Technical Discussion / Why is there a target field in block headers? on: March 31, 2014, 04:42:51 AM
Block headers have a `bits` field representing the target at the time a block was mined (according to the Bitcoin wiki). Obviously, clients cannot trust this field as a malicious miner could simply set an easy target, rendering the PoW meaningless. What is the purpose of having a target field in block headers if it cannot be trusted?
5  Bitcoin / Development & Technical Discussion / Re: bitcoin maximum fraction unit? there are something less than satoshi unit? on: March 27, 2014, 09:57:07 PM
Is there any check in the transaction verification code that this value must be >= COIN ?
6  Economy / Service Announcements / Re: [ANN] Kraken Passes Cryptographically Verifiable Proof of Reserves Audit on: March 24, 2014, 01:54:26 PM
Is this a process that can be automated / carried out without an outside auditor?

Yes, see https://github.com/olalonde/proof-of-solvency

Great work guys, congratulations.

I'm afraid one piece of the puzzle seems still open to me. The audit proves that everyone's balance is represented in the Merkle tree, but not that the same bitcoins aren't backing two people's accounts at the same time. That is, there's no way to check against the following scenario:

USER1 audit page:
Submission code: 379377cd8190f9bf
Amount: 0.01500000

USER2 audit page:
Submission code: 379377cd8190f9bf
Amount: 0.01500000

Thankfully, this proof gap can be resolved without an auditor, and in an anonymous way.

I propose the following three-step scheme. (step 1) Kraken generates a 64-bit nonce for each account in the system. They publish this nonce on each user's account page, as follows:

USER1 audit:
Submission code: 379377cd8190f9bf
Nonce: fa132f44d7e35e0f
Amount: 0.01500000

(step 2) Kraken publish a signed document with the anonymized account name for each submission code:

$submission_code: sha256($nonce || ":" || $username)

For USER1 in our example, sha256("fa132f44d7e35e0f:USER1")=b7000194f1327aeb9b16f6104333fc889dd2f4c3cdba1eb3500d91ca5efc8208, so the document would contain:

379377cd8190f9bf: b7000194f1327aeb9b16f6104333fc889dd2f4c3cdba1eb3500d91ca5efc8208

(step 3) Users will verify not only that their submission code exists in the Merkle tree, but also that the submission code cannot correspond to any other account by calculating the sha256 as above and verifying that it corresponds to the submission code.

(end of scheme)

The only drawback I see is that this will make public the number of accounts in the Merkle tree, but I don't think this should be a problem.

Let me know what you think.

This problem is addressed in the standard proposed here: https://github.com/olalonde/proof-of-liabilities/#leaf-node

By the way, I'm not sure I understand how Kraken users are supposed to do the verification. Are they given a tree in order to compute the root? If so, would anyone mind sharing the tree they were given so that I can make http://syskall.com/proof-of-liabilities/#verify compatible with their format (this will reveal your balance on Kraken)? Let's be realistic, most users will never verify the code if it involves writing some code.
7  Economy / Service Announcements / Re: [ANN] Kraken Passes Cryptographically Verifiable Proof of Reserves Audit on: March 24, 2014, 12:16:15 PM
For those of you who might be considering implementing the scheme, please consider making your implementation compatible with  https://github.com/olalonde/proof-of-liabilities#specification (there are about 3 implementations following this spec now) to allow interoperability with verification tools. Also, see the online tools at http://olalonde.github.io/proof-of-liabilities and higher level description of the scheme at https://iwilcox.me.uk/2014/proving-bitcoin-reserves

We need the proofs to be verifiable automatically (through a browser extension for example) if we ever want this kind of scheme to work in practice.

Regardless, thumbs up to Kraken for being more transparent about solvency.
8  Bitcoin / Development & Technical Discussion / Working on a language and compiler for Bitcoin scripts on: March 03, 2014, 11:01:14 AM
I've never written a compiler before and wanted to give it a shot so I decided to write a high level language and compiler for Bitcoin's stack based script
language. So far, the parser kind of works but the compilation step is still work in progress. The language (bitscript) uses a Javascript like syntax.

The following script should compile to a standard transaction script (eventually):

Code:
// standardtransaction.bitscript
function main(sig, pubKey) {
  pubKeyHash = '1eHhgW6vquBYhwMPhQ668HPjxTtpvZGPC';
  pubKeyHashA = hash160(pubKey);

  // should be optimized to OP_EQUALVERIFY
  assert(pubKeyHash == pubKeyHashA);

  // should be optimized to OP_CHECKSIGVERIFY
  assert(checksig(sig, pubkey));
}

I'm posting this here mainly to keep me motivated and in case anyone wants to participate. I'm writing the compiler using Node.js + Jison. https://github.com/olalonde/compiler/
9  Bitcoin / Development & Technical Discussion / Re: Blind Solvency Proof Scheme on: March 03, 2014, 03:49:33 AM
Good news. There is an online wallet currently implementing the scheme. They should announce it shortly.
10  Bitcoin / Bitcoin Discussion / Re: Best Practices to Avoid Mt Gox Repeats on: March 02, 2014, 01:38:22 AM
Have a look at https://bitcointalk.org/index.php?topic=493475 (blind solvency proof scheme)
11  Bitcoin / Development & Technical Discussion / Re: Request for Comments on Audit Protocol on: March 02, 2014, 01:23:12 AM
I've implemented something very similar here: https://github.com/olalonde/bitcoin-asset-proof

Also see Blind Solvency Proof scheme: https://bitcointalk.org/index.php?topic=493475.0
12  Bitcoin / Development & Technical Discussion / Re: Blind Solvency Proof Scheme on: March 01, 2014, 07:28:41 AM
Thanks for the suggestion. I will put this on my TODO list.
13  Bitcoin / Development & Technical Discussion / Blind Solvency Proof Scheme on: March 01, 2014, 04:03:40 AM
Blind Solvency Proof Scheme

Hi all, this is my first post here. I have been working on a scheme and a related set of tools that an exchange (shared wallet) can use to prove they are solvent within reasonable certainty while protecting the privacy of its user. The scheme is based on gmaxwell's "prove-how-(non)-fractional-your-Bitcoin-reserves-are scheme". (https://iwilcox.me.uk/2014/nofrac-orig).



Github repository: https://github.com/olalonde/blind-solvency-proof

The specification is still a draft and improvements/criticism/pull requests are welcome.  A related white paper will be published some time next week elaborating on the concepts and introducing some new ones. Please use Github issues for technical issues.

Show your support: 1ECyyu39RtDNAuk3HRCRWwD4syBF2ZGzdx

There are 3 components to the scheme: liability proof, asset proof and solvency verification.

Liability proof

https://github.com/olalonde/blind-liability-proof

The liability proof is done by widely publishing the root of the proof tree and distributing partial trees to your users so they can verify they were included in the tree.

Complete proof tree

The complete proof tree is a binary tree where the leaf nodes represent all the user accounts and the interior nodes generated using the NodeCombiner function described below.

The complete tree should be kept private by the operator in order to protect the privacy of its users. Only the root node should be puslished publicly and each individual user should have private access to their own partial proof tree.

Interior node (NodeCombiner function)

Interior nodes are generated using the NodeCombiner function described below.

The node's value is equal to the sum of its two child node's values.

The node's hash is equal to the sha256 of its value concatenated with its child's hashes.

Code:
function NodeCombiner (left_node, right_node) {
  var n = {};
  n.value = left_node.value + right_node.value;
  n.hash = sha256((left_node.value + right_node.value) + '' + left_node.hash + '' + right_node.hash);
  return n;
}

Leaf node

Leaf nodes represent user accounts. They possess the following values:

user: A unique identifier for the user. It is necessary for a user to assess the uniqueness of this value so it is recommended to use their username or email.
nonce: A random nonce to prevent its neighboor node from discovering its user value
value: The user's balance.
hash: A sha256 hash of user concanetated with the nonce.

Root node

The root node of the tree like all interior nodes possesses a hash and a value. This data must be published publicly as a way to prove that all users are part of the same proof tree.

Partial proof tree

A partial proof contains only the nodes from the complete root a given user needs to verify he was included in the tree.

It can be generated by starting from the user's leaf node and moving up the tree until reaching the root node. Then the siblings of each selected node on the path must be added to the tree. The user's leaf sibling which is also a leaf node must be stripped of its user and nonce values so that only the hash and value remain.

Partial trees should be disclosed privately to each individual users so they can verify the proof.

Asset proof

https://github.com/olalonde/bitcon-asset-proof

At the moment, the asset proof is simply done with signing a descriptive message using all your private keys. This method has significant limitations and I would love to hear improvement/alternative suggestions.

Solvency verification

https://github.com/olalonde/solvency-verifier-extension

The solvency verification is done by:

1) Verifying the liability proof
2) Verifying the asset proof
3) Verifying that assets - liabilities >= 0

The Chrome extension currently has some limitations. For one, users must manually verify with other users that they were given the same root hash value. They must also verify that the balance used in the liability proof is correct.

References

Special thanks to gmaxwell for his help on IRC.

IRC log: https://iwilcox.me.uk/2014/nofrac-orig
HN thread: https://news.ycombinator.com/item?id=7277865
Reddit thread: http://www.reddit.com/r/Bitcoin/comments/1yzil4/i_implemented_gmaxwells/


DISCLAIMER: This scheme is a draft and subject to change.


Feedback, questions and constructive criticism are welcome!
14  Bitcoin / Bitcoin Discussion / Re: Mars One: Bitcoins in space? on: April 24, 2013, 06:44:39 PM
My first post on the noob forum jokingly talked about the problem of the blockchain on Mars and beyond if bitcoin is still around 200 years from now. As soon as the blockchain is divided into bitcoin-Mars, bitcoin-Europa, etc, things is going to be a mess...

Some says quantum entanglement would be a solution for every future form of data communications from any two points in the universe without the limitation of the speed of light. Not only that but when Alice Data is locked with Bob Data through this weird, bizarre concept, Carol from NSA CANNOT intercept the Data.

Of course this is still science fiction, but the concept already was proved and worked in the lab as far as Data teleportation.

http://youtu.be/3nq6y9P1_yM

Unfortunately, quantum entanglement doesn't allow faster than light communication.

Weird, i was under the impression that wasnt the case. got a link or something? (ill try to look it up later either way)

That's the best I could find: http://everything2.com/title/Quantum+entanglement+and+faster+than+light+communication
15  Bitcoin / Bitcoin Discussion / Re: Mars One: Bitcoins in space? on: April 22, 2013, 07:22:01 PM
My first post on the noob forum jokingly talked about the problem of the blockchain on Mars and beyond if bitcoin is still around 200 years from now. As soon as the blockchain is divided into bitcoin-Mars, bitcoin-Europa, etc, things is going to be a mess...

Some says quantum entanglement would be a solution for every future form of data communications from any two points in the universe without the limitation of the speed of light. Not only that but when Alice Data is locked with Bob Data through this weird, bizarre concept, Carol from NSA CANNOT intercept the Data.

Of course this is still science fiction, but the concept already was proved and worked in the lab as far as Data teleportation.

http://youtu.be/3nq6y9P1_yM

Unfortunately, quantum entanglement doesn't allow faster than light communication.
16  Bitcoin / Bitcoin Discussion / CAPTCHA to mitigate DDoS attack? on: April 22, 2013, 10:16:49 AM
I was wondering if Mt.Gox could force all visitors to solve a Google hosted CAPTCHA before being able to access the website. It seems that the small annoyance of having to solve a CAPTCHA would outweigh the damage done by a DDoS. Logged in users and users who have previously solved a captcha should be exempt from the CAPTCHA requirement.

Would this even work? Would it be a good idea?
17  Economy / Economics / Paul Krugman (1998): By 2005 Internet will have no more economic impact than fax on: April 16, 2013, 01:57:36 AM
Thought some of you would like this little gem  Cool

http://web.archive.org/web/19980610100009/www.redherring.com/mag/issue55/economics.html

Quote
Why most economists' predictions are wrong.
By Paul Krugman

Everyone knows we are living in a time of spectacular technological progress--progress at a rate that nobody could have foreseen. But is what everyone knows really true?

Recently I went to the library and checked out a once-famous book, Herman Kahn's The Year 2000, published in 1967. The book is a favorite because it is a perfect example of overly optimistic economic forecasting. Kahn, presumably drawing on the opinions of pretty reasonable people, predicted that over the last third of the century living standards would double, despite a sharp reduction in work time. He thought that by 2000 a 30-hour workweek, with 13 weeks of vacation per year, would be the norm. He then went on to worry about the social implications of excessive leisure time. His prophecy didn't come true, but most Americans were too busy trying to make ends meet to notice.

Why was Kahn--along with almost everyone else--so optimistic? Mainly because he expected spectacular technological progress, which for the most part has not materialized.

No bots
Kahn provided a convenient set of tables listing 100 innovations that he considered "very likely" by the year 2000, plus 25 "somewhat unlikely" possibilities. And he actually fares pretty well. Among the very likely developments were many major technological changes that have taken place. He predicted, for example, that most people would have computers at home and that they would be able to use them both to search databases and to communicate. He also predicted pocket phones, VCRs, and home satellite dishes. Indeed, I can't think of a single important technological development since 1967 that was not on his list.

All of his errors were in the opposite direction. Many of the technological developments he predicted, like radical new power sources, dramatically cheaper construction techniques, and undersea cities, did not materialize. In fact, only about a third of his very likely innovations have occurred, by my count, mainly in areas involving information processing; two-thirds have not. (An example: though Kahn was skeptical that housecleaning robots would be available by 1984, he regarded them as more or less a sure thing by 2000.) And not one of the innovations he listed as somewhat likely has taken place--or seems likely to happen any time soon. In short, looking back at the future makes it pretty clear that technology has made less, not more, progress than expected.

How can this be, when information technology is making such strides? One answer is that input isn't the same as output. The raw power of computers has advanced at a stunning speed, but has this advance translated into a comparable improvement in their usefulness? Word processing, to take the most obvious example, hasn't fundamentally improved since the late '80s. And in the view of many people I know, WordPerfect 5.1 for DOS was actually better for their purposes than any of the bloatware that has followed.

Peaks in valleys
Another explanation is that when all is said and done, the technological progress we keep hearing about is occurring in only a small part of the economy. Silicon Valley employs something like one-third of 1 percent of U.S. workers, and information technology as a whole no more than 3 or 4 percent, unless you use a definition so broad as to be meaningless.

So never mind the hype. The truth is that we live in an age not of extraordinary progress but of technological disappointment. And that's why the future is not what it used to be.

Paul Krugman is a professor of economics at MIT.

FUTURE THOUGHT
Paul Krugman prognosticates.

* Productivity will drop sharply this year. Nineteen ninety-seven, which was a very good year for worker productivity, has led many pundits to conclude that the great technology-led boom has begun. They are wrong. Last year will prove to have been a blip, just like 1992.

* Inflation will be back. Wages are rising at almost 5 percent annually, and the underlying growth of productivity is probably only 1.5 percent or less. Sooner or later, companies will have to start raising prices. In 1999 inflation will probably be more than 3 percent; with only moderate bad luck--say, a drop in the dollar--it could easily top 4 percent. Sell bonds!

* Within two or three years, the current mood of American triumphalism--our belief that we have pulled economically and technologically ahead of the rest of the world--will evaporate. All it will take is a few technological setbacks or a mild recession here while Europe or Japan recovers a bit.

* The growth of the Internet will slow drastically, as the flaw in "Metcalfe's law"--which states that the number of potential connections in a network is proportional to the square of the number of participants--becomes apparent: most people have nothing to say to each other! By 2005 or so, it will become clear that the Internet's impact on the economy has been no greater than the fax machine's.

* As the rate of technological change in computing slows, the number of jobs for IT specialists will decelerate, then actually turn down; ten years from now, the phrase information economy will sound silly.

* Sometime in the next 20 years, maybe sooner, there will be another '70s-style raw-material crunch: a disruption of oil supplies, a sharp run-up in agricultural prices, or both. And suddenly people will remember that we are still living in the material world and that natural resources matter.
18  Other / Beginners & Help / Re: Can BitCoin change the world economy? on: April 15, 2013, 12:56:47 PM
If you want people to join the conversation, please ask a more specific question or start elaborating an answer by yourself to show you have done your homework and read a bit about Bitcoin.
19  Other / Beginners & Help / Re: Whats the best way to get my bitcoin site noticed? on: April 15, 2013, 11:21:52 AM
You can advertise here on Bitcointalk.org: https://bitcointalk.org/index.php?topic=172934.0
20  Other / Off-topic / Re: Let's Count to 21 Million with Images on: April 15, 2013, 10:11:12 AM
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!