Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
There's some actually proposing inaction as an outright decision, but I more meant that at times it has felt like we would end up with inaction through momentum, combined with adoption rate making any hard fork more complex if it continues to be delayed. On 18/06/2015 22:42, Matt Whitlock wrote: On Thursday, 18 June 2015, at 8:31 pm, Ross Nicoll wrote: I may disagree with Mike Gavin on timescale, but I do believe there's a likelihood inaction will kill Bitcoin An honest question: who is proposing inaction? I haven't seen anyone in this whole, agonizing debate arguing that 1MB blocks are adequate. The debate has been about *how* to increase the block-size limit and whether to take action ASAP (at the risk of fracturing Bitcoin) or to delay action for further debate (at the risk of overloading Bitcoin). Even those who are arguing for further debate are not arguing for *inaction*. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
I'm struggling to illustrate how incredibly low 7 transactions per second is, not just for a payment network, but even just for a clearance network (i.e. to balance transactions between institutions and/or chains). As an example, the Clearing House Interbank Payments System (CHIPS) is a US-only, inter-bank only clearance network, which handled about 3.5 transactions per second (average) in 2014 (https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en). While it seems likely the US population of 300 million makes more transactions individually than many other countries, and therefore we can't simply multiply that by 20 to estimate what a global clearance network might require, hopefully it's clear that if Bitcoin is to scale globally, it needs substantially more transaction throughput even if main chain transactions become something for banks and the super rich. I don't know how much more, but I can't look at the 8MB reportedly backed by a number of mining pools and say it's clearly insufficient, at least. I should emphasise that I don't think we need to jump straight to 8MB (or otherwise), if a scaling protocol can be decided upon that would be ideal, but we should be planning ahead while it's still relatively easy to make these changes. Ross On 18/06/2015 23:33, Mark Friedenbach wrote: On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full. To do that, you need to (a) plan forward, in order to (b) set a hard fork date in the future. Or alternatively, fix the reasons why users would have negative experiences with full blocks, chiefly: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. Not raising the block size limit does not mean doing nothing to solve the problem. -- ___ 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] A suggestion for reducing the size of the UTXO database
I think potential fee subsidies for cleaning up UTXO (and/or penalties for creating more UTXO than you burn) are worth thinking about. As Gavin's post ( gavinandresen.ninja/utxo-uhoh ) indicates, UTXO cost is far higher than block storage, so charging differently for the in/out mismatches should make good economic sense. Ross On 09/05/2015 20:16, Jim Phillips wrote: On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille pieter.wui...@gmail.com mailto:pieter.wui...@gmail.com wrote: It's a very complex trade-off, which is hard to optimize for all use cases. Using more UTXOs requires larger transactions, and thus more fees in general. Unless the miner determines that the reduction in UTXO storage requirements is worth the lower fee. There's no protocol level enforcement of a fee as far as I understand it. It's enforced by the miners and their willingness to include a transaction in a block. In addition, it results in more linkage between coins/addresses used, so lower privacy. Not if you only select all the UTXOs from a single address. A wallet that is geared more towards privacy minded individuals may want to reduce the amount of address linkage, but a wallet geared towards the general masses probably won't have to worry so much about that. The only way you can guarantee an economical reason to keep the UTXO set small is by actually having a consensus rule that punishes increasing its size. There's an economical reason right now to keeping the UTXO set small. The smaller it is, the easier it is for the individual to run a full node. The easier it is to run a full node, the faster Bitcoin will spread to the masses. The faster it spreads to the masses, the more valuable it becomes. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
I'm presuming that schedule is just an example, as you'd end up with insanely large block sizes in a few years. Absolutely, yes, an increase schedule is an option if people agree on it, and I think the better option, as the current limit too low, but jumping straight to a value big enough for indefinitely is a huge jump. Gave some thought to scaling block size based on transaction fees, but suspect it would end up with miners sending huge fees to themselves with transactions that aren't relayed (so they only are actioned if they make it into a block that miner mines) to make the network allow bigger blocks. Ross On 07/05/2015 19:38, Chris Wardell wrote: Instead of raising the block size to another static number like 20MB, can we raise it dynamically? Make the max block size something like: pow(2, nHeight/10) * 1MB; //double every ~2 years -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
Can I just add my own support for this - as has been stated elsewhere in this discussion, hard forks are difficult, and risky. The earlier we have a decision, and the earlier the change goes into the code, the easier that is. Even if the decision was the actual block size change is fine to leave until 2020, I'd like to see the code committed ASAP so that every new install, and every upgrade from there on gets the new version. My personal opinion only is that 7 transactions a second is insanely limited even if the main chain does nothing but act as a backbone between other chains and transaction networks. I don't think that's overly controversial. I think 2016 is too early for a 20mb block size, though. I'm inclined to suggest a schedule of expansion, say to 2mb in 2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it stops. The intent would be to provide enough size pressure to motivate scaling work, while not limiting Bitcoin overly. Further, I think this highlights that we need more work on fees. Right now fees and transactions included are fairly naive, but I'd like to see the absolute block size limit as a hard upper bound, with miners imposing soft limits based on a balance cost of storage, number of outputs vs inputs (and therefore impact on the UTXOs), and risk of orphan blocks to determine which transactions are actually worth including in each block. If anyone has numbers on block size vs orphan rate that would be really useful, BTW. Ross On 07/05/2015 19:06, Mike Hearn wrote: I think you are rubbing against your own presupposition that people must find and alternative right now. Quite a lot here do not believe there is any urgency, nor that there is an immanent problem that has to be solved before the sky falls in. I have explained why I believe there is some urgency, whereby some urgency I mean, assuming it takes months to implement, merge, test, release and for people to upgrade. But if it makes you happy, imagine that this discussion happens all over again next year and I ask the same question. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arriving slightly late to the discussion, apologies. Personally I wouldn't have written that patch, but I know development of hostile patches happens out of sight, and if it can be written, we have to presume it will be written eventually. I'd have preferred a patch that only replaced non-final txes, which is the use-case I have for transaction replacement, but that's easy to add back in. I'm certainly not terribly convinced of the security of vanilla zero-confirmation transactions myself, for reasons including but not limited to this case. I also think it's important to understand that people do make irrational decisions, and trusting network security on everyone behaving perfectly rationally is not a workable model either. TLDR; me too Ross On 12/02/15 20:36, Allen Piscitello wrote: You keep making moral judgements. Reality is, if you live in a world with arsonists, you need to have a building that won't catch on fire, or has fire extinguishers in place. Do not depend on arsonists ignoring you forever as your security model. Penetration testing to know what weaknesses exist, what limitations exist, and what can be improved is essential. Keeping your head in the sand and hoping people choose to do the right thing only ends one way. On Thu, Feb 12, 2015 at 1:52 PM, Justus Ranvier justusranv...@riseup.net wrote: 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. -- 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 -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU31/yAAoJEJFC5fflM8475YIIAI7nxgxUdkKiMePMqtvPOi25 U+WCxjvIK0ZRTAV30POC7fKLT2mK0gPusSS7LtNJpPKvpC98VcSD5HWE49K80Yo9 9+QI7X7xBau1jjLo+27uOex0bJ6JwP1DSMpC12AQbMmi4FnyG+M5FMkr5/OnSxeF cd4lT2UF7yTJPRy0+A9LwertL5Sv1yeOJJ9jtWuXgixapmHN+1Zm2VkGnur55V64 vnonlixlUMwnZNxDVoRhjTWm1P/lmCejvmvTRvcBomUlAEgRQF4TtF4YMBYXS97S 5WYrxOHLgTfTWr3FJuOnd+CVBRgZGw3u30ktaSErelyMG19lJOusBPdHTQFkV30= =eWPj -END PGP SIGNATURE- -- 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] BIP70: why Google Protocol Buffers for encoding?
That was essentially what we did in the end, we replaced the network identifier (main/test) with the genesis block hash. The result is never going to accidentally work with Bitcoin Core (nor vice-versa), but is readily extensible to any other altcoins that want to use the specification without requiring any sort of central registry. Ross On 24/01/15 13:19, Isidor Zeuner wrote: For what it's worth, there was consideration of replacing protocol buffers when modifying BIP70 to function with the altcoin I work on (changes were required anyway in eliminate any risk that payment requests could not be accidentally applied to the wrong blockchain). Why not serialize some kind of blockchain identifier with the messages? Arbitrarily deviating from a given design choice just for the sake of doing it differently may serve the goal of creating more overall code diversity, but would not necessarily serve the quality of the blockchain network where it is done for. Best regards, Isidor -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
For what it's worth, there was consideration of replacing protocol buffers when modifying BIP70 to function with the altcoin I work on (changes were required anyway in eliminate any risk that payment requests could not be accidentally applied to the wrong blockchain). The eventual conclusion was that while we might have used JSON or XML if we were starting from scratch, there's no choice that's clearly better. While deployed infrastructure for payment protocol is still quite limited, it seems that the cost to replace at this point is higher than not. If there's ever a major reworking of the standard, for example to handle recurring payments, it's probably worth thinking about then, but protocol buffers result in a compact data format which is supported by most major languages (and size is a concern if dealing with Bluetooth or NFC), and has no major drawbacks I am aware of. Ross On 19/01/2015 20:40, Mike Hearn wrote: I'm a bit confused. It's been a long time since I looked at protobuf (and will have to dig into it soon), but I seem to recall it doesn't have any of the determinism properties you guys just said. It's not guaranteed no, which is why we store signed sub-messages as byte arrays instead of typed submessages. In practice though, most implementations do seem to serialise things the same way. I recall Python used to be an odd one out, unsure if it still is. OK, I guess we can boil this down more simply. BIP 70 uses protocol buffers because I designed it and implemented the original prototype (with lots of input from Gavin and an earlier proposal by sipa). I used protocol buffers because, beyond all their nice properties, I used to work at Google and so was very familiar with them. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Re-enabling simple tx replacement
Dear all, I've been looking at atomic cross-chain trading ( https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the Bitcoin and Dogecoin blockchains, and have a mostly functional prototype. However as it stands if the refund transaction is relayed before the actual spend transaction, it blocks the legitimate spend transaction from being accepted into the memory pool. I'd like to enable TX replacement in the case where all conflicting transactions are not final, and the replacement is final. While yes, this still leaves scope for unpaid for bandwidth, hopefully being able to do a single replacement isn't a major issue. For those wanting background on this, https://github.com/bitcoin/bitcoin/pull/2516 may be useful reading. I've drafted a patch for this https://github.com/rnicoll/bitcoin/commit/e668d36607f008990ccaac7275e463a6efdd9b5a but have not yet raised a PR, as historically this has lead to a lot of discussion in Github which is better suited to this mailing list. I'm therefore looking for feedback while I continue testing that patch, and any comments would be welcomed. Ross -- 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] Re-enabling simple tx replacement
On 04/01/15 17:04, Gregory Maxwell wrote: On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll j...@jrn.me.uk wrote: Dear all, I've been looking at atomic cross-chain trading ( https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the Bitcoin and Dogecoin blockchains, and have a mostly functional prototype. However as it stands if the refund transaction is relayed before the actual spend transaction, it blocks the legitimate spend transaction from being accepted into the memory pool. Unless there is a serious bug that I am not aware of this is not the case. The unlocked transaction is not relayable and will not be mempooled (well, until right before it locks). Grabbing a simple test case: https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8 - that won't lock until 0028 UTC on the 5th. I've tried closing the wallet, moving the wallet.dat file out of the way, and then attempting the spend transaction (which can be locked immediately), and it either rejects it on acceptance to mempool, or it is never included in a block. Compare with https://chain.so/tx/BTCTEST/0b96eb0c9bf8a6ca08bb9d75e44970889db9c6d3122296c0169959f979cc where the refund was not sent first, and the transaction has succeeded. I've drafted a patch for this https://github.com/rnicoll/bitcoin/commit/e668d36607f008990ccaac7275e463a6efdd9b5a but have not yet raised a PR, as historically this has lead to a lot of discussion in Github which is better suited to this mailing list. I'm therefore looking for feedback while I continue testing that patch, and any comments would be welcomed. This appears to have absolutely no protection against denial of service, it seems to me that a single user can rapidly update their transaction and exhaust the relay bandwidth of the entire network. They can only replace a non-final transaction with a final transaction, so the replacement can happen at most once (any later replacement would be attempting to replace a final transaction, and therefore fails). So, while they can expend twice the bandwidth compared to a non-replacement, I don't think that's a major issue? -- 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] Re-enabling simple tx replacement
On 04/01/15 17:35, Gregory Maxwell wrote: On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll j...@jrn.me.uk wrote: Grabbing a simple test case: https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8 - that won't lock until 0028 UTC on the 5th. I've tried closing the wallet, moving the wallet.dat file out of the way, and then attempting the spend transaction (which can be locked immediately), and it either rejects it on acceptance to mempool, or it is never included in a block. Can you send me the actual raw transaction (that site doesn't appear have a way to get it, only some cooked json output; which doesn't include the sequence number). As I said, it's a severe bug if unlocked transactions are being relayed or mempooled far in advance. Attached. Sequence number for the input is set to 1, please do tell me if I've misunderstood how it's used. They can only replace a non-final transaction with a final transaction, Ah I missed that the replacement had to be final. Thats indeed a much more sane thing to do than I was thinking (sorry for some reason I saw the +1 and thought it was just checking the sequence number was higher.) I don't think that's a major issue? If they can relay the first one to begin with its an an issue, the replacement just makes it twice an issue. :) I'll set up a few nodes tomorrow and double check it's in fact relaying in the latest version. If it's simply an issue of incorrect relaying, that's significantly simpler at least, and the problem can be tackled through that instead. 0100019fbf1e1c6543278795a24a5138cd9eea17a24ff40f246dece6312f0c5fcd6826da00493046022100ee7d395355d2b5504289e4de88cd1694d4fbfb68c6083d2b1d97668f8aecad81022100cbb2def124eaac394d97a3619b1cf723101878105eefc179201ade5651e0ed1e01483045022100ae62d80c3c38a52d27ea649f274c17c0ed438350577b7e22d4d83a780f0c29a302200e9c371c52d9819d6c37b90466fcf3b7b074d92e075bd043d5a16a392fdaed3101522103abd60343437179d12abc40da47c26ad261e2d22f5c89d8af254d4e5dddae11a321020c076f4c121583b2f4ef93e8186d61cd35cecc18d15c5aa993a8759d678c1eb052010001583e0f001976a914098ff5dc58c2c8af6a343a6be9be4a15d0408e5288aca9daa954-- 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] Re-enabling simple tx replacement
On 04/01/15 17:44, Gregory Maxwell wrote: On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com wrote: Can you send me the actual raw transaction (that site doesn't appear have a way to get it, only some cooked json output; which doesn't include the sequence number). Nevermind, I guess. I think I figured out your problem: The behaviour on testnet is busted because the non-mempooling is enforced by IsStandardTx which is bypassed in testnet. We should enforce that elsewhere. This isn't the case on the real network. Ah, thanks for that. I'll try Peter's patch for testnet tomorrow, sounds like it should fix this for my use case. -- 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: Encrypt bitcoin messages
The concern is that if you can monitor traffic in and out of a single node, you can determine which transactions originate from it vs those which it relays. That's not great, certainly, but how many nodes actually require that level of security, and surely they can use Tor or VPN services if so? Further, unless the remote nodes are in some way trusted, you're changing the attack from read-only to requiring the ability to perform a man in the middle attack - that doesn't seem much harder to me. As Gregory states, there's been at least two recent serious if not catastrophic OpenSSL bugs, and the consequences of Heartbleed if the Bitcoin network had been vulnerable are the stuff of nightmares. Very difficult to see the risk/reward payoff being worthwhile. Ross On 19/08/2014 18:35, Johnathan Corgan wrote: On 08/19/2014 09:38 AM, Gregory Maxwell wrote: We've dodged several emergency scale vulnerabilities by not having TLS. I'm still trying to understand the original premise that we want encrypted communications between nodes. I can certainly see the value of having *authenticated* traffic with specific nodes, using an HMAC for the protocol messages in place of the current checksum. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
Dear Gavin, Andreas, I'd see standardisation (or at least suggested standards) for error handling as positive for consistency of user experience. I do see what you mean about over-specification, however. Thanks for the feedback, I've taken the main points and created two pull requests: BIP-0070: https://github.com/bitcoin/bips/pull/54/ BIP-0072: https://github.com/bitcoin/bips/pull/55/ Please tell me if these need any further work. Ross On 26/04/14 14:23, Gavin Andresen wrote: The main area of concern is handling unexpected problems while sending the Payment message, or receiving the corresponding PaymentACK message. For example, in case of a transport layer failure or non-200 HTTP status code while sending the Payment message, what should the wallet software do next? Is it safe to re-send the Payment message? I'd propose that for any transport failure or 500 status code, the client retries after a delay (suggested at 30-60 seconds). For 400 status codes, the request should not be repeated, and as such the user should be alerted and a copy of the Payment message saved to be resent later. Why does error handling have to be standardized? I generally think that wallet software should be free to do whatever gives the user the best experience, so I'm in favor of restricting BIPs to things that must be standardized so that different implementations inter-operate. For 300 (redirect and similar) status codes, is it considered safe to follow redirects? I think we have to, but good to make it clear in the specification. Referencing whatever RFCs defines how to fetch URLs would be the best way to do this. Submit a pull request. On the merchant's side; I think it would be useful for there to be guidance for handling of errors processing Payment messages. I'd suggest that Payment messages should have a fixed maximum size to avoid merchant systems theoretically having to accept files of any size; 10MB would seem far larger than in any way practical, and therefore a good maximum size? PaymentRequests are limited to 50,000 bytes. I can't think of a reason why Payment messages would need to be any bigger than that. Submit a pull request to the existing BIP. A defined maximum time to wait (to avoid DDoS via connection holding) might be useful too, although I'd need to do measurements to find what values are tolerable. Implementation detail that doesn't belong in the spec, in my humble opinion. I would like to have the protocol state that merchant systems should handle repeatedly receiving the same Payment message, and return an equivalent (if not identical) PaymentACK to each. This is important in case of a network failure while the client is sending the Payment message, as outlined above. I think this should be left to implementations to work out. Lastly, I'm wondering about potential timing issues with transactions; if a merchant system wants to see confirmation of a transaction before sending a PaymentACK... not a good idea. The user should get feedback right away. Poking a pay now button and then waiting more than a second or three to get your payment has been received and is being processed is terrible UI. -- 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] Error handling in payment protocol (BIP-0070 and BIP-0072)
I'd be very cautious of security implications of embedding files into the payment request. Even file formats one would presume safe, such as images, have had security issues (i.e. https://technet.microsoft.com/library/security/ms11-006 ) Longer term I was wondering about embedding the PaymentRequest into web pages directly via the object tag, which could eliminate need for BIP0072 and potentially improve user interface integration that way. Obviously this would require browser plugins, however. Ross On 26/04/14 18:36, Mike Hearn wrote: PaymentRequests are limited to 50,000 bytes. I can't think of a reason why Payment messages would need to be any bigger than that. Submit a pull request to the existing BIP. In future it might be nice to have images and things in the payment requests, to make UIs look prettier. But with the current version 50kb should be plenty indeed. -- 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
[Bitcoin-development] BIP0071 media type registration with IANA
Dear all, Still going through the payment protocol specifications... the MIME types in BIP0071 aren't IANA registered, and honestly look unlikely to be accepted if they were submitted as-is. Latest RFC on media type registration is RFC 6838, which very strictly restricts what can go in the default application/ namespace. Essentially they'd want it to be an ISO standard or similar. There are vendor namespaces, which look much more feasible (this is how Powerpoint 2007 ended up as application/vnd.openxmlformats-officedocument.presentationml.presentation), but would be quite a dramatic change to BIP0071. What's the general feeling on this? Personally I'm in favour of following the registration process, so register a Bitcoin vendor namespace with IANA, then allocate MIME types such as: application/vnd.bitcoin.payment.request application/vnd.bitcoin.payment.payment application/vnd.bitcoin.payment.ack Thoughts? Ross -- 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
[Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
Dear Gavin, all, Going over the payment protocol specifications, I've noticed that there's appears to be a lack of specificity on handling of error states. In most cases there are reasonably obvious solutions, however it would seem positive to formalise processes to ensure consistency. I'm wondering therefore if either you'd be willing to edit the existing BIP, or advise on whether this is useful to write up as a new BIP? The main area of concern is handling unexpected problems while sending the Payment message, or receiving the corresponding PaymentACK message. For example, in case of a transport layer failure or non-200 HTTP status code while sending the Payment message, what should the wallet software do next? Is it safe to re-send the Payment message? I'd propose that for any transport failure or 500 status code, the client retries after a delay (suggested at 30-60 seconds). For 400 status codes, the request should not be repeated, and as such the user should be alerted and a copy of the Payment message saved to be resent later. For 300 (redirect and similar) status codes, is it considered safe to follow redirects? I think we have to, but good to make it clear in the specification. On the merchant's side; I think it would be useful for there to be guidance for handling of errors processing Payment messages. I'd suggest that Payment messages should have a fixed maximum size to avoid merchant systems theoretically having to accept files of any size; 10MB would seem far larger than in any way practical, and therefore a good maximum size? A defined maximum time to wait (to avoid DDoS via connection holding) might be useful too, although I'd need to do measurements to find what values are tolerable. I would like to have the protocol state that merchant systems should handle repeatedly receiving the same Payment message, and return an equivalent (if not identical) PaymentACK to each. This is important in case of a network failure while the client is sending the Payment message, as outlined above. Lastly, I'm wondering about potential timing issues with transactions; if a merchant system wants to see confirmation of a transaction before sending a PaymentACK, any thoughts on whether it should hold the connection, or send a PaymentACK with a memo indicating payment has been seen on the relay network but is not yet confirmed, or something else? Happy to write this up as a new BIP if that's more appropriate than editing the original, and please do tell me if I've missed anything obvious/prior discussion on this topic. Ross -- 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
