[Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
Discomfort with Sourceforge For a while now people have been expressing concern about Sourceforge's continued hosting of the bitcoin-dev mailing list. Downloads were moved completely to bitcoin.org after the Sept 2014 hacking incident of the SF project account. The company's behavior and perceived stability have been growing to be increasingly questionable. http://www.theregister.co.uk/2013/11/08/gimp_dumps_sourceforge_over_dodgy_ads_and_installer November 2013: GIMP flees SourceForge over dodgy ads and installer https://lwn.net/Articles/646118/ May 28th, 2015: SourceForge replacing GIMP Windows downloads http://seclists.org/nmap-dev/2015/q2/194 June 3rd, 2015: Sourceforge hijacked nmap's old site and downloads. When this topic came up over the past two years, it seemed that most people agreed it would be a good idea to move. Someone always suggests Google Groups as the replacement host. Google is quickly shot down as too controversial in this community, and it becomes an even more difficult question as to who else should host it. Realizing this is not so simple, discussion then dies off until the next time somebody brings it up. http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/1943127.DBnVxmfOIh%401337h4x0r/#msg34192607 Somebody brought it up again this past week. It seems logical that an open discussion list is not a big deal to continue to be hosted on Sourceforge, as there isn’t much they could do to screw it up. I personally think moving it away now would be seen as a gesture that we do not consider their behavior to be acceptable. There are also some benefits in being hosted elsewhere, at an entity able to professionally maintain their infrastructure while also being neutral to the content. Proposal: Move Bitcoin Dev List to a Neutral Competent Entity Bitcoin is a global infrastructure development project where it would be politically awkward for any of the existing Bitcoin companies or orgs to host due to questions it would raise about perceived political control. For example, consider a bizarro parallel universe where MtGox was the inventor of Bitcoin, where they hosted its development infrastructure and dev list under their own name. Even if what they published was 100% technically and ideologically equivalent to the Bitcoin we know in our dimension, most people wouldn't have trusted it merely due to appearances and it would have easily gone nowhere. I had a similar thought process last week when sidechains code was approaching release. Sidechains, like Bitcoin itself, are intended to be a generic piece of infrastructure (like ethernet?) that anyone can build upon and use. We thought about Google Groups or existing orgs that already host various open source infrastructure discussion lists like the IETF or the Linux Foundation. Google is too controversial in this community, and the IETF is seen as possibly too politically fractured. The Linux Foundation hosts a bunch of infrastructure lists https://lists.linuxfoundation.org/mailman/listinfo and it seems that nobody in the Open Source industry considers them to be particularly objectionable. I talked with LF about the idea of hosting generic Bitcoin-related infrastructure development lists. They agreed as OSS infrastructure dev is already within their charter, so early this week sidechains-dev list began hosting there. From the perspective of our community, for bitcoin-dev it seems like a great fit. Why? While they are interested in supporting general open source development, the LF has literally zero stake in this. In addition to neutrality, they seem to be suitable as a competent host. They have full-time sysadmins maintaining their infrastructure including the Mailman server. They are soon upgrading to Mailman 3 http://wiki.list.org/Mailman3, which means mailing lists would benefit from the improved archive browser. I am not personally familiar with HyperKitty, but the point here is they are a stable non-profit entity who will competently maintain and improve things like their Mailman deployment (a huge improvement over the stagnant Sourceforge). It seems that LF would be competent, neutral place to host dev lists for the long-term. To be clear, this proposal is only about hosting the discussion list. The LF would have no control over the Bitcoin Project, as no single entity should. Proposed Action Plan - Discuss this openly within this community. Above is one example of a great neutral and competent host. If the technical leaders here can agree to move to a particular neutral host then we do it. - Migration: The current list admins become the new list admins. We import the entire list archive into the new host's archives for user convenience. - http://sourceforge.net/p/bitcoin/mailman/ Kill bitcoin-list and bitcoin-test. Very few people actually use it. Actually, let's delete the entire Bitcoin Sourceforge project as its continued existence
Re: [Bitcoin-development] User vote in blocksize through fees
The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. Exactly right. Bitcoin does not have a free market for fee though, and literally all the discussion so far has neglected some fundamental aspect of this, as you described. It's not at all a technical or engineering decision. It's the question of how to potentially re-design a fundamental part of Bitcoin, and the proposals so far don't address this. What is the price of the scarce resource of the blockchain and the mechanism to decide on price, once the subsidy runs out? On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson m...@henricson.se wrote: Jeff, with all due respect, but I've seen you saying this a few times now, that this decision is oh so difficult and important. But this is not helpful. We all know that. Even I. Make a suggestion, or stay out of the debate! Mats On 06/14/2015 07:36 AM, Jeff Garzik wrote: The choice is very real and on-point. What should the block size limit be? Why? There is a large consensus that it needs increasing. To what? By what factor? The size limit literally defines the fee market, the whole damn thing. If software high priests choose a size limit of 300k, space is scarce, fees are bid high. If software high priests choose a size limit of 32mb, space is plentiful, fees are near zero. Market actors take their signals accordingly. Some business models boom, some business models fail, as a direct result of changing this unintentionally-added speedbump. Different users value adoption, decentralization etc. differently. The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance problems associated with actors lobbying developers, even if a cloistered and vetted Technical Advisory Board as has been proposed. On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote: I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- ___ 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] User vote in blocksize through fees
Jeff, with all due respect, but I've seen you saying this a few times now, that this decision is oh so difficult and important. But this is not helpful. We all know that. Even I. Make a suggestion, or stay out of the debate! Mats On 06/14/2015 07:36 AM, Jeff Garzik wrote: The choice is very real and on-point. What should the block size limit be? Why? There is a large consensus that it needs increasing. To what? By what factor? The size limit literally defines the fee market, the whole damn thing. If software high priests choose a size limit of 300k, space is scarce, fees are bid high. If software high priests choose a size limit of 32mb, space is plentiful, fees are near zero. Market actors take their signals accordingly. Some business models boom, some business models fail, as a direct result of changing this unintentionally-added speedbump. Different users value adoption, decentralization etc. differently. The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance problems associated with actors lobbying developers, even if a cloistered and vetted Technical Advisory Board as has been proposed. On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote: I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- ___ 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] Scaling Bitcoin with Subchains
Pieter, Am 13.06.2015 um 16:39 schrieb Pieter Wuille: We can reasonably assume that different people's wallet will tend to be distributed uniformly over several sidechains to hold their transactions (if they're not, there is no scaling benefit anyway...). That means that for an average transaction, you will need a cross-chain transfer in order to get the money to the recipient (as their wallet will usually be associated to a chain that is different from your own). I think we should set the right incentives to invalidate these assumptions. If the fees as well as the security guarantees on the main chain are highest and fees are dropping with the distance from the main chain on each level of side chains, wouldn't communities with many internal transactions create their own side chain with low fees? I'd expect geographic as well as virtual communities to be forming enjoying cheap fees on their 'local' chains and expensive but comparabily rare 'long distance' fees. One would expect geographic chains (e.g. continents) as well as virtual ones (e.g. the Open Bazaar users' chain) to form. To save fees, a typical user would maintain a wallet in each of her communities which are loaded and drained with rare expensive transacations, whereas daily business with many transactions is done cheaply within each community chain. So, indeed, I would argue that side chains equipped with the right cost incentives for cross-chain transactions would lead to a scalable and efficiently self-organizing network of side chains. best regards, Martin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
Hi all, it's a very useful approach to also model fees and you came up with an interesting scenario. Assuming that you meant that the groups are only connected with a single link, I've recreated the scenario with Gavin's simulation and got similar results. The group with the large hashrate does profit overall, but the miners which are not directly connected to the small group loose: https://github.com/jonasnick/bitcoin_miningsim/blob/master/analysis/README.md#two-groups-well-connected-internally-but-connected-to-each-other-with-a-single-poor-connection Moreover, it's important to note that this is not an equilibrium because these miners are better off when they create their own connections to the small group (see the plot below the other one). This means that your scenario is not the result of a cartel but the result of a long-term network partition. When assuming partitions, there are quite a few scenarios where big miners can profit from creating big blocks. For example, one 40% miner and two groups of three 10% miners, where both groups are connected to the big miner but they are not connected to each other. https://github.com/jonasnick/bitcoin_miningsim/blob/master/analysis/README.md#one-big-miner-and-two-partitioned-groups Best, Jonas On 06/12/2015 06:51 PM, Pieter Wuille wrote: Hello all, I've created a simulator for Bitcoin mining which goes a bit further than the one Gavin used for his blog post a while ago. The main difference is support for links with different latency and bandwidth, because of the clustered configuration described below. In addition, it supports different block sizes, takes fees into account, does difficulty adjustments, and takes processing and mining delays into account. It also simulates longer periods of time, and averages the result of many simulations running in parallel until the variance on the result is low enough. The code is here: https://github.com/sipa/bitcoin-net-simul The configuration used in the code right now simulates two groups of miners (one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected internally, but are only connected to each other through a slow 2 Mbit/s link. Here are some results. This shows how the group of smaller miners loses around 8% of their relative income (if they create larger blocks, their loss percentage goes up slightly further): Configuration: * Miner group 0: 80.00% hashrate, blocksize 2000.00 * Miner group 1: 20.00% hashrate, blocksize 100.00 * Expected average block size: 1620.00 * Average fee per block: 0.25 * Fee per byte: 0.000154 Result: * Miner group 0: 81.648985% income (factor 1.020612 with hashrate) * Miner group 1: 18.351015% income (factor 0.917551 with hashrate) When fees become more important however, and half of a block's income is due to fees, the effect becomes even stronger (a 15% loss), and the optimal way to compete for small miners is to create larger blocks as well (smaller blocks for them result in even less income): Configuration: * Miner group 0: 80.00% hashrate, blocksize 2000.00 * Miner group 1: 20.00% hashrate, blocksize 2000.00 * Expected average block size: 2000.00 * Average fee per block: 25.00 * Fee per byte: 0.012500 Result: * Miner group 0: 83.063545% income (factor 1.038294 with hashrate) * Miner group 1: 16.936455% income (factor 0.846823 with hashrate) The simulator is not perfect. It doesn't take into account that multiple blocks/relays can compete for the same bandwidth, or that nodes cannot process multiple blocks at once. The numbers used may be unrealistic, and I don't mean this as a prediction for real-world events. However, it does very clearly show the effects of larger blocks on centralization pressure of the system. Note that this also does not make any assumption of destructive behavior on the network - just simple profit maximalization. Lastly, the code may be buggy; I only did some small sanity tests with simple networks. -- ___ 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] User vote in blocksize through fees
Exactly -- both block size proponents and block size change conservatives seem to be glossing over this aspect - much to my dismay. Choosing the size limit is choosing the size of a scarce resource. By fiat. It is wrong to think that a technical consensus can choose what is best here. The block size limit defines the scope of a resource for which all fee market actors bid. That, in turn, defines who is in the fee market and how they behave, what market choices are made. It doesn't matter how or why the limit was originally enacted, what Satoshi meant to do. What matters, economically, is what is. What the software and our $3B economy market knows and sees today. (I think some block size change proponents miss this!) The solution lies in transitioning this size limit to the free market. In the end, the users must choose their desired level of growth, decentralization, etc. We cannot rely on some dev's idea of the proper level of fee, proper level of growth, proper level of decentralization. And IMO, a floating limit with training wheels is better and stronger for bitcoin's health from a governance, user choice and free market perspective than simply hard fork to 2MB, come back again in 6 months. On Sun, Jun 14, 2015 at 6:34 AM, Benjamin benjamin.l.cor...@gmail.com wrote: The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. Exactly right. Bitcoin does not have a free market for fee though, and literally all the discussion so far has neglected some fundamental aspect of this, as you described. It's not at all a technical or engineering decision. It's the question of how to potentially re-design a fundamental part of Bitcoin, and the proposals so far don't address this. What is the price of the scarce resource of the blockchain and the mechanism to decide on price, once the subsidy runs out? On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson m...@henricson.se wrote: Jeff, with all due respect, but I've seen you saying this a few times now, that this decision is oh so difficult and important. But this is not helpful. We all know that. Even I. Make a suggestion, or stay out of the debate! Mats On 06/14/2015 07:36 AM, Jeff Garzik wrote: The choice is very real and on-point. What should the block size limit be? Why? There is a large consensus that it needs increasing. To what? By what factor? The size limit literally defines the fee market, the whole damn thing. If software high priests choose a size limit of 300k, space is scarce, fees are bid high. If software high priests choose a size limit of 32mb, space is plentiful, fees are near zero. Market actors take their signals accordingly. Some business models boom, some business models fail, as a direct result of changing this unintentionally-added speedbump. Different users value adoption, decentralization etc. differently. The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance problems associated with actors lobbying developers, even if a cloistered and vetted Technical Advisory Board as has been proposed. On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote: I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- ___ 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
Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
Update: BIP 79 has been implemented in the latest release of Electrum, v2.3.2: https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES -Kristov On Fri, Jun 12, 2015 at 5:36 PM, Kristov Atlas kristovatlas.li...@gmail.com wrote: Since everyone's busy, I went ahead and made a pull request to add this as an informational BIP 79 to the bips directory. https://github.com/bitcoin/bips/pull/157 Regards, Kristov On Tue, Jun 9, 2015 at 4:14 PM, Peter Todd p...@petertodd.org wrote: On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote: Two other things: On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd p...@petertodd.org wrote: Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized protocols; you haven't taken into account the needs of those protocols. For BIP's it's better to stick to the use-cases where the need is clear and there exists running code that to speculate too much on future uses. With signature hashing in particular it's not yet clear at all what future OP_CHECKSIG's will look like, let alone the various ways people will use sighash for smart contract type stuff. You'd be better off presenting the BIP in terms of a generic statement that except when otherwise prevented by advanced signature hashing requirements, wallet software must emit transactions sorted according to the following You can then specify the two common cases in detail: 1) SIGHASH_ALL: input and output order signed, so sort appropriately 2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit transactions sorted, recognising that the actual mined order may be changed. That makes sense. I updated the language as follows -- your thoughts? Keep in mind this BIP is informational, and so people are free to ignore it. Applicability: This BIP applies to all transactions of signature hash type SIGHASH_ALL. Additionally, software compliant with this BIP that allows later parties to update the transaction (e.g. using signature hash types SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit lexicographically sorted inputs and outputs, although they may later be modified. Transactions that have index dependencies between transactions or within the same transaction are covered under the section of this BIP entitled “Handling Input/Output Dependencies.” I'd keep it even simpler than that, and just say for now that such use-cases are out of the scope of this BIP, however those standards should come up with some kind of deterministic standard that meets the needs of the protocol. Again, there's a bunch of possible use-cases here and we just can't predict them; focus on the fact that the *spirit* of what this BIP is about is applicable and future standards should be developed. So I'd change the Applicability section to: This BIP applies to all transactions where the order of inputs and outputs does not matter. This is true for the vast majority of transactions as they simply move funds from one place to another. Currently this generally refers to transactions where SIGHASH_ALL is used, in which case the signatures commit to the exact order of input and outputs. In the case where SIGHASH_ANYONECANPAY and/or SIGHASH_NONE has been used (e.g. crowdfunds) the order of inputs and/or outputs may not be signed, however compliant software should still emit transactions with sorted inputs and outputs, even though they may later be modified by others. In the event that future protocol upgrades introduce new signature hash types, compliant software should apply the lexographic ordering principle analogously. While out of scope of this BIP, protocols that do require a specified order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should consider the goals of this BIP and how best to adapt them to the specifics needs of those protocols. Then remove the handling input/output deps section. Do you have a patch implementing deterministic tx ordering for Bitcoin Core yet? I'm not a frequent C programmer, so I'd prefer to let someone else take care of it, as a frequent committer of code would do a faster and more stylistically consistent job of it. If no one else will, however, I will. re: the actual ordering algorithm, having txids be sorted by with the hex-based algorithm is odd. I'd simply say they're sorted as little-endian byte arrays, or in other words, with the bytearr_cmp() function, but with the order of bytes reversed. You also should say that we're doing that to make the user see them in visually sorted order to match expectations because txids are displayed as little-endian. For outputs, don't say locking script, say scriptPubKey. Secondly, scriptPubKeys are not in little-endian representation - they have no endianness to them. With output amount, there's no need to say that they're unsigned or little-endian satoshies,
Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
It might be as well to keep the archive but disable new posts as otherwise we create bit-rot for people who linked to posts on sourceforge. The list is also archived on mail-archive though. https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ Adam On 14 June 2015 at 22:55, Andy Schroder i...@andyschroder.com wrote: Hello, I'd support moving to a Linux Foundation e-mail list. I am also against google groups. I agree that the gesture of moving indicates that SourceForge is not playing nice on other issues and that moving this list shows their behavior is being acknowledged. I understand your reason for wanting to delete the Source Forge account (after reading the links). However, the only problem with that is that the SourceForge archive is the oldest one I've found with some early messages from Satoshi. Myself finding Bitcoin after its inception, as well as this mailing list even later on, it's nice to be able to review the archives. SourceForge's interface to those archives is pretty bad though. I'm not sure if there is any way to get older messages archived on sites like gmane or mail-archive? Does anyone know? You mentioned importing the list archive as part of the migration plan, but I guess is this easy to do from SourceForge? Andy Schroder On 06/14/2015 06:12 AM, Warren Togami Jr. wrote: Discomfort with Sourceforge For a while now people have been expressing concern about Sourceforge's continued hosting of the bitcoin-dev mailing list. Downloads were moved completely to bitcoin.org after the Sept 2014 hacking incident of the SF project account. The company's behavior and perceived stability have been growing to be increasingly questionable. http://www.theregister.co.uk/2013/11/08/gimp_dumps_sourceforge_over_dodgy_ads_and_installer November 2013: GIMP flees SourceForge over dodgy ads and installer https://lwn.net/Articles/646118/ May 28th, 2015: SourceForge replacing GIMP Windows downloads http://seclists.org/nmap-dev/2015/q2/194 June 3rd, 2015: Sourceforge hijacked nmap's old site and downloads. When this topic came up over the past two years, it seemed that most people agreed it would be a good idea to move. Someone always suggests Google Groups as the replacement host. Google is quickly shot down as too controversial in this community, and it becomes an even more difficult question as to who else should host it. Realizing this is not so simple, discussion then dies off until the next time somebody brings it up. http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/1943127.DBnVxmfOIh%401337h4x0r/#msg34192607 Somebody brought it up again this past week. It seems logical that an open discussion list is not a big deal to continue to be hosted on Sourceforge, as there isn’t much they could do to screw it up. I personally think moving it away now would be seen as a gesture that we do not consider their behavior to be acceptable. There are also some benefits in being hosted elsewhere, at an entity able to professionally maintain their infrastructure while also being neutral to the content. Proposal: Move Bitcoin Dev List to a Neutral Competent Entity Bitcoin is a global infrastructure development project where it would be politically awkward for any of the existing Bitcoin companies or orgs to host due to questions it would raise about perceived political control. For example, consider a bizarro parallel universe where MtGox was the inventor of Bitcoin, where they hosted its development infrastructure and dev list under their own name. Even if what they published was 100% technically and ideologically equivalent to the Bitcoin we know in our dimension, most people wouldn't have trusted it merely due to appearances and it would have easily gone nowhere. I had a similar thought process last week when sidechains code was approaching release. Sidechains, like Bitcoin itself, are intended to be a generic piece of infrastructure (like ethernet?) that anyone can build upon and use. We thought about Google Groups or existing orgs that already host various open source infrastructure discussion lists like the IETF or the Linux Foundation. Google is too controversial in this community, and the IETF is seen as possibly too politically fractured. The Linux Foundation hosts a bunch of infrastructure lists and it seems that nobody in the Open Source industry considers them to be particularly objectionable. I talked with LF about the idea of hosting generic Bitcoin-related infrastructure development lists. They agreed as OSS infrastructure dev is already within their charter, so early this week sidechains-dev list began hosting there. From the perspective of our community, for bitcoin-dev it seems like a great fit. Why? While they are interested in supporting general open source development, the LF has literally zero stake in this. In addition to
[Bitcoin-development] comments on BIP 100
Hi I made these comments elsewhere, but I think really we should be having these kind of conversations here rather than scattered around. These are about Jeff Garzik's outline draft BIP 100 I guess this is the latest draft: (One good thing about getting off SF would be finally JGarzik's emails actually not getting blocked!). http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf may have changed since the original [1] Over the original proposal: 1. there should be a hard cap, not indefinitely growing. 2. there should be a growth limiter (no more than X%/year) 3. I think the miners should not be given a vote that has no costs to cast, because their interests are not necessarily aligned with users or businesses. I think Greg Maxwell's difficulty adjust [2] is better here for that reason. It puts quadratic cost via higher difficulty for miners to vote to increase block-size, which miners can profitably do if there are transactions with fees available to justify it. There is also the growth limiter as part of Greg's proposal. [3] I think bitcoin will have to involve layering models that uplift security to higher layers, but preserve security assurances, and smart-contracts even, with protocols that improve the algorithmic complexity beyond O(n^2) in users, like lightning, and there are multiple other candidates with useful tradeoffs for various use-cases. One thing that is concerning is that few in industry seem inclined to take any development initiatives or even integrate a library. I suppose eventually that problem would self-correct as new startups would make a more scalable wallet and services that are layer2 aware and eat the lunch of the laggards. But it will be helpful if we expose companies to the back-pressure actually implied by an O(n^2) scaling protocol and don't just immediately increase the block-size to levels that are dangerous for decentralisation security, as an interventionist subsidy to save them having to do basic integration work. Otherwise I think whichever any kind of kick the can some 2-5 years down the road we consider, we risk the whole saga repeating in a few years, when no algorithmic progress has been made and even more protocol inertia has set in. Adam [1] original proposal comments on reddit https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/ [2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html [3] growth limited proposal for flexcap by Greg Maxwell https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I fully agree and support this idea. Some recent discussion on social media which touches on this very subject of bitcoin and sourceforge (I include nmap and gittorrent as well because those seem relevant, imho) https://twitter.com/jgarzik/status/607750046021357568 https://twitter.com/nmap/status/608418994236891137 https://twitter.com/ktorn/status/607818378531631106 https://twitter.com/ktorn/status/607822900331020288 On 06/14/2015 03:12 AM, Warren Togami Jr. wrote: Discomfort with Sourceforge For a while now people have been expressing concern about Sourceforge's continued hosting of the bitcoin-dev mailing list. Downloads were moved completely to bitcoin.org http://bitcoin.org after the Sept 2014 hacking incident of the SF project account. The company's behavior and perceived stability have been growing to be increasingly questionable. http://www.theregister.co.uk/2013/11/08/gimp_dumps_sourceforge_over_do dgy_ads_and_installer November 2013: GIMP flees SourceForge over dodgy ads and installer https://lwn.net/Articles/646118/ May 28th, 2015: SourceForge replacing GIMP Windows downloads http://seclists.org/nmap-dev/2015/q2/194 June 3rd, 2015: Sourceforge hijacked nmap's old site and downloads. When this topic came up over the past two years, it seemed that most people agreed it would be a good idea to move. Someone always suggests Google Groups as the replacement host. Google is quickly shot down as too controversial in this community, and it becomes an even more difficult question as to who else should host it. Realizing this is not so simple, discussion then dies off until the next time somebody brings it up. http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/19 43127.DBnVxmfOIh%401337h4x0r/#msg34192607 Somebody brought it up again this past week. It seems logical that an open discussion list is not a big deal to continue to be hosted on Sourceforge, as there isn’t much they could do to screw it up. I personally think moving it away now would be seen as a gesture that we do not consider their behavior to be acceptable. There are also some benefits in being hosted elsewhere, at an entity able to professionally maintain their infrastructure while also being neutral to the content. Proposal: Move Bitcoin Dev List to a Neutral Competent Entity Bitcoin is a global infrastructure development project where it would be politically awkward for any of the existing Bitcoin companies or orgs to host due to questions it would raise about perceived political control. For example, consider a bizarro parallel universe where MtGox was the inventor of Bitcoin, where they hosted its development infrastructure and dev list under their own name. Even if what they published was 100% technically and ideologically equivalent to the Bitcoin we know in our dimension, most people wouldn't have trusted it merely due to appearances and it would have easily gone nowhere. I had a similar thought process last week when sidechains code was approaching release. Sidechains, like Bitcoin itself, are intended to be a generic piece of infrastructure (like ethernet?) that anyone can build upon and use. We thought about Google Groups or existing orgs that already host various open source infrastructure discussion lists like the IETF or the Linux Foundation. Google is too controversial in this community, and the IETF is seen as possibly too politically fractured. The Linux Foundation hosts a bunch of infrastructure lists https://lists.linuxfoundation.org/mailman/listinfoand it seems that nobody in the Open Source industry considers them to be particularly objectionable. I talked with LF about the idea of hosting generic Bitcoin-related infrastructure development lists. They agreed as OSS infrastructure dev is already within their charter, so early this week sidechains-dev list began hosting there. From the perspective of our community, for bitcoin-dev it seems like a great fit. Why? While they are interested in supporting general open source development, the LF has literally zero stake in this. In addition to neutrality, they seem to be suitable as a competenthost. They have full-time sysadmins maintaining their infrastructure including the Mailman server. They are soon upgrading to Mailman 3 http://wiki.list.org/Mailman3, which means mailing lists would benefit from the improved archive browser. I am not personally familiar with HyperKitty, but the point here is they are a stable non-profit entity who will competently maintain and improve things like their Mailman deployment (a huge improvement over the stagnant Sourceforge). It seems that LF would be competent, neutral place to host dev lists for the long-term. To be clear, this proposal is only about hosting the discussion list. The LF would have no control over the Bitcoin Project,
Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
Hi, I just wanted to let everyone know that every email is also archived at bitcoin-development.narkive.com http://bitcoin-development.narkive.com/, where you can find everything since the beginning of the list (June 2011). That should answer to Andy’s concern about the older messages not being archived anywhere but on sourceforge. Davide On 14 Jun 2015, at 23:59, Adam Back a...@cypherspace.org wrote: It might be as well to keep the archive but disable new posts as otherwise we create bit-rot for people who linked to posts on sourceforge. The list is also archived on mail-archive though. https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ Adam On 14 June 2015 at 22:55, Andy Schroder i...@andyschroder.com wrote: Hello, I'd support moving to a Linux Foundation e-mail list. I am also against google groups. I agree that the gesture of moving indicates that SourceForge is not playing nice on other issues and that moving this list shows their behavior is being acknowledged. I understand your reason for wanting to delete the Source Forge account (after reading the links). However, the only problem with that is that the SourceForge archive is the oldest one I've found with some early messages from Satoshi. Myself finding Bitcoin after its inception, as well as this mailing list even later on, it's nice to be able to review the archives. SourceForge's interface to those archives is pretty bad though. I'm not sure if there is any way to get older messages archived on sites like gmane or mail-archive? Does anyone know? You mentioned importing the list archive as part of the migration plan, but I guess is this easy to do from SourceForge? Andy Schroder On 06/14/2015 06:12 AM, Warren Togami Jr. wrote: Discomfort with Sourceforge For a while now people have been expressing concern about Sourceforge's continued hosting of the bitcoin-dev mailing list. Downloads were moved completely to bitcoin.org after the Sept 2014 hacking incident of the SF project account. The company's behavior and perceived stability have been growing to be increasingly questionable. http://www.theregister.co.uk/2013/11/08/gimp_dumps_sourceforge_over_dodgy_ads_and_installer November 2013: GIMP flees SourceForge over dodgy ads and installer https://lwn.net/Articles/646118/ May 28th, 2015: SourceForge replacing GIMP Windows downloads http://seclists.org/nmap-dev/2015/q2/194 June 3rd, 2015: Sourceforge hijacked nmap's old site and downloads. When this topic came up over the past two years, it seemed that most people agreed it would be a good idea to move. Someone always suggests Google Groups as the replacement host. Google is quickly shot down as too controversial in this community, and it becomes an even more difficult question as to who else should host it. Realizing this is not so simple, discussion then dies off until the next time somebody brings it up. http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/1943127.DBnVxmfOIh%401337h4x0r/#msg34192607 Somebody brought it up again this past week. It seems logical that an open discussion list is not a big deal to continue to be hosted on Sourceforge, as there isn’t much they could do to screw it up. I personally think moving it away now would be seen as a gesture that we do not consider their behavior to be acceptable. There are also some benefits in being hosted elsewhere, at an entity able to professionally maintain their infrastructure while also being neutral to the content. Proposal: Move Bitcoin Dev List to a Neutral Competent Entity Bitcoin is a global infrastructure development project where it would be politically awkward for any of the existing Bitcoin companies or orgs to host due to questions it would raise about perceived political control. For example, consider a bizarro parallel universe where MtGox was the inventor of Bitcoin, where they hosted its development infrastructure and dev list under their own name. Even if what they published was 100% technically and ideologically equivalent to the Bitcoin we know in our dimension, most people wouldn't have trusted it merely due to appearances and it would have easily gone nowhere. I had a similar thought process last week when sidechains code was approaching release. Sidechains, like Bitcoin itself, are intended to be a generic piece of infrastructure (like ethernet?) that anyone can build upon and use. We thought about Google Groups or existing orgs that already host various open source infrastructure discussion lists like the IETF or the Linux Foundation. Google is too controversial in this community, and the IETF is seen as possibly too politically fractured. The Linux Foundation hosts a bunch of infrastructure lists and it seems that nobody in the Open Source industry considers them to be particularly objectionable. I talked with LF
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Sat, Jun 6, 2015 at 4:42 AM, Rusty Russell ru...@rustcorp.com.au wrote: Title: Canonical Input and Output Ordering Author: Rusty Russell ru...@rustcorp.com.au Discussions-To: Bitcoin Dev bitcoin-development@lists.sourceforge.net Status: Draft Type: Standards Track Created: 2015-06-06 Abstract This BIP provides a canonical ordering of inputs and outputs when creating transactions. Motivation Most bitcoin wallet implementations randomize the outputs of transactions they create to avoid trivial linkage analysis (especially change outputs), however implementations have made mistakes in this area in the past. Using a canonical ordering has the same effect, but is simpler, more obvious if incorrect, and can eventually be enforced by IsStandard() and even a soft-fork to enforce it. Specification Inputs should be ordered like so: index (lower value first) txid (little endian order, lower byte first) Outputs should be ordered like so: amount (lower value first) script (starting from first byte, lower byte first, shorter wins) Rationale Any single wallet is already free to implement this, but if other wallets do not it would reduce privacy by making those transactions stand out. Thus a BIP is appropriate, especially if this were to become an IsStandard() rule once widely adopted. Because integers are fast to compare, they're sorted first, before the lexographical ordering. The other input fields do not influence the sort order, as any valid transactions cannot have two inputs with the same index and txid. Reference Implementation https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering Sorry I wasn't a part of the IRC conversation where this was first discussed, though I'm very happy to see a concrete implementation along with the proposal. I'm not a great fan of this proposal for two reasons: The first is that the strict ordering requirements is incompatible with future soft-forks that may expose additional ordering constraints. Today we have _SINGLE, which as noted this interacts with poorly, but there have been other constraints proposed that this would also interact with poorly. The second is that even absent consensus rules there may be invisible constraints in systems-- e.g. hardware wallets that sign top down, or future transaction covenants that have constraints about ordering, or proof systems that use (yuck) midstate compression for efficiency. Right now, with random ordering these applications are fairly indistinguishable from other random uses (since their imposed order could come about by chance) but if everyone else was ordered, even if wasn't enforced.. these would be highly distinguishable. Which would be unfortunate. Worse, if most transactions are ordered the few that aren't could be mishandled (which is, I assume, part of why you propose requiring the ordering-- but I think the soft fork constraints there hurt it more). [Sorry for the delay in stating my views here; I wanted to talk them over with a few other people to see if I was just being stupid and misunderstanding the proposal] I think perhaps the motivations here are understated. We have not seen any massive deployments of accidentally broken ordering that I'm aware of-- and an implementation that got this wrong in a harmful way would likely make far more fatal mistakes (e.g. non random private keys). As an alternative to this proposal the ordering can be privately derandomized in the same way DSA is, to avoid the need for an actual number source. If getting the randomness right were really the only motivation, I'd suggest we propose a simple derandomized randomization algorithm--- e.g. take the order from (H(input ids||client secret)). I think there is actually an unstated motivation also driving this (and the other) proposal related to collaborative transaction systems like coinjoins or micropayment channels; where multiple clients need to agree on the same ordering. Is this the case? If so we should probably talk through some of the requirements there and see if there isn't a better way to address it. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Mon, Jun 8, 2015 at 9:25 PM, Danny Thorpe danny.tho...@gmail.com wrote: Recommending sorting of the inputs and outputs as a best practice is fine (and better than random, IMO), but not as part of IsStandard() or consensus rules. There are cases where the order of the inputs and outputs is significant. Is it your opinion that its fine if the result is that it makes the usage trivially distinguishable e.g. where it might be subjected to higher tx fees, or might break some software which incorrectly expects all transactions to be ordered since most are? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
Mike Hearn m...@plan99.net wrote: Which is why there will soon be a fork that does it. I understand why you would be keen to scale bitcoin, everyone here is. But as you seem to be saying that you will do a unilateral hard-fork, and fork the code-base simultaneously, probably a number of people have questions, so I'll start with some: ( I noticed some of your initial thoughts are online here https://www.youtube.com/watch?v=DB9goUDBAR0 or the full podcast https://epicenterbitcoin.com/podcast/082/ ) - Are you releasing a BIP for that proposal for review? - If the reviewers all say NACK will you take on board their suggestions? - On the idea of a non-consensus hard-fork at all, I think we can assume you will get a row of NACKs. Can you explain your rationale for going ahead anyway? The risks are well understood and enormous. - How do you propose to deal with the extra risks that come from non-consensus hard-forks? Hard-forks themselves are quite risky, but non-consensus ones are extremely dangerous for consensus. - If you're going it alone as it were, are you proposing that you will personally maintain bitcoin-XT? Or do you have a plan to later hand over maintenance to the bitcoin developers? - Do you have contingency plans for what to do if the non-consensus hard-fork goes wrong and $3B is lost as a result? As you can probably tell I think a unilateral fork without wide-scale consensus from the technical and business communities is a deeply inadvisable. While apparently some companies have expressed interest in increased scale, I can only assume they do no yet understand the risks. I suggest before they would actually go ahead that they seek independent advice. Of the overall process, I think you can agree we should not be making technical decisions with this level of complexity and consensus risk with financial implications of this magnitude under duress of haste? This seems otherwise a little like the moral hazard of the 2008 financial collapse that Satoshi put the quote in the genesis block about. I think its best that we progress as Jeff Garzik has done to have engineering discussions centre around BIPs, running code for review, simulation and careful analysis. I understand this has been going on for a long time, and some people are frustrated with the rate of progress, but making hasty, contentious or unilateral actions in this space is courting disaster. Please use your considerable skills to, along with the rest of the community, work on this problem collaboratively. I can sincerely assure you everyone does want to scale bitcoin and shares your long term objective on that. Adam -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
On Sun, Jun 14, 2015 at 10:12 AM, Warren Togami Jr. wtog...@gmail.com wrote: From the perspective of our community, for bitcoin-dev it seems like a great fit. Why? While they are interested in supporting general open source development, the LF has literally zero stake in this. In addition to neutrality, they seem to be suitable as a competent host. They have I support this proposal. But for clarity sake, we should recognize that Linux Foundation isn't a charity chartered to act in the public good, is a trade organization which acts in the commercial interest of it's membership. I do not think this presents a problem: LF's membership's interests are not at odds with ours currently, and aren't likely to become so (doubly so with sourceforge as the comparison point). We are, after all, just talking about a development mailing list; in the unlikely case that there were issues in the future it could be changed, and they've demonstrated considerable competence at this kind of operation as well, and I would be grateful to have their support. I mention it only because the 'foundation' name sometimes carries the charity confusion, and to be clear that I think the stakes on this matter are small enough that it doesn't require a careful weighing of interests. These concerns may matter for other initiatives but as you note, LF has zero stake beyond the general support of the open source ecosystem. I do not believe it would be wise to delete the SF account, at least while there are many active links to it. As it might well be recreated to 'mirror' things as a 'service' to those following the old links. I also agree with Jeff's comments wrt, bitcoin-security. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] comments on BIP 100
Adding - in re pay-to-FOO - these schemes are inherently short term, such that it is near-impossible for the market to plan for what happens in 12+ months. On Sun, Jun 14, 2015 at 10:28 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 5:23 PM, Adam Back a...@cypherspace.org wrote: Hi I made these comments elsewhere, but I think really we should be having these kind of conversations here rather than scattered around. These are about Jeff Garzik's outline draft BIP 100 I guess this is the latest draft: (One good thing about getting off SF would be finally JGarzik's emails actually not getting blocked!). http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf may have changed since the original [1] Over the original proposal: 1. there should be a hard cap, not indefinitely growing. In the latest draft there is an explicit 32MB ceiling now. Users will need to opt into growth beyond 32MB via a 2nd hard fork. 2. there should be a growth limiter (no more than X%/year) As a general principle, this is an area of market disagreement, and should not be our call. Encoding this into software veers into personal opinion about what economic policy should be. That said -- BIP 100, as a compromise, includes a growth limiter. Abrupt change (1MB - 32MB!) is awful on markets. Good policies include a measured pace of transition from policy A to policy B. It gives the community time to assess system effectiveness - while also allowing free market input. In the long run I hope the cap is removed (see below), and the intention is to -slowly- and -transparently- move from the tightly controlled limit to something the free market and users are choosing. 3. I think the miners should not be given a vote that has no costs to cast, because their interests are not necessarily aligned with users or businesses. I think Greg Maxwell's difficulty adjust [2] is better here for that reason. It puts quadratic cost via higher difficulty for miners to vote to increase block-size, which miners can profitably do if there are transactions with fees available to justify it. There is also the growth limiter as part of Greg's proposal. [3] paying with difficulty has severe negative elements that will likely cause it never to be used: - complex and difficult for miners to reason - fails the opportunity cost test - dollar cost lost losing the block race versus value gained by increasing block size - inherently unpredictable in the short term - user experience is that it's possibly difficult to see a gain in utility versus the revenue you are giving up - REQUIRES informal miner collusion - probably less transparent than BIP 100 - in order to solve the who-goes-first problem. - net result: tough sell Paying bitcoins to future miners makes a lot more sense. Initially I was a fan of pay-with-diff, but freezing bitcoins (CLTV) or timelock'd anyone-can-spend has much more clear incentives, if you want to go down that road. Problems with pay-to-increase-block-size: - how much to pay? You are inherently setting your growth policy on top of bitcoin by choosing a price here. - another who-goes-first problem Anyway, there is a natural equilibrium block size that the free market and user choice will seek. Related: There is a lot of naive miner = max income = max block size reasoning going on, with regards to fees. This is defining the bounds of an economically scarce resource. There are many reasons why a miner will today, in the real world, limit their block size. WRT fee income, if block size is too large the fee competition in the overall market is low-to-zero, fee income rapidly collapses. Then factor in price and demand elasticity on top of that. Quite frankly, there seems to be a natural block size equilibrium ceiling, and I worry about miners squeezing the market by maximizing their fee income through constrained block sizes and competition at the low end. This is of course already possible today - miners may openly or covertly collude to keep the block size low. I think bitcoin will have to involve layering models that uplift security to higher layers, but preserve security assurances, and smart-contracts even, with protocols that improve the algorithmic complexity beyond O(n^2) in users, like lightning, and there are multiple other candidates with useful tradeoffs for various use-cases. One thing that is concerning is that few in industry seem inclined to take any development initiatives or even integrate a library. I suppose eventually that problem would self-correct as new startups would make a more scalable wallet and services that are layer2 aware and eat the lunch of the laggards. But it will be helpful if we expose companies to the back-pressure actually implied by an O(n^2) scaling protocol and don't just immediately increase the block-size to levels that are dangerous for
