Re: [Bitcoin-development] 2-way pegging (Re: is there a way to do bitcoin-staging?)
Some comments. On 3/16/14, Adam Back wrote: > 6. a fraud proof is an SPV proof with a longer chain showing that the proof > of burn was orphaned. As discussed, "reorg proof" it's a more appropriate term since the reorg can happen without any fraud. It also prevents the term from being confused with the fraud proof that auditors (full nodes that can't create blocks) produce for private chains. > Apart from pegging from bitcoin to a side-chain, if a private chain is made > with same rules to the side-chain it becomes possible with some > modifications to the above algorithm to peg the side-chain to a private > chain. Private chain meaning a chain with the same format but signature of > single server in place of hashing, and timestamping of the block signatures > in the mined side chain. And then reactive security on top of that by full > nodes/auditors trying to find fraud proofs (rewrites of history relative to > side-chain mined time-stamp or approved double-spends). The reaction is to > publish a fraud proof and move coins back to the side chain, and then > regroup on a new server. (Open transactions has this audit + reactive > model > but as far as I know does it via escrow, eg the voting pools for k of n > escrow of the assets on the private server.) I also proposed the same > reactive audit model but for auditable namespaces [4]. > > Private chains add some possiblity for higher scaling, while retaining > bitcoin security properties. (You need to add the ability for a user to > unilaterally move his coins to the side-chain they came from in event the > chain server refuses to process transactions involving them. This appears > to be possible if you have compatible formats on the private chain and > side-chain). In this case you can't require a side chain proof of burn to move back to the side chain or the funds could be locked by the dishonest private chain operator (accountant in freimarkets[1] terminology). By allowing unilateral withdrawals, you impose on the private chain the task of observing the side chain looking for double-spends, censoring those transactions or maybe updating its committed utxo when it has proofs that the coins have been withdrawn. [1] http://freico.in/docs/freimarkets.pdf https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#private-ledgers -- Jorge Timón http://freico.in/ -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 2-way pegging (Re: is there a way to do bitcoin-staging?)
So an update on 1-way pegging (aka bitcoin staging, explained in quoted text at bottom): it turns out secure 2-way pegging is also possible (with some bitcoin change to help support it). The interesting thing is this allows interoperability in terms of being able to move bitcoin into and out of a side chain. The side chains may have some different parameters, or experimental things people might want to come up with (subject to some minimum compatibility at the level of being able to produce an SPV proof of a given form). At the time of the 1-way peg discussion I considered 2-way peg as desirable and it seemed plausible with bitcoin changes, but the motivation for 1-way peg was to make it less risky to make changes on bitcoin, so that seemed like a catch-22 loop. Also in the 2-way peg thought experiment I had not realized how simple it was to still impose a security firewall in the 2-way peg also. So Greg Maxwell proposed in Dec last year a practically compact way to do 2-way pegging using SPV proofs. And also provided a simple argument of how this can provide a security firewall. (Security firewall means the impact of security bugs on the side-chain is limited to the people with coins in it; bitcoin holders who did not use it are unaffected). [1] How it works: 1. to maintain the 21m coins promise, you start a side-chain with no in-chain mining subsidy, all bitcoin creation happens on bitcoin chain (as with 1-way peg). Reach a reasonable hash rate. (Other semantics than 1:1 peg should be possible, but this is the base case). 2. you move coins to the side-chain by spending them to a fancy script, which suspends them, and allows them to be reanimated by the production of an SPV proof of burn on the side-chain. 3. the side-chain has no mining reward, but it allows you to mint coins at no mining cost by providing an SPV proof that the coin has been suspended as in 2 on bitcoin. The SPV proof must be buried significantly before being used to reduce risk of reorganization. The side-chain is an SPV client to the bitcoin network, and so maintains a view of the bitcoin hash chain (but not the block data). 4. the bitcoin chain is firewalled from security bugs on the side chain, because bitcoin imposes the rule that no more coins can be reanimated than are currently suspend (with respect to a given chain). 5. to simplify what they hypothetical bitcoin change would need to consider and understand, after a coin is reanimated there is a maturity period imposed (say same as fresh mined coins). During the maturity period the reanimation script allows a fraud proof to spend the coins back. A fraud bounty fee (equal to the reanimate fee) can be offered by the mover to incentivize side-chain full nodes to watch reanimations and search for fraud proofs. 6. a fraud proof is an SPV proof with a longer chain showing that the proof of burn was orphaned. There are a few options to compress the SPV proof, via Fiat-Shamir transform to provide a compact proof of amount work contained in a merkle tree of proofs of work (as proposed by Fabien Coelho link on http://hashcash.org/papers/) with params like 90% of work is proven. But better is something Greg proposed based on skip-lists organized in a tree, where 'lucky' proofs of work are used to skip back further. (Recalling that if you search for a 64-bit leading-0 proof-of-work, half the time you get a 65-bit, quarter 66-bit etc.) With this mechanism you can accurately prove the amount of proof of work in a compressed tree (rather than ~90%). Apart from pegging from bitcoin to a side-chain, if a private chain is made with same rules to the side-chain it becomes possible with some modifications to the above algorithm to peg the side-chain to a private chain. Private chain meaning a chain with the same format but signature of single server in place of hashing, and timestamping of the block signatures in the mined side chain. And then reactive security on top of that by full nodes/auditors trying to find fraud proofs (rewrites of history relative to side-chain mined time-stamp or approved double-spends). The reaction is to publish a fraud proof and move coins back to the side chain, and then regroup on a new server. (Open transactions has this audit + reactive model but as far as I know does it via escrow, eg the voting pools for k of n escrow of the assets on the private server.) I also proposed the same reactive audit model but for auditable namespaces [4]. Private chains add some possiblity for higher scaling, while retaining bitcoin security properties. (You need to add the ability for a user to unilaterally move his coins to the side-chain they came from in event the chain server refuses to process transactions involving them. This appears to be possible if you have compatible formats on the private chain and side-chain). This pegging discussion involved a number of #bitcoin-wizards, Greg Maxwell, Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freide
Re: [Bitcoin-development] Electrum 1.9.8 release
Thanks again for having a look. Given these problems, I have decided to remove the encryption methods from the current release. I retagged 1.9.8 and updated the packages. Thomas Le 16/03/2014 15:39, Gregory Maxwell a écrit : > On Sun, Mar 16, 2014 at 7:31 AM, Thomas Voegtlin wrote: >> thanks for your feedback! >> >> I was not aware that that implementation was flawed. >> I will see how I can fix that code and get back to you. > It also leaks on the order of 7 bits of data about the message per > message chunk. I'm also think it's likely that there are some > messages which are just incorrectly decrypted. ... it's really > screwy and suspect. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 1.9.8 release
On Sun, Mar 16, 2014 at 7:31 AM, Thomas Voegtlin wrote: > thanks for your feedback! > > I was not aware that that implementation was flawed. > I will see how I can fix that code and get back to you. It also leaks on the order of 7 bits of data about the message per message chunk. I'm also think it's likely that there are some messages which are just incorrectly decrypted. ... it's really screwy and suspect. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 1.9.8 release
thanks for your feedback! I was not aware that that implementation was flawed. I will see how I can fix that code and get back to you. Thomas Le 16/03/2014 14:54, Gregory Maxwell a écrit : > On Sun, Mar 16, 2014 at 6:24 AM, Thomas Voegtlin wrote: >> The encryption algorithm is ECIES, and code was was borrowed from >> https://github.com/jackjack-jj/jeeq. In order to know the public >> key corresponding to a Bitcoin address in your wallet, you can use >> the 'getpubkeys' command. The 'decrypt' command assumes that the >> wallet has the private key corresponding to the public key passed as >> argument. > The cryptosystem in that repository appears to be insecure in several > ways and is not actually implementing ECIES. > > The most important of which is that instead of using a > cryptographically strong mac tied to the ephemeral secret it uses a > trivial 16 bit check value. This means that that I can decode an > arbitrary message encrypted to a third person if they allow me to make > no more than 65536 queries to a decryption oracle to decrypt some > other message. > > Also, in the event that a random query to a decryption oracle yields a > result (1:2^16 times) the result directly reveals the ECDH value > because it is only additively combined with the message value. If the > implementation does not check if the nonce point is on the curve (an > easy implementation mistake) the result can yield a point on the twist > instead of the curve which is far more vulnerable to recovery of the > private key. ECIES uses a KDF instead of using the ECDH result > directly to avoid this. > > There may be other problems (or mitigating factors) as it was very > hard for me to follow what it was actually doing. > > (The particular implementation has a number of other issues, like > apparently not using a cryptographically strong RNG for its EC nonce.. > but I assume you didn't copy that particular flaw) -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 1.9.8 release
On Sun, Mar 16, 2014 at 6:24 AM, Thomas Voegtlin wrote: >The encryption algorithm is ECIES, and code was was borrowed from >https://github.com/jackjack-jj/jeeq. In order to know the public >key corresponding to a Bitcoin address in your wallet, you can use >the 'getpubkeys' command. The 'decrypt' command assumes that the >wallet has the private key corresponding to the public key passed as >argument. The cryptosystem in that repository appears to be insecure in several ways and is not actually implementing ECIES. The most important of which is that instead of using a cryptographically strong mac tied to the ephemeral secret it uses a trivial 16 bit check value. This means that that I can decode an arbitrary message encrypted to a third person if they allow me to make no more than 65536 queries to a decryption oracle to decrypt some other message. Also, in the event that a random query to a decryption oracle yields a result (1:2^16 times) the result directly reveals the ECDH value because it is only additively combined with the message value. If the implementation does not check if the nonce point is on the curve (an easy implementation mistake) the result can yield a point on the twist instead of the curve which is far more vulnerable to recovery of the private key. ECIES uses a KDF instead of using the ECDH result directly to avoid this. There may be other problems (or mitigating factors) as it was very hard for me to follow what it was actually doing. (The particular implementation has a number of other issues, like apparently not using a cryptographically strong RNG for its EC nonce.. but I assume you didn't copy that particular flaw) -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] mailing list to get news ONLY about new releases
Hi everyone. Is there a mailing list where I can get only notifications about NEW releases of bitcoin-qt client? So far I've found only RSS subscription here: https://bitcoin.org/en/rss/releases.rss RSS is not convinient at all for me.. Many thanks. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Electrum 1.9.8 release
I am happy to announce the release of Electrum 1.9.8. This release includes some features initially planned for version 2.0. Packages are available on https://electrum.org/download.html (signed by me) Binaries for windows and mac will be available in the coming days enjoy Thomas --- RELEASE NOTES # Release 1.9.8 (This release includes features initially planned for version 2.0) * Electrum servers were upgraded to version 0.9. The new server stores a Patrica tree of all UTXOs, an idea proposed by Alan Reiner in the bitcointalk forum. This property allows the client to directly request the balance of any address. The new commands are: 1. getaddressbalance 2. getaddressunspent 3. getutxoaddress * In addition, two commands for message encryption were added: 1. encrypt 2. decrypt The encryption algorithm is ECIES, and code was was borrowed from https://github.com/jackjack-jj/jeeq. In order to know the public key corresponding to a Bitcoin address in your wallet, you can use the 'getpubkeys' command. The 'decrypt' command assumes that the wallet has the private key corresponding to the public key passed as argument. * The encrypt and decrypt functions are available in the Qt GUI (from the menubar, or right click on one of your addresses if you want to use its public key). * Command-line commands that require a connection to the network spawn a daemon, that remains connected and handles subsequent commands. The daemon terminates itself if it remains unused for more than one minute. The purpose of this is to make scripting more efficient. For example, a bash script using many electrum commands will open only one connection. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] External IP Address
Sam, On Sun, Mar 16, 2014 at 8:04 AM, Sam Michaels wrote: > You can look for X-Client-Update to see if the check in was logged. Other > information can be passed in the header, too. > > Errors are trapped so that it will always display the IP address and any > error information is contained in the headers. > > Hope you find this useful. > Thanks for your effort. However the current idea is to phase out reliance on centralized external services completely in favor of peer-based address detection. See https://github.com/bitcoin/bitcoin/pull/3461 Wladimir -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] External IP Address
Hello devs. I was poking around in the code for a small project and I came across the function GetMyExternalIP() in net.cpp. The comment says you'd like to phase out the current method. I threw together exactly what was asked in the comments: it's a site that has PHP echo the IP address. Additionally, it captures the IP, user agent, and time for analysis (a client with the same IP and user agent just updates the entry). The site for the client is: ip.bitcheck.us. It does a quick search for "Mozilla" in the user agent to redirect browers that go there. The following information is sent: --- GET / HTTP/1.1 Host: ip.bitcheck.us User-Agent: /Satoshi:0.8.6/ Connection: close --- And following is received: --- HTTP/1.1 200 OK Date: Sun, 16 Mar 2014 05:31:51 GMT Server: Apache mod_fcgid/2.3.10-dev X-Powered-By: Satoshi v1.0 X-Client-Update: yes Content-Length: 9 Connection: close Content-Type: text/html 127.0.0.1 --- You can look for X-Client-Update to see if the check in was logged. Other information can be passed in the header, too. Errors are trapped so that it will always display the IP address and any error information is contained in the headers. Hope you find this useful. Sam -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
