Re: [Bitcoin-development] Are Instant Confirmations safe?
Den 18 mar 2015 23:38 skrev Dennis Sullivan dennis.jm.sulli...@gmail.com : Hello. This is my first time posting to this list. I wanted to ask your opinions on something relating to confirmation times. I recently read about a transaction locking proposal which claims to make it possible to accept 0-conf transactions with guarantee they will get mined. This seems rather dubious to me, because if there was merit to the system, I would have already expected to see discussion on this list regarding it. Sounds like it would be weak to sybil attacks (deterministically choosing my own nodes sounds great!), and of course Finney attacks (single-block reversal) and defecting miners (what are you gonna do, punish miners with limited network connectivity as well? You'll risk forking the network). Zero-conf is only safe if nobody's actively trying to attack you. It has no inherent security in and of itself. For low values the risk is usually tolerated. For large values there's too much risk of making yourself a target. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proof of Payment
Den 13 mar 2015 20:57 skrev Kalle Rosenbaum ka...@rosenbaum.se: Hi all, I've been thinking about how a person can prove that she has made a payment. I came up with an idea I call Proof of Payment (PoP) and I would highly appreciate your comments. Has something like this been discussed somewhere before? Use cases There are several scenarios in which it would be useful to prove that you have paid for something. For example: A pre-paid hotel room where your PoP functions as a key to the door. An online video rental service where you pay for a video and watch it on any device. An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. During this period you can upload new content to the sign whenever you like using PoP. A lottery where all participants pay to the same address, and the winner of the T-shirt is selected among the transactions to that address. You exchange the T-shirt for a PoP for the winning transaction. These use cases can be achieved without any personal information (no accounts, no e-mails, etc) being involved. Desirable properties: A PoP should be generated on demand. It should only be usable once to avoid issues due to theft. It should be able to create a PoP for any payment, regardless of script type (P2SH, P2PKH, etc.). Relevant: https://idemix.wordpress.com/ Anonymous Credentials allows an issuer to declare that you have certain rights. For example, upon paying the service provider could issue you the credentials for using their service up until a certain date. When challenged to prove a statement about what credentials you have, you can prove the fact that you've got the right credentials without revealing anything else. You don't even reveal you're the same person as the last time, if you prove the right to access a VPN multiple times there's no data in it that links the different sessions together. The main difference is that issuance of Anonymous Credentials aren't atomic with the payment transactions, which can open up the risk for certain types of dishonest behavior by the seller. You could however use a proof in court of having paid for the credentials but not getting them issued to you (maybe throw in usage of Factom to log issuance of credentials?). With this construction of using both these methods, you add stronger privacy for the usage of the services while simultaneously keeping a degree of accountability for the payment. The Zerocoin developers also got a paper on a blockchain version, Distributed Anonymous Credentials. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
Den 12 mar 2015 19:52 skrev Andreas Schildbach andr...@schildbach.de: I'm afraid this will never fly. Wallets are just too different and that's a good thing! For example, by design choice Bitcoin Wallet and bitcoinj doesn't support multiple accounts. How would it ever import wallets from MultiBit or Mycelium? I think I covered that with the importing wallet says what sections it supports part. Then you'd only ask for the library to give you the addresses from the first branch in the main HD wallet. The user would be told that you by design can't manage the other parts. The user would be alerted and get the recommendation to send the funds over manually if they want to switch their wallet. The user might however just want to export that one single branch if he's a power user, so he would proceed to use it that way. At export, I recommend the wallet will tell the user what extensions and standards are in use (and which are necessary to recover how much of their funds in the target wallet). The user would be asked to confirm that the target wallet client supports these. The user should be given the option to hand the list of supported functionality in the target wallet (like a list of BIP numbers?), and tell the wallet to move the funds around so that the target wallet can successfully import everything and recover all funds. Actually, thinking about it I think what we really need first is a standard synchronization / transition protocol. Right now we don't have more than the address label syncing plugin for Electrum. We need something for wallets to synchronize state, with the option for having one wallet tell the other how to send over all funds (for when they use completely different standards for managing funds). As the most simple option, the target wallet would provide a list of addresses to the sending wallet when you switch (this would satisfy Bryan's request). -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
Den 12 mar 2015 17:48 skrev Mike Hearn m...@plan99.net: b) Creation date is just a short-term hack. I agree, but we need things to be easy in the short term as well as the long term :) The long term solution is clearly to have the 12 word seed be an encryption key for a wallet backup with all associated metadata. We're heading in that direction one step at a time. Unfortunately it will take time for wallets to start working this way, and all the pieces to fall into place. Restoring from the block chain will be a semi regular operation for users until then. This have been mentioned a few times before, and what I think is necessary is to create a common file format that can be interpreted by a library which all wallets can use. I see it as similar as the work to create libconsensus for parsing the blockchain. We need something extensible that can describe how to derive all addresses used by the user. What HD branches to derive and how, with block numbers (or bloom filters of block hashes or similar) to note where all previously known transactions related to the wallet have occurred, and the last known block (so only new blocks need to be scanned). A way to describe one HD tree as a multisignature wallet tied to a hardware wallet if you have that (could include serial number or MAC of the device for simple identification by the wallet client). A way to describe another set of addresses as using a custom extension. A way to denote one private key as being used for stealth addresses together with details for how to identify the transactions (prefix, mailbox to look in, etc). Labels for transactions. P2SH script templates so those addresses can be recovered. A way to describe Copay style multisignature wallets and what server to use for coordinating with the other coowners. A way to describe threshold crypto group signature wallets and how to coordinate. Computer parsable descriptions of HD branches as change addresses, as being used for receiving payments in merchant payment systems, etc... Also, you should really be talking to people like accountants and auditors to see what features they'd like to see when it comes to things like how company wallets could have rules defined for how to use the various HD branches. And so on... I think you get my point by now. The basic idea is that the wallet uses the library to parse the wallet file and tells the user which sections it understands (can't expect all wallets to handle custom extensions or stealth addresses, etc), then proceeds to scan the blockchain for those addresses. Then the user also won't be surprised that not all funds are found and won't think they're lost. I think it should be referred to as an import/export format, more than as a backup format. You always want the most recent metadata the wallet of origin can provide when importing, to reduce unnecessary extra work. You don't want really old backup files. If people add new seeds and various new extensions that can't be automatically recovered from old wallet backups, they need new backups. You might as well use the wallet's own internal formats for backup, as the wallet developer might better know how to optimize for the use cases he have designed for. But at the same time we should ask wallet developers to offer conversion tools to generate export format files from custom wallet data files. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bip44 GPG identities - POC demo
Den 8 mar 2015 02:36 skrev Pavol Rusnak st...@gk2.sk: On 07/03/15 16:53, Mem Wallet wrote: [...] I am currently in process of implementing a SignIdentity message for TREZOR, which will be used for HTTPS/SSH/etc. logins. See PoC here: https://github.com/trezor/trezor-emu/commit/9f612c286cc7b8268ebaec4a36757e1c19548717 The idea is to derive the BIP32 path from HTTPS/SSH URI (by hashing it and use m/46'/a'/b'/c'/d' where a,b,c,d are first 4*32 bits of the hash) and use that to derive the private key. This scheme might work for GPG keys (just use gpg://u...@host.com for the URI) as well. Reminds me of FIDO's U2F protocol. http://fidoalliance.org/specifications https://www.yubico.com/products/yubikey-hardware/fido-u2f-security-key/ It ties into the browser SSL session to make sure only the correct server can get the correct response for the challenge-response protocol, so that credentials phishing is blocked and worthless. A unique keypair is generated for each service for privacy, so that you can't easily be identified across services from the usage of the device alone (thus safe for people with multiple pseudonyms). -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Den 23 feb 2015 08:38 skrev Andy Schroder i...@andyschroder.com: I agree that NFC is the best we have as far as a trust anchor that you are paying the right person. The thing I am worried about is the privacy loss that could happen if there is someone passively monitoring the connection. So, in response to some of your comments below and also in response to some of Eric Voskuil's comments in another recent e-mail: From the sources I can find NFC don't provide full privacy, but some modulations are MITM resistant to varying degrees, some aren't at all, and they are all susceptible to denial of service via jammers. If the merchant system monitors the signal strength and similar metrics, a MITM that alters data (or attempts to) should be detectable, allowing it to shut down the connection. Using NFC for key exchange to establish an encrypted link should IMHO be secure enough. http://resources.infosecinstitute.com/near-field-communication-nfc-technology-vulnerabilities-and-principal-attack-schema/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
Den 22 feb 2015 13:36 skrev Peter Todd p...@petertodd.org: Implementing it as a general purpose scripting language improvement has a lot of advantages, not least of which is that you no longer need to rely entirely on inherently unreliable P2P networking: Promise to never create two signatures for a specific BIP32 root pubkey and make violating that promise destroy and/or reallocate a fidelity bond whose value is locked until some time into the future. Since the fidelity bond is a separate pool of funds, detection of the double-spend can happen later. Somebody sent me a zero-confirmation transaction, or one that got orphaned after one block. I created a transaction spending that UTXO, and another. So at that point I have UTXO_orphaned based on the sender's UTXO_origin and my UTXO_old (because I've had it unspent for a long time), both in one transaction, creating UTXO_new. Now he doublespend UTXO_origin to create a UTXO_doublespend (which conflicts with UTXO_orphaned). He conspires with a miner to get it into a block. Now what? Can my UTXO_old effectively be tainted forever because UTXO_new got invalidated together with UTXO_orphaned? Will that transaction be a valid proof of doublespend against a new UTXO_replacement I created? Or otherwise, if only transactions where all UTXO's are currently valid works as doublespend proofs, aren't you still just left without protection against any one miner that conspires with doublespend attempting thieves? In other words, you are unprotected and potentially at greater risk if you create a transaction depending on another zero-confirmation transaction. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
Den 22 feb 2015 14:29 skrev Natanael natanae...@gmail.com: Den 22 feb 2015 13:36 skrev Peter Todd p...@petertodd.org: Implementing it as a general purpose scripting language improvement has a lot of advantages, not least of which is that you no longer need to rely entirely on inherently unreliable P2P networking: Promise to never create two signatures for a specific BIP32 root pubkey and make violating that promise destroy and/or reallocate a fidelity bond whose value is locked until some time into the future. Since the fidelity bond is a separate pool of funds, detection of the double-spend can happen later. Somebody sent me a zero-confirmation transaction, or one that got orphaned after one block. I created a transaction spending that UTXO, and another. So at that point I have UTXO_orphaned based on the sender's UTXO_origin and my UTXO_old (because I've had it unspent for a long time), both in one transaction, creating UTXO_new. Now he doublespend UTXO_origin to create a UTXO_doublespend (which conflicts with UTXO_orphaned). He conspires with a miner to get it into a block. Now what? Can my UTXO_old effectively be tainted forever because UTXO_new got invalidated together with UTXO_orphaned? Will that transaction be a valid proof of doublespend against a new UTXO_replacement I created? Or otherwise, if only transactions where all UTXO's are currently valid works as doublespend proofs, aren't you still just left without protection against any one miner that conspires with doublespend attempting thieves? In other words, you are unprotected and potentially at greater risk if you create a transaction depending on another zero-confirmation transaction. Additional comments: If you punish the creation of UTXO_replacement, you will punish people who was lead to think zero-confirmation transactions were safe and thus that chains of zero-confirmation transactions also were safe. If you don't, but STILL accept chains of zero-confirmation transactions were not all of them are covered by fidelity bonds, then you failed to protect yourself against thieves who creates chains of unconfirmed transactions. Another question: if all transactions in the chain are covered by fidelity bonds for their own value, which one pays out to who? Does only the first one pay out, and only to the last party in the chain? Or to every subsequent party after him? In full or just a fraction? Why, why not? You might not know which of these serviced their customers in full without getting full value back in exchange due to the doublespend. What if the fidelity bond is too small, do you stop accepting it as a zero-confirmation transaction? Do you even accept chains of unconfirmed transactions at all? -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
Den 22 feb 2015 17:00 skrev Justus Ranvier justusranv...@riseup.net: On 02/22/2015 07:50 AM, Matt Whitlock wrote: This happened to one of the merchants at the Bitcoin 2013 conference in San Jose. They sold some T-shirts and accepted zero-confirmation transactions. The transactions depended on other unconfirmed transactions, which never confirmed, so this merchant never got their money. I keep telling people not to accept transactions with zero confirmations, but no one listens. A better solution is to track the failure rate of zero confirmation transactions, and adjust prices accordingly to cover the expected loss. This is what every merchant *already does* since no payment method has a 0% fraud rate. Even physical cash has a probability of being counterfeit, and the prices you pay for things at a convenience store already have that risk priced in. The idea that zero confirmation transactions require a 100% guarantee is a strawman, especially since there exists no number of confirmations the actually produce a 100% irreversibility guarantee. The problem with this approach is that it is worthless as a predictor. We aren't dealing with traffic safety and road design - we are dealing with adaptive attackers and malicious miners and pools. Anything which does not invalidate blocks carrying doublespends WILL allow malicious miners and pools to conspire with thieves to steal money. The probability of being hit will then be (their proliferation in your business area) * (their fraction of the mining power). That might seem to give small numbers for most sets of reasonable assumptions. But the problem is that's only an average, and the people being hit might have small profit margins - one successful attack can place hundreds of merchants in red numbers and force them to shut down. You should never expose yourself to attacks which you can't defend against and which can be fatal. In particular not if there's nothing in the environment that is capable of limiting the size or numbers of any attacks. And there's no such thing today in Bitcoin. This is why I sketched out the multisignature notary approach, and why some decided to extend that approach with collateral (NoRiskWallet) to further reduce trust in the notary. This is the single most practical approach I know of today to achieve ACTUAL SECURITY for unconfirmed transactions. Don't like it? See if you can do better! Just don't rely on zero-confirmation transactions! -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
- Sent from my tablet Den 22 feb 2015 17:25 skrev Justus Ranvier justusranv...@riseup.net: You just disproved your own argument. It is possible to predict risk, and therefore to price the risk. Your fault is that you assume the predictions can be reliable and trustable. They can not be. The data you have available has none of the indicators you actually NEED to make predictions. You're making extrapolations from the past, not calculations based on recent trends and behavior globally. You also noted that for some Bitcoin users, the price of that risk is too high for the types of transactions in which wish to engage. In what way does that translated into a universal requirement for everybody to use multisignature notaries? It isn't universal. It is just the most practical solution if you need instant confirmation for high value transactions with customers you don't yet trust. Surely the users who can afford the risk can use zero conf if they like, and those who can't can use multisig notaries? Use whatever you want. I don't care. I will warn you about the risks and make suggestions, but I won't force you to do anything differently. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 8:52 PM, Justus Ranvier justusranv...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 07:47 PM, Allen Piscitello wrote: Nothing will stop that. Bitcoin needs to deal with those issues, not stick our heads in the sand and pretend they don't exist out of benevolence. This isn't a pet solution, but the rules of the protocol and what is realistically possible given the nature of distributed consensus. Relying on altruism is a recipe for failure. If there's a risk of fire burning down wooden buildings, pass out fire extinguishers and smoke detectors, not matches. The latter makes one an arsonist. Controlled fires is a valid tactic when necessary to reduce harm. It is frequently used in areas with periods of extreme heat including Australia. By burning off grids, you isolate the majority of flammable matter into islands. An accident fire would cause much more damage. Placing yourself in the way of the fire and asking them to find another solution isn't that bright. It is only a matter of time until a fire starts, controlled or not! If you want another solution, go figure one out yourself! More to the point, it is unreasonable to knowingly expose yourself to risk of harm and blame everybody else who isn't making your life easier without you having to change anything. If the majority decides that the best option to reduce harm for everybody requires that you move out of the way and find another way to do things, you're better off moving. Telling people it is fine to keep being careless when there's a fire hazard is the real crime, because that would cause more harm than what those who try to get the system changed does. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Den 12 feb 2015 14:44 skrev Mike Hearn m...@plan99.net: You can prove a doublespend instantly by showing two conflicting transactions both signed by thar party. This pair can be distributed as a proof of malice globally in seconds via a push messaging mechanism. There have been lots of e-cash schemes proposed in the academic literature that work like this, or variants of it. Schemes where participants are anonymous until they double spend are popular. Let's re-write your proposal but substituting the word notary for miner: To profit, the miner would have to be sure the payout from agreeing on collusion (or to perform the doublespend themselves) would pay out better than acting honestly for a given amount of time info the future. This means transactions for small sums are secure. That's the exact argument we're having. The assertion is that a rational notary would kill his own business to increase his profits in the next few hours. So you're just arguing that a notary is different to a miner, without spelling out exactly why. Does the notary have to make a big up front investment? If so, why is that different to mining investment? Miners are transient. You don't depend on any given subset of them. Centralized e-currency give you no choice but to trust one set of notaries. The notary don't have any large maintenance costs. The initial investment is small, they don't need more than a few servers and maybe a HSM and some office. In the non-collateral version, they're a centralized entity. Note that in the fully centralized model, if the notary goes bad you're screwed. Your tokens are useless or maybe gone. Essentially you can't know if you're up for the long con or not. Anybody can set up a miner with capital investments. No individual miner has a large impact on the system as a whole. In Bitcoin, you aren't dependent on any one multisignature notary. One going gown only represents a small loss and done temporarily locked funds. Anybody can set up a multisignature notary, but people won't trust you unless you show you're trustable - you need to market yourself to get to the point where a malicious doublespend can be profitable. You can't really replicate the collateralized multisignature notary model in centralized systems. Because having the e-currency bank be the notary means they have the same powers a 51% miner would have - they can block the transaction claiming the collateral, they can censor any other transactions at will, and all your funds depend on them and the market's trust in them. Is the notary non-anonymous and afraid of being charged with payment fraud? If so, note that big miners do lots of non-anonymous things too, like renting warehouses and importing specialised equipment. As notaries can be small operations, they can perform the doublespend as they escape across the border. Is it because of the big up front collateral they're meant to have lying around? If so, how do you ensure a fluid market for notaries? With collateralized multisignature notaries, my assumption is that organizations that are related to Bitcoin transactions that has sufficient sums of unallocated funds would use them for collateral in a scheme like this (almost every large organization in the world have some unallocated funds somewhere). As sellers have almost no risk of losing money to them, any notary backed by somebody they know and trust would be good enough As buyers also have no risk, they'd use them when they want to make quick payments. - You seem to be making a lot of arguments from the status quo. I don't care what people have been doing, preserving every habit isn't a sacred goal. I care about stable incentives and long term predictability regarding what behavior is safe. Behavior that becomes unsafe if incentives change is bad and shouldn't be relied on. Also, Bitcoin is the concensus mechanism. As mentioned, trying to provide a guarantee for what will end up in the blocks without servers involved is to reinvent Bitcoin within Bitcoin. I can go Xzibit on you all day long if you like! What you consider an attack is irrelevant. You assume a certain behavior is desired without first making sure it is reliable. Depending on that which isn't guaranteed is bd, and breaking other people's assumptions is by itself NOT an attack if there never was a guarantee or even as little as an implicit understanding it is safe. Your also assume people will expect the Bitcoin network to keep zero-conf safe forever and that Bitcoin valuation is tied to that. Given the options available and current state of things, I'm assuming that's wrong. Besides, zero-conf will never be secure if you don't add external contextual information as a requirement when validating blocks. Otherwise defecting miners will frequently doublespend against you. And adding such information is messy and probably not secure in itself, as it opens up for gaming the system through network level attacks. And your remarks
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Den 12 feb 2015 13:49 skrev Mike Hearn m...@plan99.net: Are you not counting collateralized multisignature notaries? Its an extended version of the Greenaddress.it model. It makes unconfirmed transactions useless in the classical Bitcoin model. Obviously if you introduce a trusted third party you can fix things, but then you're back to having the disadvantages of centralised trust. That trust you put in them is extremely limited, and temporary. First of all, the standard multisignature notary model applies like how I originally described it in my blog post over a year ago. You can prove a doublespend instantly by showing two conflicting transactions both signed by thar party. This pair can be distributed as a proof of malice globally in seconds via a push messaging mechanism. After confirmation in the blockchain, you have standard Bitcoin transaction security. To profit, the notary would have to be sure the payout from agreeing on collusion (or to perform the doublespend themselves) would pay out better than acting honestly for a given amount of time info the future. This means transactions for small sums are secure. To provide security for high value transactions, NRW adds a collateral transaction that the notary stands for and signs in advance, and gives to the seller. The key here is that it is constructed such that if the original payment gets doublespent, then this collateral transaction to the seller becomes spendable. So there is two outcomes - either the customer or the notary pays the seller. The customer can't force a doublespend. The notary can't steal or freeze funds (due to nlocktime fund recovery option). The seller knows he'll get the funds for sure before delivering the goods. Nobody is at risk. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Den 12 feb 2015 12:58 skrev Mike Hearn m...@plan99.net: [...] Your scorched earth plan is aptly named, as it's guaranteed to make unconfirmed payments useless. Are you not counting collateralized multisignature notaries? Its an extended version of the Greenaddress.it model. NoRiskWallet: https://github.com/baleato/bitcoin-hackathon -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Den 12 feb 2015 15:53 skrev Mike Hearn m...@plan99.net: So you're just arguing that a notary is different to a miner, without spelling out exactly why. I'm afraid I still don't understand why you think notaries would build long term businesses but miners wouldn't, in this model. I think you are saying because notaries have identity, brand awareness and because they have big up front bonds, that means they will be trustworthy. Miners aren't contractors, they don't have to care about repeat business. Individual miners don't have enough impact to have a negative impact on their own capital investment. Zero-conf transactions also aren't that tied to the Bitcoin valuation. Multisignature notaries need to convince people to select them. They want to know that even with collateral, their funds won't be temporarily locked up and unspendable for days at a time. What services would miners provide here, do you think? Well, sure. It's the same model governments use and is why being a money transmitter in the USA is so difficult: you need to put up large sums of money as collateral and have your fingerprints taken 48 times. Then you can start advertising to get customers! Obviously you need to have collateral to provide collateral. Can't make cryptographic verifiable guarantees if you don't have the resources to back them. The reason mining is such a nice model is it doesn't have these sorts of requirements. And also can't make these assurances. Any minority miner can be overrun. As notaries can be small operations . [snip] .. (almost every large organization in the world have some unallocated funds somewhere). Which is it? Are notaries small operations or large operations? The operation itself is small. A few people maintaining a few servers. The collateral needed depends on how many and how large simultaneous transactions they want to provide assurances for, so they can chose to be a small player for one niche market or large and global if they have the funds for it. I think exploring new consensus models with semi-trusted notaries is interesting, but it's not Bitcoin. Methods for decentralized consensus that aren't PoW also aren't Bitcoin. Please don't try and apply this logic in the real world :( Rephrased: That's a nice house. I noticed it's made of wood. I'm going to start fires until it burns down, because there is no guarantee your house won't burn down in future and it's important you understand that wooden houses aren't safe. Really I'm just doing you a favour. Actually that IS often a bad idea. But fortunately the risk and threat is low, and mitigation is well understood. I'm really not a fan of Peter's approach, which is hey let's try and cause as many problems as possible to try and prove a point, without having created any solutions. Replace-by-fee-scorched-earth doesn't work and isn't a solution. Miners can easily cut payment fraudsters in on the stolen money, and as they'd need to distribute custom double-spending wallets to make the scheme work it'd be very easy to do. Security analysis requires having the mindset of an attacker. Sometimes that reveals suboptimal choices. Then you want them changed to more stable choices such that once the incentives change, the risk already is gone. Minimization of damage, simply put. Your also ssume people will expect the Bitcoin network to keep zero-conf safe forever and that Bitcoin valuation is tied to that. Given the options available and current state of things, I'm assuming that's wrong. Why? You think ability to make payments in a few seconds is some irrelevant curiousity? No. But you can't be certain it is secure without having a solid reliable mechanism to provide such a guarantee. You want zero-conf to stay safe without involvement of servers? Then please, try to find a way to secure it. Right now you're assuming it can remain safe based on circumstances which can change and assumptions about market participant's valuations that likely aren't true. Let's put it this way. If BitPay's business model evaporates tomorrow, along with all the merchants they support, do you think that'd have any effect on Bitcoin's value? If not, why not? It would. They'd tank. But you're assuming too much about the basis for valuation. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Den 12 feb 2015 16:15 skrev Mike Hearn m...@plan99.net: The first is that this setup means miners can steal arbitrary payments if they work together with the sender of the money. The model assumes this collaboration won't happen, but it will. Because no existing wallet has a double spend this button, to make the scheme work the dishonest miners must create and distribute such a wallet that implements the whole scorched-earth protocol. At that point it's easy for miners to reward the payment fraudster with some of the stolen money the merchant lost, meaning it now makes sense for the fraudster to always do this. The situation isn't stable at all. The second is that it incentivises competitors to engage in payment fraud against each other. A big rich coffee shop chain that is facing competition from a small, scrappy newcomer can simply walk into the new shop and buy things, then trigger the scorched earth. Even with no miner collaboration, this means the big company is down the cost of the product but so is the little company who lost everything. Whoever can outspend the other wins. We don't really need game theory to tell us that this plan is a bad idea. Just imagine trying to explain it to an actual shop keeper. They would think you were crazy. Bitcoin is already a hard enough concept to understand without throwing into the mix anyone can burn the money they gave you after walking out of the shop. I see no fundamental difference in outcome from miner collusion in scorched-fee (which isn't guaranteed to pay the right pool!) and miner collusion in knowingly mining a doublespend transaction. Both outcomes pay the miner and thief equally when successful. The merchant loses in both. Zero-conf needs something else for security. A guarantee it can not be doublespent in the relevant time frame. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Den 12 feb 2015 16:42 skrev Mike Hearn m...@plan99.net: Remember that you aren't paying the bad pool, the bad pool is paying you. Whichever pool benefits from the scorched earth protocol can simply pick an address out of the transaction it perceived as starting the protocol, and pay that. My counterargument: with zero-conf but no replace-by-fee scorched earth, there would instead be a market which thieves use where pools would offer to execute doublespends that pay the thief and the pool, and where the pools would set what terms and payouts they ask for. All bidding pools with acceptable terms get a doublespend transaction that pays that specific pool and the thief, the first to mine theirs win (and the merchant loses). Your protocol requires less setup, but that's the only notable difference (besides risk of paying non-participating pools with scorched earth). No notable difference in security for merchants. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header
Den 11 feb 2015 09:55 skrev Hector Chu hector...@gmail.com: A proposal for stemming the tide of mining centralisation -- Requiring a miner's signature in the block header (the whole of which is hashed), and paying out coinbase to the miner's public key. Please comment on whether this idea is feasible, has been thought of before, etc., etc. Thank you. Motivation -- Mining is centralising to a handful of pool operators. This is bad for a number of political reasons, which we won't go into right now. But I have always believed that some years down the line, they could hold the users hostage and change the rules to suit themselves. For instance by eliminating the halving of the block reward. [...] I propose that we require each miner to sign the block header prior to hashing. The signature will be included in the data that is hashed. Further, the coinbase for the block must only pay out to the public key counterpart of the private key used to sign the block header. [...] This will make it difficult to form a cooperating pool of miners who may not trust each other, as the block rewards will be controlled by disparate parties and not by the pool operator. Only a tight clique of trusted miners would be able to form their own private pool in such an environment. People already trust things like cloud mining, so your solution with increasing technical trust requirements won't help. But you will however break P2Pool instead. Also, note that threshold signatures (group signatures) could probably be used by an actual distrusting pool's miners. There are already a proof of concept for this implemented with secp256k1 that works with Bitcoin clients silently. This wouldn't prevent such a pool from working. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)
BIP70 is a protocol for getting a user's wallet client communicate with a merchant's server in order to agree on details like where to send the payment, how much to send, what the shipping address is, sending a receipt back, and much more using various extensions that adds more functionality. There could even be advanced functionality for automatically negotiating terms. One example could be selecting a multisignature arbitrator both sides trust. Another could be to agree on the speed and type of delivery. Many more types of decisions could be automatically agreed upon. But as it is now, it is designed to be initiated at the time of payment. If you always want next-day delivery from online stores then you won't always know if that's an option until you've filled the digital basket and gone through checkout. If you only want to shop with an arbitrator involved same thing applies. Everything that BIP70 enables happens at the last step only, as it is right now. If there could be a BIP70 HTML tag on web shops that automatically triggered your wallet as soon as you visit the page, it would be possible for a browser extension that talks to your wallet to tell you right away if the web shop you're currently looking at has terms you consider acceptable or not (note: if your wallet client isn't installed on or linked to that same machine, a visible Qr code would be an acceptable alternative which you can scan in advance before you start shopping). This notification can even be automatically updated as you add and remove things from your cart and details like shipping options change. This would massively simplify the shipping experience and make every web shop feel like Amazon. Of course this has privacy implications and increases exposure to potential wallet exploits, but the wallet can ask you if you intend to shop or not at each site before it even connects and send any information at all in order to mitigate both of those problems. This way it should be reasonably safe. Another option would be to automatically connect but limit what data is sent in order to remain privacy preserving, until the user agrees to send private information. This second method would also open up for the merchant to other send relevant information such as details about various certifications from third parties, which can include a certification that shows they have been been audited and approved by by entity X for purpose Y. If your wallet has that entity whitelisted it will show you that certificate (for example Acme Audits have audited and approves of Merchant M's privacy policy and data protection). With a list of predefined types of certifications that the wallet understand and accepts, it could (by choice of the user) require a certificate to be present to even allow you to make a purchase (lack of required certifications would result in automatic denial). No certificate = your wallet never proceed to send private information. Thoughts? - Sent from my tablet -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)
Den 10 feb 2015 11:34 skrev MⒶrtin HⒶboⓋštiak martin.habovst...@gmail.com : Why would anyone want to do anything about payment before choosing what he wants to buy and for what price? I've never used Amazon but isn't filling a form with shipping information enough? That's not what this is about. BIP70 isn't just payment, it is about communication the terms of the sale. Let's say you're visiting an international webshop. But they don't ship to your country. Wouldn't you want to know that before your start filling the cart? With this, your wallet / browser extension could tell you right away that you can't shop there. No time wasted! That's just one requirement of many where you would benefit from being told right away if it is acceptable for both parties or not. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)
Den 10 feb 2015 11:48 skrev MⒶrtin HⒶboⓋštiak martin.habovst...@gmail.com : I still don't understand. The website can have this information available. This is exactly what e-bay does - it displays shipping information to my country before I do anything. What's the problem? Also with other stuff, website can do it and browser extension can do it too without messing with Bitcoin. 1: IP isn't guaranteed to work correctly both because you might be using a VPN out Tor. 2: Yes, the site can display all options right away, but are you willing to read all of them too? 3: Detailed information is not necessary, nor does it have to be unprompted. It doesn't need to tell you more than which country you are in. It can even prompt you with a popup that has a slider that shows exactly how much information and of what kind you're about to share (including none, if that's your choice). 4: It doesn't need to share raw data. Take a look at anonymous credentials: http://www.zurich.ibm.com/idemix/ https://eprint.iacr.org/2013/622.pdf 5: It can wait for prompting until you add the first item to the cart. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
Den 31 jan 2015 23:17 skrev Brian Erdelyi brian.erde...@gmail.com: Hello all, The number of incidents involving malware targeting bitcoin users continues to rise. One category of virus I find particularly nasty is when the bitcoin address you are trying to send money to is modified before the transaction is signed and recorded in the block chain. This behaviour allows the malware to evade two-factor authentication by becoming active only when the bitcoin address is entered. This is very similar to how man-in-the-browser malware attack online banking websites. Out of band transaction verification/signing is one method used with online banking to help protect against this. This can be done in a variety of ways with SMS, voice, mobile app or even security tokens. This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE. Many Bitcoin wallets and services already use Open Authentication (OATH) based one-time passwords (OTP). Is there any interest (or existing work) in in the Bitcoin community adopting the OATH Challenge-Response Algorithm (OCRA) for verifying transactions? I know there are other forms of malware, however, I want to get thoughts on this approach as it would involve the use of a decimal representation of the bitcoin address (depending on particular application). In the HSBC example (see YouTube video above), this was the last 8 digits of the recipient’s account number. Would it make sense to convert a bitcoin address to decimal and then truncate to 8 digits for this purpose? I understand that truncating the number in some way only increases the likelihood for collisions… however, would this still be practical or could the malware generate a rogue bitcoin address that would produce the same 8 digits of the legitimate bitcoin address? See vanitygen. Yes, 8 characters can be bruteforced. You need about 100 bits of security for strong security, and at the very least NOT less than ~64 (see distributed bruteforce projects attacking 64 bit keys for reference, you can find plenty via Google). You shouldn't rely on mechanisms intended to be used for one-shot auth where the secret is supposed to be unguessable for another system where the attacker knows what the target string is and have a fair amount of time to attempt bruteforce. Use something more like HMAC instead. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
Den 1 feb 2015 00:05 skrev Brian Erdelyi brian.erde...@gmail.com: See vanitygen. Yes, 8 characters can be brute forced. Thank you for this reference. Interesting to see that there is a tool to generate a vanity bitcoin address. I am still researching viruses that are designed to manipulate a bitcoin address. I suspect they are primitive in that they use a hardcoded rogue bitcoin address as opposed to dynamically generating one. As a start, this would help protect against malware that uses a static rogue bitcoin address. The next thing would be for the malware to brute-force the legitimate bitcoin address and generate a rogue bitcoin address that would produce the same 8 digit code. Curious to know how long this brute force would take? Or perhaps, before converting to 8 digits there is some other hashing function that is performed. Brian Erdelyi To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000 tries. log(50M)/log(2) = 25.6 bits of entropy. One try = generate a random number, use it to generate an ECDSA keypair, SHA256 and RIPEMD160 hash the public key per Bitcoin specs, then run that OCRA hashing code, then compare strings. Considering the ECDSA operations is by a large margin slower than all the hash functions, consider them to just add a small percentage in performance drop vs regular vanitygen usage. My non-gaming laptop performed IIRC at *a few million keys per second* with OpenCL. I've used it to search for 6 character strings in the base58 Bitcoin addresses with it in 15 minutes to half an hour or so. That's about 35 bits of entropy (rough estimate, there's some details with padding in the base58 representation that alters it). So 2^(35-26) ~= 1 in 500 of that time, and that's if you use a laptop instead of a GPU rig. Seconds at worst. Milliseconds if done on a rig. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
Den 1 feb 2015 00:37 skrev Natanael natanae...@gmail.com: To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000 tries. log(50M)/log(2) = 25.6 bits of entropy. Oops. Used the wrong number in the entropy calculation. Add one bit, the division by 2 wasn't supposed to be used in the entropy calculation. Doesn't change the equation much, though. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Time
Probably because the network isn't designed for interactive proofs. Most interactive algoritms AFAICT requires that some machine holds a secret state (or at least continuous and untampered state, but you still need to verify you're falling to the right machine), otherwise the machine can be mimicked and rewound to earlier states. Without a challenge-response that can't be faked, you've got problems. There's no trusted machines here that you can rely on. The certainty of having the right blockchain is a statistical one over longer periods of time, not enough for a PIN you want verified right now. So you can always be shown an old copy, and if your node isn't up to date yet then it can also be shown fake chains further into the future. Maybe you could throw in some kind of Secure Multiparty Computation among the miners to enable challenge-response, with state saved in the blockchain (so it can't be rolled back), but that would be fragile. How do you select what nodes may participate? How do you prevent the secret state from leaking? And performance would be absolutely horrible, and reliability is a huge problem. Den 25 jul 2014 18:03 skrev Mike Hearn m...@plan99.net: Sorry, you're right. I'd have hoped a delay that doubles on failure each time up to some max would be good enough, relying on the p2p network to unlock a PIN feels weird, but I can't really quantify why or what's wrong with it so I guess it's just me :-) On Fri, Jul 25, 2014 at 4:45 PM, Aaron Voisine vois...@gmail.com wrote: The problem is if someone moves system time forward between app launches. The lockout period doesn't have to be all that precise, it just makes you wait for the next block, then 5, then 25, and so on. Using a well known time server over https would also be a good option, but the wallet app already has the chain height anyway. On Friday, July 25, 2014, Mike Hearn m...@plan99.net wrote: Given that the speed at which the block chain advances is kind of unpredictable, I'd think it might be better to just record the time to disk when a PIN attempt is made and if you observe time going backwards, refuse to allow more attempts until it's advanced past the previous attempt. On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine vois...@gmail.com wrote: It's based on the block height, not the block's timestamp. If you have access to the device and the phone itself is not pin locked, then you can jailbreak it and get access to the wallet seed that way. A pin locked device however is reasonably secure as the filesystem is hardware aes encrypted to a combination of pin+uuid. This was just an easy way to prevent multiple pin guesses by changing system time in settings, so that isn't the weakest part of the security model. Aaron Voisine breadwallet.com On Thu, Jul 24, 2014 at 8:21 PM, William Yager will.ya...@gmail.com wrote: On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@gmail.com wrote: Is breadwallet tamper resistant zero on tamper hardware? otherwise this sounds like security theater I attach a debugger to the process (or modify the program) and ignore the block sourced time. It's an iOS application. I would imagine it is substantially more difficult to attach to a process (which, at the very least, requires root, and perhaps other things on iOS) than to convince the device to change its system time. That said, the security benefits might not be too substantial. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Aaron Voisine breadwallet.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub!
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
Den 17 jun 2014 17:59 skrev Isidor Zeuner cryptocurrenc...@quidecco.de: quote: Mike Hearn, why don't we just have all nodes report attempted double spends through the node network. No need to involve the miners at all really, or do your suggestion but also report the double spend attempt. By waiting maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can be more sure that a double spend attack was not tried. Attacker would have to hold back second tx by 10-60 seconds and hope that that second tx (with higher fee) get's into a solved block before the first one. This forced delay time ought to make the attack less successful (but not impossible). What prevents the following steps from happening: 1. attacker sends first transaction, paying to the merchant 2. merchant waits 10-60 seconds 3. merchant confirms the payment as received 4. attacker sees merchant's confirmation 5. attacker sends double spend The security improvement seems to be pretty much exactly the chance that during the 10-60 seconds, a block is solved. Am I missing something? Regarding reporting double spends, this would only help if it comes with some kind of penalty for the double spend. Now what if the double spend was not done on malicious motives? Maybe someone posted a transaction which does not confirm for some reason, and wants to recover his funds? Should we regard transactions which do not confirm as forever lost, in order to get to an every double spend is a misbehaviour policy? Best regards, Isidor With 2-of-2 multisignature notaries, the doublespend (the set of conflicting transactions) would be published and propagated together as evidence of the notary being malicious. This is trivial and self-evident self-contained proof. But there should be no direct penalty IMHO in the Bitcoin protocol itself. If a transaction would have to be replaced honestly because of being wrong or simply not confirming, then I think there should be some means of showing the second transaction is legitimate. Don't ask me how exactly it would work in practice, but one method could be through showing the original recipients have signed off on it (showing they agree it should be reversed). If you can't get the original recipient to sign, then you're stuck with either not replacing it or the notary trying to prove the replacing transaction was legitimate. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Paper Currency
Now you are talking about Trusted Platform Modules. Like smartcards, actually. Devices that won't leak their keys but let the holder spend the coins. It could even have it's own simple SPV wallet client to make it easier to handle. And they'd use the attestation features provided by the TPM to prove the software it's unmodified top the current holder. But then you still have to trust the manufacturer of the device, and you have to trust it has no exploitable side channels. - Sent from my phone Den 18 maj 2014 13:52 skrev Alex Kotenko alexy...@gmail.com: I had a long discussion recently with somebody who wants and has resources to do exactly this - paper currency representing bitcoins. Yet we've been thinking mostly about a centralized solution, where one party is producing and maintaining paper currency, with bitcoins tied to each note verifiable via blockchain. The points we've ended up is that it needs to be: - reloadable - NFC based So anybody can verify any notes instantly by just touching it with his phone, and so merchants could redeem the notes at the moment of accepting it, convert it into fully online bitcoins and avoid costs of maintaining paper money turnover. Probably merchant would sell back redeemed empty notes to the issuer for a price of the note issue, and issuer will recharge it and put back into circulation. One problem we couldn't figure out here though - how to protect the notes from unauthorized redeem. Like if someone else tries to reach your wallet with his own NFC - how can we distinguish between deliberate redeem by owner and fraudulent redeem by anybody else with custom built long range NFC antenna? Any ideas? Best regards, Alex Kotenko 2014-05-17 17:40 GMT+01:00 Gregory Maxwell gmaxw...@gmail.com: On Sat, May 17, 2014 at 9:07 AM, Chris Pacia ctpa...@gmail.com wrote: I can't really just hand someone the note and walk away because they have to scan it to see if it is actually valid. Not just scan it, but they actually must successfully sweep it— otherwise they can be trivially double spent. This is especially bad since any prior bearer can perform such an attack. E.g. record the private key of everyone that passes through your hands and then doublespend race any redemption that happens 24 hours after you spend them. The wrong person would likely be blamed and even if you were blamed you could plausibly deny it (Must have been the guy that gave it to me!). Othercoin seems to have much better properties in the space of offline transactions: https://bitcointalk.org/index.php?topic=319146.0 Separately, Cassius also ran into some regulatory issues selling physical bitcoin artifacts. Especially printing things that seem to be redeemable for a named USD value sounds especially problematic. Some random comments— The base58 encoding is fairly human unfriendly. It's fine for something being copy and pasted, but I've found typing or reading it works poorly due to mixed case. I expect the A/B side to be difficult to educate users about. This side is private is more easily understood, you could just pick one of your sides and call it private. I find it kind of odd that this design seems to have no facility for checking its txouts without recovering the private key, though considering no one should rely on such a measurement without sweeping perhaps thats for the best. (As far as the numbering goes, I think you should be calling these draft-felix-paper-currency etc. As a matter of hygienic practice I will not assign a matching bip number for something that went public with a number outside of the assignment.) -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run
Re: [Bitcoin-development] Paper Currency
The problem with not involving any electronics is that somebody needs to generate a recoverable private key that we have to trust haven't recovered the private key. The only plausible solution is multisignature P2SH addresses where you trust several independent entities to not collude instead, where you combine their paper notes into one piece. And then you still don't know if all the private keys are recoverable to you (failed print?). - Sent from my phone Den 18 maj 2014 20:48 skrev Alex Kotenko alexy...@gmail.com: Erm, few things here. - I can't see really how to embed electronics capable to run an SPV client into printed paper. I know that passive NFC tags can be printed on paper, but not actual chips and/or power modules. So we are talking about a completely different things here. - even with paper notes printed proprietarily by some business the notes itself still can have routes for independent blockchain-based verification, and you won't need to trust anybody to test it. You will have to trust security of the notes itself, but this is same as when you trust the phone manufacturer when you're putting your bitcoin wallet on it. So really I see only issues of technical security in here, and this is the problem I'm seeking solutions for. Best regards, Alex Kotenko 2014-05-18 14:50 GMT+01:00 Natanael natanae...@gmail.com: Now you are talking about Trusted Platform Modules. Like smartcards, actually. Devices that won't leak their keys but let the holder spend the coins. It could even have it's own simple SPV wallet client to make it easier to handle. And they'd use the attestation features provided by the TPM to prove the software it's unmodified top the current holder. But then you still have to trust the manufacturer of the device, and you have to trust it has no exploitable side channels. - Sent from my phone Den 18 maj 2014 13:52 skrev Alex Kotenko alexy...@gmail.com: -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bits: Unit of account
I am in favor of xbit, my only concern is if average Joes will consider that name stupid (like various attempts at cool branding with unusual letters like Q, X, Z, etc). We should see if we can get support for it in the community and if there would be any notable opposition against it or not. If there's no significant opposition and most people are in favor, I'd say go ahead. - Sent from my phone Den 21 apr 2014 11:38 skrev Tamas Blummer ta...@bitsofproof.com: Thomas V: Your proposal misses the points that: - this is about a unit with 1e-6 Bitcoins or 100 satoshis. - it is not about people who know Bitcoin and are techies, but about those who don’t and aren’t. The reasons for such a unit are more than shifting the comma some places for convinience, but to align Bitcoin with capabilities of existing financial software and customs of finance and average people, and ISO standard of currency abbreviations. bit and XBT seems to check the boxes. I would love to have some feedback on xbit as per my previous mail. Regards, Tamas Blummer http://bitsofproof.com -- 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 http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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 http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] secure assigned bitcoin address directory
Does't BIP70 cover this already via Certificate Authorities? On Mon, Mar 31, 2014 at 12:21 PM, vv01f vv...@riseup.net wrote: Some users on bitcointalk[0] would like to have their vanity addresses available for others easily to find and verify the ownership over a kind of WoT. Right now they sign their own addresses and quote them in the forums. As I pointed out there already the centralized storage in the forums is not secury anyhow and signed messages could be swapped easily with the next hack of the forums. Is that use case taken care of in any plans already? I thought about abusing pgp keyservers but that would suit for single vanity addresses only. It seems webfinger could be part of a solution where servers of a business can tell and proof you if a specific address is owned by them. [0] https://bitcointalk.org/index.php?topic=502538 [1] https://bitcointalk.org/index.php?topic=505095 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] secure assigned bitcoin address directory
This sounds like Namecoin. You can already register profiles with it, including keypairs. onename.io is a web-based client you can use to register on the Namecoin blockchain. On Mon, Mar 31, 2014 at 1:14 PM, Chris D'Costa chris.dco...@meek.io wrote: Security of transmission of person-to-person pay-to addresses is one of the use cases that we are addressing on our hardware wallet. I have yet to finish the paper but in a nutshell it uses a decentralised ledger of, what we refer to as, device keys. These keys are not related in any way to the Bitcoin keys, (which is why I'm hesitating about discussing it here) neither do they even attempt to identify the human owner if the device. But they do have a specific use case and that is to provide advanced knowledge of a publickey that can be used for encrypting a message to an intended recipient, without the requirement for a third-party CA, and more importantly without prior dialogue. We think it is this that would allow you to communicate a pay-to address to someone without seeing them in a secure way. As I understand it the BlockChain uses time bought through proof of work to establish a version of the truth, we are using time in the reverse sense : advanced knowledge of all pubkeys. Indeed all devices could easily check their own record to identify problems on the ledger. There is of course more to this, but I like to refer to the distributed ledger of device keys as the Web-of-trust re-imagined although that isn't strictly true. Ok there you have it. The cat is out of the bag, feel free to give feedback, I have to finish the paper, apologies if it is not a topic for this list. Regards Chris D'Costa On 31 Mar 2014, at 12:21, vv01f vv...@riseup.net wrote: Some users on bitcointalk[0] would like to have their vanity addresses available for others easily to find and verify the ownership over a kind of WoT. Right now they sign their own addresses and quote them in the forums. As I pointed out there already the centralized storage in the forums is not secury anyhow and signed messages could be swapped easily with the next hack of the forums. Is that use case taken care of in any plans already? I thought about abusing pgp keyservers but that would suit for single vanity addresses only. It seems webfinger could be part of a solution where servers of a business can tell and proof you if a specific address is owned by them. [0] https://bitcointalk.org/index.php?topic=502538 [1] https://bitcointalk.org/index.php?topic=505095 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Den 29 mar 2014 19:15 skrev Matt Whitlock b...@mattwhitlock.name: On Saturday, 29 March 2014, at 2:08 pm, Alan Reiner wrote: Regardless of how does it, I believe that obfuscating that information is bad news from a usability perspective. Undoubtedly, users will make lots of backups of lots of wallets and think they remember the M-parameter but don't. They will accidentally mix in some 3-of-5 fragments with their 2-of-4 not realizing they are incompatible, or not able to distinguish them. Or they'll distribute too many thinking the threshold is higher and end up insecure, or possibly not have enough fragments to restore their wallet thinking the M-value was lower than it actually was. I just don't see the value in adding such complexity for the benefit of obfuscating information an attacker might be able to figure out anyway (most backups will be 2-of-N or 3-of-N) and can't act on anyway (because he doesn't know where the other frags are and they are actually in safe-deposit boxes) Okay, you've convinced me. However, it looks like the consensus here is that my BIP is unneeded, so I'm not sure it would be worth the effort for me to improve it with your suggestions. I think it should be made an option (with the default being that the threshold is given and verification is applied. There could certainly be a few cases where the threshold is set high, you maybe don't have access to a great enough variety of hiding spots or secure enough hiding spots, and you want deter an attempt to find all the shares (with the idea being that the risk of detection would be too high, in particular when you use tamper evident seals). But for the majority it would be better to find a few different safeboxes to put the shares in and rely on physical security. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
Regarding (ISO standards) currency symbols, XBT is already used as equivalent to 1 Bitcoin in numerous places, and XBC is taken and BT* belongs to Bhutan (and X** is already the default for non-national currency common items of trade), so IMHO we should define something like XUB as microbitcoins so we can have a symbol that doesn't require changing any existing systems and that can be standardized globally. Then those with accounting software that needs to deal with something that has two decimals maximum without losing precision can use that while following well defined standards. And those who don't like large numbers can still chose to show mBTC. - Sent from my phone Den 14 mar 2014 18:18 skrev vv01f vv...@riseup.net: I think * if we change to mBTC because your state currencys price for bitcoin make this a valid option we will change again in future * users do not like changes * we should keep a good standard A good standard should be * built on standards (e.g. SI) * backed by best practice: never force the user to take an option he cannot change * do not make changes without users permission * take care of users at fault when entering 5.967 ot should be pointed out before sending that e.g. the sw understood 5967.000 000 00 BTC instead of 5.967 000 00 BTC because the user failed to use the correct delimiter. For now a good standard is * simply bitcoin as BTC with eight decimal places or could be * uBTC as SI prefix, probably using XBT as a symbol for compatibility with other software * satoshis (w. SI prefixes if numbers are to big) for regions where decimal places in prices are uncommon So I'd prefer: Make the choice transparent to users and set a standard that the user alway should be empowered to use all available decimal places. And there should be a set of official test-cases for wallet software and the desired behavior. -- 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 -- 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] New side channel attack that can recover Bitcoin keys
You've heard of TRESOR? No, not Trezor. https://en.wikipedia.org/wiki/TRESOR Signing on the CPU, without touching RAM. - Sent from my phone Den 6 mar 2014 09:41 skrev Mike Hearn m...@plan99.net: I'm wondering about whether (don't laugh) moving signing into the kernel and then using the MTRRs to disable caching entirely for a small scratch region of memory would also work. You could then disable pre-emption and prevent anything on the same core from interrupting or timing the signing operation. However I suspect just making a hardened secp256k1 signer implementation in userspace would be of similar difficulty, in which case it would naturally be preferable. On Wed, Mar 5, 2014 at 11:25 PM, Gregory Maxwell gmaxw...@gmail.comwrote: On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo elombr...@gmail.com wrote: Everything you say is true. However, branchless does reduce the attack surface considerably - if nothing else, it significantly ups the difficulty of an attack for a relatively low cost in program complexity, and that might still make it worth doing. Absolutely. I believe these things are worth doing. My comment on it being insufficient was only that my signer is branchless doesn't make other defense measures (avoiding reuse, multsig with multiple devices, not sharing hardware, etc.) unimportant. As for uniform memory access, if we avoided any kind of heap allocation, wouldn't we avoid such issues? No. At a minimum to hide a memory timing side-channel you must perform no data dependent loads (e.g. no operation where an offset into memory is calculated). A strategy for this is to always load the same values, but then mask out the ones you didn't intend to read... even that I'd worry about on sufficiently advanced hardware, since I would very much not be surprised if the processor was able to determine that the load had no effect and eliminate it! :) ) Maybe in practice if your data dependencies end up only picking around in the same cache-line it doesn't actually matter... but it's hard to be sure, and unclear when a future optimization in the rest of the system might leave it exposed again. (In particular, you can't generally write timing sign-channel immune code in C (or other high level language) because the compiler is freely permitted to optimize things in a way that break the property. ... It may be _unlikely_ for it to do this, but its permitted— and will actually do so in some cases—, so you cannot be completely sure unless you check and freeze the toolchain) Anyhow, without having gone into the full details of this particular attack, it seems the main attack point is differences in how squaring and multiplication (in the case of field exponentiation) or doubling and point addition (in the case of ECDSA) are performed. I believe using a branchless implementation where each phase of the operation executes the exact same code and accesses the exact same stack frames would not be vulnerable to FLUSH+RELOAD. I wouldn't be surprised. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Regarding chains of transactions intended to be published at once together, wouldn't it be easier to add a only-mine-with-child flag? That way the parent transactions aren't actually valid unless spent together with the transaction that depends on it, and only the original will have a child referencing it. Then malleability is not an issue at all for transaction chains if you only need to broadcast your full transaction chain once, and don't need to extend it in two or more occasions, *after* broadcasting subchains to the network, from the same set of pregenerated transactions. If you need to broadcast pregenerated subchains separately, then you need the last child in the chain to be non-malleable. This would require all miners to start to respect it at once in order to avoid forking the network. - Sent from my phone Den 19 feb 2014 22:13 skrev Pieter Wuille pieter.wui...@gmail.com: On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager grona...@mac.com wrote: I think that we could guarantee fewer incidents by making version 1 transactions unmalleable and then optionally introduce a version 3 that supported the malleability feature. That way most existing problematic implementations would be fixed and no doors were closed for people experimenting with other stuff - tx v 3 would probably then be called experimental transactions. Just to be clear: this change is not directly intended to avoid incidents. It will take way too long to deploy this. Software should deal with malleability. This is a longer-term solution intended to provide non-malleability guarantees for clients that a) are upgraded to use them b) willing to restrict their functionality. As there are several intended use cases for malleable transactions (the sighash flags pretty directly are a way to signify what malleabilities are *wanted*), this is not about outlawing malleability. While we could right now make all these rules non-standard, and schedule a soft fork in a year or so to make them illegal, it would mean removing potential functionality that can only be re-enabled through a hard fork. This is significantly harder, so we should think about it very well in advance. About new transaction and block versions: this allows implementing and automatically scheduling a softfork without waiting for wallets to upgrade. The non-DER signature change was discussed for over two years, and implemented almost a year ago, and we still notice wallets that don't support it. We can't expect every wallet to be instantly modified (what about hardware wallets like the Trezor, for example? they may not just be able to be upgraded). Nor is it necessary: if your software only spends confirmed change, and tracks all debits correctly, there is no need. -- Pieter -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
You could pregenerate entire trees of alternative outcomes where you pick one branch / chain to broadcast based on the real world events as they happen. But I see another problem regarding use of oracles, if you have a P2SH address with 2-of-3 signatures or similar in the chain, amd some transactions following it, then the oracle needs to pregenerate both transactions for both outcomes in advance. But the oracle probably don't want to actually share it in advance to any third party before the event happened. This can be solved if the oracle only shares the transaction hash in advance and then hands out a Zero-knowledge proof of that transaction with the given hash is following the agreed upon rules, so you can trust the transaction chain anyway and still being able to pregenerate a full tree of transactions. And then the oracle will release one of the possible transactions after the event in question has happened, so you can broadcast the chain of choice. This unfortunately breaks down if the number of possible outcomes becomes too many as you would need to both generate and store a tree of possible outcomes that is massive. - Sent from my phone Den 20 feb 2014 02:29 skrev Allen Piscitello allen.piscite...@gmail.com: This is somewhat problematic in my use case since some parts need to be in the chain earlier than others and have the same ID as expected. https://bitcointalk.org/index.php?topic=260898.10 I haven't gone back to see if there are any ways around it, but the main problem here is I need the Contract TX to be in the chain much earlier than redeeming, but I need the refund transaction to be in the chain much earlier. Perhaps there are some tricks to pull off to get it to work, but I haven't been working on this for a while so I'm a bit rusty in that area. This might be helpful enough to help a lot of use cases, but shouldn't be final. -Allen On Wed, Feb 19, 2014 at 6:22 PM, Natanael natanae...@gmail.com wrote: Regarding chains of transactions intended to be published at once together, wouldn't it be easier to add a only-mine-with-child flag? That way the parent transactions aren't actually valid unless spent together with the transaction that depends on it, and only the original will have a child referencing it. Then malleability is not an issue at all for transaction chains if you only need to broadcast your full transaction chain once, and don't need to extend it in two or more occasions, *after* broadcasting subchains to the network, from the same set of pregenerated transactions. If you need to broadcast pregenerated subchains separately, then you need the last child in the chain to be non-malleable. This would require all miners to start to respect it at once in order to avoid forking the network. - Sent from my phone Den 19 feb 2014 22:13 skrev Pieter Wuille pieter.wui...@gmail.com: On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager grona...@mac.com wrote: I think that we could guarantee fewer incidents by making version 1 transactions unmalleable and then optionally introduce a version 3 that supported the malleability feature. That way most existing problematic implementations would be fixed and no doors were closed for people experimenting with other stuff - tx v 3 would probably then be called experimental transactions. Just to be clear: this change is not directly intended to avoid incidents. It will take way too long to deploy this. Software should deal with malleability. This is a longer-term solution intended to provide non-malleability guarantees for clients that a) are upgraded to use them b) willing to restrict their functionality. As there are several intended use cases for malleable transactions (the sighash flags pretty directly are a way to signify what malleabilities are *wanted*), this is not about outlawing malleability. While we could right now make all these rules non-standard, and schedule a soft fork in a year or so to make them illegal, it would mean removing potential functionality that can only be re-enabled through a hard fork. This is significantly harder, so we should think about it very well in advance. About new transaction and block versions: this allows implementing and automatically scheduling a softfork without waiting for wallets to upgrade. The non-DER signature change was discussed for over two years, and implemented almost a year ago, and we still notice wallets that don't support it. We can't expect every wallet to be instantly modified (what about hardware wallets like the Trezor, for example? they may not just be able to be upgraded). Nor is it necessary: if your software only spends confirmed change, and tracks all debits correctly, there is no need. -- Pieter -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls
Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
Because it's trivial to create collisions! You can choose exactly what output you want. That's why XOR is a very bad digest scheme. - Sent from my phone Den 4 feb 2014 14:20 skrev Peter Todd p...@petertodd.org: On Tue, Feb 04, 2014 at 02:13:12PM +0100, Mike Hearn wrote: Hah, good point. If nobody completes the homework, I'll post a fixed version tomorrow :) Heh, here's another 25mBTC while we're at it: https://github.com/opentimestamps/opentimestamps-client/commit/288f3c17626974de7eaef4f1c9b5cd93eecf40f6 Why is that a bad idea? Bonus question: What was I smoking? (hint: where do I live?) On Tue, Feb 4, 2014 at 2:03 PM, Peter Todd p...@petertodd.org wrote: On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote: Hello, I'm pleased to announce the release of bitcoinj 0.11, a library for writing Bitcoin applications that run on the JVM. BitcoinJ is widely used across the Bitcoin community; some users include Bitcoin Wallet for Android, MultiBit, Hive, blockchain.info, the biteasy.com block explorer (written in Lisp!), Circle, Neo/Bee (Cypriot payment network), bitpos.me, Bitcoin Touch, BlueMatt's relay network and DNS crawler, academic advanced contracts research and more. The release-0.11 git tag is signed by Andreas Schildbach's GPG key. The commit hash is 410d4547a7dd. This paragraph is signed by the same Bitcoin key as with previous releases (check their release announcements to establish continuity). Additionally, this email is signed using DKIM and for the first time, a key that was ID verified by the Swiss government. Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m Signature for last paragraph: H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg= The above makes for a great homework problem for budding cryptographers: Why did the three forms of signature, DKIM, long-lived bitcoin address, and Official Swiss Government Identity fail to let you actually verify you have the right code? (but make for great security theater) Bonus question: Who has the smallest work-factor for such an attack? Two rewards of 25mBTC for correct responses to each question from a crypto newbie. Thanks to Mike Belshe, the wallet can now send to P2SH addresses. Thanks Generated signatures now use canonical S values. This will aid a future hard-forking rule change which bans malleable signatures. Soft-forking rule change. -- 'peter'[:-1]@petertodd.org 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 -- 'peter'[:-1]@petertodd.org 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
So far I've only liked the original name Stealth address and the suggestion routing address. Should we put this up for some kind of informal vote with comments allowed? Like a Google docs form? - Sent from my phone Den 17 jan 2014 10:18 skrev Mike Hearn m...@plan99.net: I must say, this shed is mighty fine looking. It'd be a great place to store our bikes. But, what colour should we paint it? How about we split the difference and go with privacy address? As Peter notes, that's what people actually like and want. The problem with stealth is it's got strong connotations with American military hardware and perhaps thieves sneaking around in the night: https://www.google.com/search?tbm=ischq=stealth But everyone loves privacy. On Fri, Jan 17, 2014 at 8:49 AM, Drak d...@zikula.org wrote: Peter I agree with you about reusable addresses, but aren't we also trying to get away from the word address entirely? How about calling it a payment key or reusable payment key instead? using stealth is just asking for bad press imo. On 16 January 2014 21:28, Peter Todd p...@petertodd.org wrote: On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote: Might I propose reusable address. I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'. It definitely packs a marketing punch which could help drive adoption. The feature is only useful if/when broadly adopted. I'm very against the name reusable addresses and strongly belive we should stick with the name stealth addresses. You gotta look at it from the perspective of a user; lets take standard pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many times as I want and everything works just great. I also can enter the address on blockchain.info's search box, and every transaction related to the address, and the balance of it, pops up immediately. What is that telling me? A: Addresses starting with 1 are reusable. B: Transactions associated with them appear to be public knowledge. Now I upgrade my wallet software and it says I now have a reusable address. My reaction is Huh? Normal addresses are reusable, what's special about this weird reusable address thing that my buddy Bob's wallet software couldn't pay. I might even try to enter in a reusable address in blockchain.info, which won't work, and I'll just figure must be some new unsupported thing and move on with my life. On the other hand, suppose my wallet says I now have stealth address support. I'm going to think Huh, stealth? I guess that means privacy right? I like privacy. If I try searching for a stealth address on blockchain.info, when it doesn't work I might think twig on Oh right! It said stealth addresses are private, so maybe the transactions are hidden? I might also think Maybe this is like stealth/incognito mode in my browser? So like, there's no history being kept for others to see? Regardless, I'm going to be thinking well I hear scary stuff about Bitcoin privacy, and this stealth thing sounds like it's gonna help, so I should learn more about that Finally keep in mind that stealth addresses have had a tonne of very fast, and very wide reaching PR. The name is in the public conciousness already, and trying to change it now just because of vague bad associations is going to throw away the momentum of that good PR and slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I based on conversations there with people there, technical and non-technical, almost everyone had heard about them and almost everyone seemed to understand the basic idea of why they were a good thing. That just wouldn't have happened with a name that tried to hide what stealth addresses were for, and by changing the name now we risk people not making the connection when wallet software gets upgraded to support them. -- 'peter'[:-1]@petertodd.org 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740 -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today.