Re: [Bitcoin-development] Developer documentation on bitcoin.org
On Sun, May 11, 2014 at 4:08 AM, Saïvann Carignan saiv...@gmail.com wrote: A new Developer Documentation section should be soon merged on bitcoin.org . Live Preview: http://bitcoindev.us.to/en/developer-documentation GitHub Pull Request: https://github.com/bitcoin/bitcoin.org/pull/393 Bitcointalk Thread: https://bitcointalk.org/index.php?topic=511876.0 Great work! Very nice to see thorough developer documentation on bitcoin.org. I've already been reading it now and then and haven't found any technical issues yet, if I do, I'll let you know. Wladimir -- 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] Allow cross-site requests of payment requests
Would it be a terrible idea to amend BIP 70 to suggest implementors include a Access-Control-Allow-Origin: * response header for their payment request responses? I don't think this opens up any useful attack vectors. It sounds OK to me, although we should all sleep on it for a bit. The reason this header exists is exactly because mobile code fetching random web resources can result in surprising security holes. For this to be useful, someone would have to actually want to fully implement the payment protocol (with its own root cert store, ASN.1 parsing, RSA etc) in browser-sandboxed Javascript rather than just providing a real app for people to download. Is that really going to be popular, though? I think it's unclear. -- 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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
A Java implementation of what is called BIPSS in lack of an official number can be found here: https://github.com/mycelium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/crypto/BipSs.java (passing all test vectors) Which is based on a GF2^8 implementation here: https://github.com/mycelium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/crypto/Gf256.java I think having 3 encoding formats (long/short/compact) is over engineered, and basically only makes implementing the standard a pain in the rear. From a user experience point of view only the long format makes sense, and it is only a few bytes longer than the short version. On Mon, May 5, 2014 at 9:36 PM, Nikita Schmidt nik...@megiontechnologies.com wrote: A fork of Matt's proposal converted to GF(2^8) is here: https://github.com/cetuscetus/btctool/blob/bip/bip-.mediawiki Other changes include: - only six application/version bytes are allocated, which is the minimum to ensure that the encoded form starts with S in all cases; - encoded prefixes are SK/SL for a shared private key (mainnet/testnet) and SS/ST for a shared BIP32 seed; - the only hash function in use is SHA-256, which is the all-purpose hash function in the Bitcoin protocol; - double SHA is used for similarity with Bitcoin, although Jan and I believe single SHA is enough in this application; - bias-less encoding of M and x, because there can't be more than 255 shares over GF(2^8). On 23 April 2014 09:16, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Apr 22, 2014 at 10:33 PM, Tamas Blummer ta...@bitsofproof.com wrote: So you agree, that SSS should not contain specific flag for testnet? Or for that matter not even BIP32 needs them since it is not an address to send to. I think the convention we have so far is that addresses and address relate thing we share normally contain an opaque 'version' identifier which we use to identify the purpose for the data (E.g. network meaning, etc.) and I think its a generally reasonable custom. -- 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 -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ 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
Re: [Bitcoin-development] A statistical consensus rule for reducing 0-conf double-spend risk
Sorry to run on, a correction is needed. A much better approximation requires that the rule-following minority finds the next TWO blocks, so the cost is (total miner revenue of block)*(fraction of hashpower following the rule)^2 So the lower bound cost in this very pessimistic scenario is .0025 BTC, still quite high for one transaction. I guess miner could try to make a business out of mining double-spends, to defray that cost. On 5/11/2014 9:41 PM, Tom Harding wrote: Back up to the miner who decided to include a seasoned double-spend in his block. Let's say he saw it 21 seconds after he saw an earlier spend, and included it, despite the rule. The expected cost of including the respend is any revenue loss from doing so: (total miner revenue of block)*(fraction of hashpower following the rule). So today, if only 1% of hashpower follows the rule (ie a near total failure of consensus implementation), he still loses at least .25 BTC. .25 BTC is about 1000x the typical double-spend premium I'm seeing right now. Wouldn't the greedy-rational miner just decide to include the earlier spend instead -- 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] ECDH in the payment protocol
On Fri, May 09, 2014 at 08:38:22PM +0200, Pieter Wuille wrote: On Fri, May 9, 2014 at 8:13 PM, Peter Todd p...@petertodd.org wrote: I don't think we're going to find that's practical unfortunately due to change. Every payment I make ties up txouts, so if we try to base the atomicity of payments on whether or not the payee decides to broadcast the transaction the payor is stuck with txouts that they can't use until the payee makes up their mind. That leads to lots and lots of nasty edge cases. I haven't talked much about it except for on IRC, but my idea was this: * PaymentACK messages become signed (with the same key as the payment request, or using some delegation mechanism, so that the same key doesn't need to remain online). * Instead of a full Bitcoin transaction, a Payment message contains a scriptSig-less Bitcoin transaction + a limit on its byte size (and perhaps a limit on its sigop count). * The sender sends such a Payment to the receiver before actually signing the transaction (or at least, before revealing the signed form). * The receiver only ACKs if the transaction satisfies the request, is within time limits, isn't unlikely to confirm. * If the sender likes the ACK (the refund and memo fields are intact, the transaction isn't changed, the signature key is valid, ...), he either sends the full transaction (with receiver taking responsibility for broadcasting) or broadcasts it himself. Together, this means that a paymentACK + a confirmed matching Bitcoin transaction can count as proof of payment. Both parties have a chance to disagree with the transaction, and are certain all communicated data (apart from transaction signatures) in both directions happened correctly before committing. It would completely remove the chance that the Bitcoin transaction gets broadcast without the receiver liking it (for legitimate or illegitimate reasons), or without the backchannel functioning correctly. It's also compatible with doing multiple payments in one Bitcoin transaction - you can ask for ACKs from multiple parties before signing the transaction. Of course, the sender can still withhold the signed transaction (in which case nothing happened, but we probably need a second timeout), or the receiver can always claim to have never received the transaction. The sender can broadcast the transaction himself in order to prevent that, after obtaining an ACK. Yeah, with the receiver specifically signing off on the tx I think that's fine. OTOH you still gotta ask if this process is really worth it; do you really need this level of signing off for payments that are only going to be considered fully valid after a confirmation? That's always going to be the case for a large proportion of Bitcoin transactions, and sticking to that model makes upgrades easier and reduces the reasons why receivers would want to reimplement a bunch of Bitcoin-related logic. -- 'peter'[:-1]@petertodd.org 7cf5744be694eea2f20501e6db9d3362428aabd63dda4151 signature.asc Description: Digital signature -- 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
[Bitcoin-development] Prenumbered BIP naming
I've noticed some folks struggling to attach labels to their yet to be numbered BIPs. I'd recommend people call them draft-main author name-what it does like draft-maxwell-coinburning in the style of pre-WG IETF drafts. -- 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] Prenumbered BIP naming
On Monday, 12 May 2014, at 9:53 am, Gregory Maxwell wrote: I've noticed some folks struggling to attach labels to their yet to be numbered BIPs. I'd recommend people call them draft-main author name-what it does like draft-maxwell-coinburning in the style of pre-WG IETF drafts. Why is there such a high bar to getting a number assigned to a BIP anyway? BIP 1 seems to suggest that getting a BIP number assigned is no big deal, but the reality seems to betray that casual notion. Even proposals with hours of work put into them are not getting BIP numbers. It's not exactly as though there's a shortage of integers. Are numbers assigned only to proposals that are well liked? Isn't the point of assigning numbers so that we can have organized discussions about all proposals, even ones we don't like? -- 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] Prenumbered BIP naming
On Mon, May 12, 2014 at 10:01 AM, Matt Whitlock b...@mattwhitlock.name wrote: Why is there such a high bar to getting a number assigned to a BIP anyway? BIP 1 seems to suggest that getting a BIP number assigned is no big deal, but the reality seems to betray that casual notion. Even proposals with hours of work put into them are not getting BIP numbers. It's not exactly as though there's a shortage of integers. Are numbers assigned only to proposals that are well liked? Isn't the point of assigning numbers so that we can have organized discussions about all proposals, even ones we don't like? It isn't a big deal, but according to the process numbers shouldn't be assigned for things that haven't even been publically discussed. If someone wants to create specifications that are purely the product of they own work and not a public discussion— they should feel free to do that, but BIP isn't the process for that. So, since things need to be discussed, it can be useful to have something to call a proposal before other things happen— thats all. The same kind of issue arises elsewhere. -- 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] Allow cross-site requests of payment requests
It sounds OK to me, although we should all sleep on it for a bit. The reason this header exists is exactly because mobile code fetching random web resources can result in surprising security holes. That's fair. From the server perspective, I'd argue that payment requests / payments already need to be publicly accessible endpoints. Current practical use requires support for cross-app/cross-device requests for them. It seems like a reasonable logical extension to explicitly allow for them to be accessed cross-site as well. For this to be useful, someone would have to actually want to fully implement the payment protocol (with its own root cert store, ASN.1 parsing, RSA etc) in browser-sandboxed Javascript rather than just providing a real app for people to download. I think there is still value in fetching the payment request cross-site even if the request payload is validated by a 3rd party using a more conventional TLS/crypto suite. Exposing x.509/RSA/ASN.1/chain verification functionality strikes me as a useful thing browsers could easily offer but that's another discussion entirely but sure it could be done all in JS. In certain environments downloading a real app isn't possible/practical. Is that really going to be popular, though? I think it's unclear. It certainly won't be if there is no ability :) -Andy -- 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] ECDH in the payment protocol
Just a thought. Using the payment protocol for stealth would mean we would likely have to return to backing up wallets all the time would it not? The nonces cannot be derived from your wallet seed and, since they aren't in the blockchain, would have to be stored in your wallet. I suppose they could be stored on the server, but you would probably want a backup for that anyway. So we would end up having to back up all the time, something we're trying to get away from. Am I correct about this? On 05/09/2014 02:38 PM, Pieter Wuille wrote: On Fri, May 9, 2014 at 8:13 PM, Peter Todd p...@petertodd.org wrote: I don't think we're going to find that's practical unfortunately due to change. Every payment I make ties up txouts, so if we try to base the atomicity of payments on whether or not the payee decides to broadcast the transaction the payor is stuck with txouts that they can't use until the payee makes up their mind. That leads to lots and lots of nasty edge cases. I haven't talked much about it except for on IRC, but my idea was this: * PaymentACK messages become signed (with the same key as the payment request, or using some delegation mechanism, so that the same key doesn't need to remain online). * Instead of a full Bitcoin transaction, a Payment message contains a scriptSig-less Bitcoin transaction + a limit on its byte size (and perhaps a limit on its sigop count). * The sender sends such a Payment to the receiver before actually signing the transaction (or at least, before revealing the signed form). * The receiver only ACKs if the transaction satisfies the request, is within time limits, isn't unlikely to confirm. * If the sender likes the ACK (the refund and memo fields are intact, the transaction isn't changed, the signature key is valid, ...), he either sends the full transaction (with receiver taking responsibility for broadcasting) or broadcasts it himself. Together, this means that a paymentACK + a confirmed matching Bitcoin transaction can count as proof of payment. Both parties have a chance to disagree with the transaction, and are certain all communicated data (apart from transaction signatures) in both directions happened correctly before committing. It would completely remove the chance that the Bitcoin transaction gets broadcast without the receiver liking it (for legitimate or illegitimate reasons), or without the backchannel functioning correctly. It's also compatible with doing multiple payments in one Bitcoin transaction - you can ask for ACKs from multiple parties before signing the transaction. Of course, the sender can still withhold the signed transaction (in which case nothing happened, but we probably need a second timeout), or the receiver can always claim to have never received the transaction. The sender can broadcast the transaction himself in order to prevent that, after obtaining an ACK. -- 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
[Bitcoin-development] Bitcoin Fee Formula Proposal
This was originally submitted to the bitcoin github issue manager. I'm re-posting here. I propose the transaction fee should be calculated from a percentage of the input amount divided by the confirmations of the input multiplied by the number of inputs. By using a percentage of the input amount the transaction fee will always make sense no matter what the price of bitcoins may be in fiat; by dividing the fee by the number of confirmations we discourage hasty spends and reward savings (ie. old inputs); by multiplying the fee by the number of inputs we discourage payment fragmenting. Let me further explain payment fragmenting by way of an example: Let's say I get paid $2,500 in bitcoins per month from my job. If I then take that $2,500 and pay for a coffee (right away, 1 confirmation) I'll be charged a fee of $2.50 because I'm charged according to the *input amount*, not the actual transaction size. Because of this it would behove my employer to pay me the $2,500 as one transaction with, perhaps, 100 output addresses at $25 apiece so that when I pay for my coffee I use one of the $25 unspent outputs. By multiplying the transaction fee be the number of inputs this provides a disincentive for payment fragmenting as multiple inputs will be required to pay for larger purchases. Furthermore this provides an incentive for wallet software to use the oldest input(s) which most closely match the transaction amount. For the example above: In real life a user's wallet would have a number of inputs to choose from and wouldn't use the newest paycheck input for the coffee purchase. Furthermore, even if the $2,500 input was the only input available, by waiting for 100 confirmations (less than a day) the transaction fee would be 2.5 cents. Transaction fees would then be calculated by the following formula: ((INPUT_AMOUNT * BASE_PERCENT) / CONFIRMATIONS) * NUMBER_OF_INPUTS The INPUT_AMOUNT, CONFIRMATIONS and NUMBER_OF_INPUTS would be determined by the creator of the transaction and should be optimized for the transaction amount -- the BASE_PERCENT would be hard-coded in the bitcoind software. The special case of zero CONFIRMATIONS will be treated as 1 confirmation in order to avoid a divide by zero error. For example: if I choose a BASE_PERCENT of 0.1% and one input it will cost: - $1 to send $1,000,000 that has 100 confirmations; - $0.10 (10 cents) to send $1,000,000 that has 1,000 confirmations (approx. 1 week); - $0.10 (10 cents) to send $100 which has 1 confirmation; - $0.01 (1 cent) to send $100 which has 10 confirmations; - $0.001 (1/10 cent) to send $100 which has 100 confirmations (less than a day); I've put together a spreadsheet which shows the various fees by amount and confirmations -- the spreadsheet assumes one input for a transaction: https://docs.google.com/spreadsheets/d/1ovAQfxksQmOq3zYf79qFEDPCrSx58SmyK3Uwpu8iTUs/edit?usp=sharing -- 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] Bitcoin Fee Formula Proposal
What about 0 confirmation inputs? Mightn't this make tiny spam transactions unsafely inexpensive? On May 12, 2014, at 20:21, Peter Grigor pe...@grigor.ws wrote: I propose the transaction fee should be calculated from a percentage of the input amount divided by the confirmations of the input multiplied by the number of inputs. smime.p7s Description: S/MIME cryptographic signature -- 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
