Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

Andy Schroder On 06/14/2015 11:19 PM, Warren Togami Jr. wrote: On Sun, Jun 14, 2015 at 5:15 AM, Jeff Garzik > wrote: * ACK on moving away from SourceForge mailing lists - though only once a community-welcomed replacement is up and running * ACK on using

Re: [Bitcoin-development] comments on BIP 100

On Mon, Jun 15, 2015 at 12:23:44AM +0200, Mike Hearn wrote: > > > > One thing that is concerning is that few in industry seem inclined to > > take any development initiatives or even integrate a library. > > > Um, you mean except all the people who have built more scalable wallets > over the past

Re: [Bitcoin-development] comments on BIP 100

> On Jun 14, 2015, at 9:11 PM, Peter Todd wrote: > > On Sun, Jun 14, 2015 at 05:53:05PM -0700, Eric Lombrozo wrote: >> I think the whole complexity talk is missing the bigger issue. >> >> Sure, per block validation scales linearly (or quasilinearly…there’s an >> O(log n) term in there somewher

Re: [Bitcoin-development] comments on BIP 100

On Sun, Jun 14, 2015 at 05:53:05PM -0700, Eric Lombrozo wrote: > I think the whole complexity talk is missing the bigger issue. > > Sure, per block validation scales linearly (or quasilinearly…there’s an O(log > n) term in there somewhere but it’s probably dominated by linear factors at > curren

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

On Sun, Jun 14, 2015 at 7:02 PM, Gregory Maxwell wrote: > 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 th

Re: [Bitcoin-development] User vote in blocksize through fees

> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo > 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 >

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

On Sun, Jun 14, 2015 at 5:15 AM, Jeff Garzik wrote: > * ACK on moving away from SourceForge mailing lists - though only once a > community-welcomed replacement is up and running > > * ACK on using LF as a mailing infrastructure provider > > * Research secure mailing list models, for bitcoin-secur

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

There's another important use case which you mentioned Greg, that also requires special exemption: compact commitments via mid-state compression. The use case is an OP_RETURN output sorted last, whose last N bytes are a commitment of some kind. A proof of the commitment can then use mid state comp

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 wrote: > On Sun, Jun 14, 2015 at 5:23 PM, Adam Back wrote: > >> Hi >> >> I made these comment

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

On Mon, Jun 15, 2015 at 2:29 AM, Rusty Russell wrote: > The softfork argument I find the most compelling, though it's tempting > to argue that every ordering use (including SIGHASH_SINGLE) is likely > a mistake. Oh. Hm. It is the case that the generalized sighash flag design I was thinking abou

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

Gregory Maxwell writes: > 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 the

Re: [Bitcoin-development] comments on BIP 100

On Sun, Jun 14, 2015 at 5:23 PM, Adam Back 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 goo

Re: [Bitcoin-development] comments on BIP 100

> On Jun 14, 2015, at 5:53 PM, Eric Lombrozo wrote: > > I think the whole complexity talk is missing the bigger issue. > > Sure, per block validation scales linearly (or quasilinearly…there’s an O(log > n) term in there somewhere but it’s probably dominated by linear factors at > current leve

Re: [Bitcoin-development] comments on BIP 100

I think the whole complexity talk is missing the bigger issue. Sure, per block validation scales linearly (or quasilinearly…there’s an O(log n) term in there somewhere but it’s probably dominated by linear factors at current levels…asymptotic limits don’t always apply very well to finite system

[Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

Mike Hearn 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,

Re: [Bitcoin-development] comments on BIP 100

Hi Mike On 15 June 2015 at 00:23, Mike Hearn wrote: >> One thing that is concerning is that few in industry seem inclined to >> take any development initiatives or even integrate a library. > > Um, you mean except all the people who have built more scalable wallets over > the past few years, whic

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

On Mon, Jun 8, 2015 at 9:25 PM, Danny Thorpe 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

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

On Sat, Jun 6, 2015 at 4:42 AM, Rusty Russell wrote: > Title: Canonical Input and Output Ordering > Author: Rusty Russell > Discussions-To: "Bitcoin Dev" > Status: Draft > Type: Standards Track > Created: 2015-06-06 > > Abstract > > This BIP provides a canonical ordering of inputs and outputs wh

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. 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,

Re: [Bitcoin-development] User vote in blocksize through fees

On Sun, Jun 14, 2015 at 4:42 PM, Jeff Garzik wrote: > Since you missed it, here is the suggestion again: > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf > Reposting as Jeff's mail got eaten by the anti-phishing filters, due to SourceForge's obsolete mailman setup.

Re: [Bitcoin-development] comments on BIP 100

> > One thing that is concerning is that few in industry seem inclined to > take any development initiatives or even integrate a library. Um, you mean except all the people who have built more scalable wallets over the past few years, which is the only reason anyone can even use Bitcoin from thei

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 , 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 bei

Re: [Bitcoin-development] User vote in blocksize through fees

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Notionally, I agree with what I see written here by Jeff, and I appreciate the thoughtfulness that went into this short post to list. On 06/14/2015 08:07 AM, Jeff Garzik wrote: > Exactly -- both block size proponents and block size change > conservat

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, And

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

Re: [Bitcoin-development] User vote in blocksize through fees

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree that changes of anything more than trivial are difficult, but I would disagree that they can't be made. It seems that the issue is one of roadblocks and muddling through when a major issue (e.g. the proposal of a hardfork / XT) is confronting

[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 a

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

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 w

Re: [Bitcoin-development] User vote in blocksize through fees

> On Jun 14, 2015, at 3:34 AM, Benjamin 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 disc

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 p

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

On Sun, Jun 14, 2015 at 11:15:18AM -0400, Jeff Garzik wrote: > * ACK on moving away from SourceForge mailing lists - though only once a > community-welcomed replacement is up and running > > * ACK on using LF as a mailing infrastructure provider > > * Research secure mailing list models, for bitc

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 wrote: > Since everyone's busy, I went ahead and made a pull request to add this as > an informa

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

* ACK on moving away from SourceForge mailing lists - though only once a community-welcomed replacement is up and running * ACK on using LF as a mailing infrastructure provider * Research secure mailing list models, for bitcoin-security. The list is not ultra high security - we all use PGP for t

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 blo

Re: [Bitcoin-development] User vote in blocksize through fees

Since you missed it, here is the suggestion again: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf On Sun, Jun 14, 2015 at 6:06 AM, Mats Henricson 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

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

[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 perceiv

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

Re: [Bitcoin-development] User vote in blocksize through fees

Economic policy sounds like a dirty word in the context of Bitcoin, but as Jeff Garzik said, choosing a block size cap is unfortunately an economic policy that has to be chosen somehow. Enabling users to incentivise the voting process is an interesting tool to have in the toolbox, but I think it w