Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

2015-09-03 Thread Andy Chase via bitcoin-dev
As posted: **Enforcement/Organization** I agree with your comments. I don't believe in setting up an organization to manage this process (would be too much power and not really needed because the internet is pretty good at information sharing). Therefore, I designed it around the assumption that p

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Peter Todd via bitcoin-dev
On Thu, Sep 03, 2015 at 01:34:54PM -0700, Dave Scotese via bitcoin-dev wrote: > I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and > 1,024,000 bytes. I believe the best policy is to use "megabyte" to mean > 2^20 (1,048,576) bytes. Kb always means 1024 bytes, even when a lot peopl

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

2015-09-03 Thread Andy Chase via bitcoin-dev
> Any such a BIP like this needs to > document the natural forces involved in real-world acceptance, not try to lay > down "rules" that people are expected to follow. That's my goal: to take the hodgepodge of we already use for acceptance, and apply rules that allow true acceptance to be identifie

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

2015-09-03 Thread Bryan Bishop via bitcoin-dev
On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev wrote: > I wrote the BIP mostly to stir the pot on ideas of governance Some quick comments: I have some objects that I am not ready to put into words, but I do think there are easily some major objections to committee design. If I vanish

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

2015-09-03 Thread Luke Dashjr via bitcoin-dev
On Friday, September 04, 2015 12:30:50 AM Andy Chase via bitcoin-dev wrote: > Here's a BIP. I wrote the BIP mostly to stir the pot on ideas of > governance, but I’m moderately serious about it. Sigh. There is *no governance at all*. Any such a BIP like this needs to document the natural forces in

[bitcoin-dev] [BIP/Draft] BIP Acceptance Process

2015-09-03 Thread Andy Chase via bitcoin-dev
Here’s a BIP. I wrote the BIP mostly to stir the pot on ideas of governance, but I’m moderately serious about it. This is set in Markdown for readability, but here’s the BIP-0001 Medawiki version: https://gist.github.com/andychase/dddb83c294295879308b

Re: [bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment

2015-09-03 Thread Gregory Maxwell via bitcoin-dev
On Fri, Sep 4, 2015 at 12:17 AM, Marco Pontello wrote: > None that I can see. > In fact I was just about to ask for some details about this part of the > process, so this come just at the right time. We used to have a WIKI page for all the BIP stuff and that worked better IMO, the use of git(hub)

Re: [bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment

2015-09-03 Thread Marco Pontello via bitcoin-dev
None that I can see. In fact I was just about to ask for some details about this part of the process, so this come just at the right time. On Fri, Sep 4, 2015 at 1:18 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The process in BIP01 was written when we use

[bitcoin-dev] Alpha release of METAmarket available for download NOW for Windows and Linux. Come help us test a new standard in P2P e-commerce!

2015-09-03 Thread Marc D. Wood via bitcoin-dev
I'm pleased to announce the newest contender in the field of decentralized e-commerce. 100% P2P and 100% customize-able. Using METAmarket, you can create your own market where you make the rules. Open to all or Private? Wholesale or retail? Moderated or unmoderated? Clearnet or Darknet? You are in

Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43

2015-09-03 Thread Luke Dashjr via bitcoin-dev
On Tuesday, June 30, 2015 5:53:05 PM Justus Ranvier wrote: > Monetas has developed a Bitmessage address derivation method from an > HD seed based on BIP-43. > > https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki > > We're proposing this as a BIP per the BIP-43 recommendation in ord

[bitcoin-dev] Multi-chain payment channel nodes

2015-09-03 Thread Bryan Bishop via bitcoin-dev
Here is a brief overview of a way to use something like the lightning network, or another multi-hop payment channel network, to handle more transactions per second. These ideas were mentioned yesterday in #bitcoin-wizards and my email does not significantly elaborate on any of it (search for "cros

Re: [bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment

2015-09-03 Thread Btc Drak via bitcoin-dev
It's a good idea. It would remove friction from the process and assignment is auditable to boot, something I've had difficulty with in the past. Almost every time I see a BIP number I would wonder, is that self-assigned (and thus invalid) or has it been assigned by the BIP editor. On Fri, Sep 4, 2

[bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment

2015-09-03 Thread Gregory Maxwell via bitcoin-dev
The process in BIP01 was written when we used a different solution for storing and presenting BIPs. I'm thinking of suggesting that the number request process be changed to opening a pull req with BIP text with no number (e.g. just using the authors name and an index as the number) as the mechenis

[bitcoin-dev] Adhoc Bitcoin Network

2015-09-03 Thread jimsmit--- via bitcoin-dev
Hi, Is there a feature in Bitcoin that supports adhoc networks, that merge their work into the main Blockchain at some point? Thanks, Jim ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/list

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Dave Scotese via bitcoin-dev
I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and 1,024,000 bytes. I believe the best policy is to use "megabyte" to mean 2^20 (1,048,576) bytes. Kb always means 1024 bytes, even when a lot people round it, so I like the K spec best. I also see value in having human readable da

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Oliver Petruzel via bitcoin-dev
I agree with Simon's sentiments for question #1, and was actually going to pose the same question. Non-votes seem like they may poison the well mathematically, and counting them anyway seems to encourage a lack of participation at a time when miners really need to be very much involved. Since we're

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Simon Liu via bitcoin-dev
Hi Jeff, Thoughts on this part of the proposal: "Absent/invalid votes are counted as votes for the current hardLimit. Out of range votes are counted as the nearest in-range value." 1. Why should an absent vote be considered a vote for the status quo? A non-voter should have zero impact on the r

Re: [bitcoin-dev] block size - pay with difficulty

2015-09-03 Thread Gregory Maxwell via bitcoin-dev
On Thu, Sep 3, 2015 at 6:23 PM, Jorge Timón wrote: > Greg, I believe Jeff is focusing on BtcDrak's proposal ( > https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the > increased nBits are used to vote for the block size to raise > permanently ( or until it gets voted down). > His argume

Re: [bitcoin-dev] block size - pay with difficulty

2015-09-03 Thread Btc Drak via bitcoin-dev
Maybe Jeff can clarify but my communications with him seemed to imply he didn't think any kind of difficulty penalty scheme is workable. I strongly dispute that assertion. On Thu, Sep 3, 2015 at 7:23 PM, Jorge Timón wrote: > Greg, I believe Jeff is focusing on BtcDrak's proposal ( > https://gist.

Re: [bitcoin-dev] block size - pay with difficulty

2015-09-03 Thread jl2012 via bitcoin-dev
Assuming that: 1. The current block size is 1MB 2. The block reward for a full block is 25.5BTC including tx fee 3. Miner is required to pay x% of reward penalty if he is trying to increase the size of the next block by x% If a miner wants to increase the block size by 1 byte, the block size h

Re: [bitcoin-dev] block size - pay with difficulty

2015-09-03 Thread Tom Harding via bitcoin-dev
On 9/2/2015 9:05 PM, Jeff Garzik via bitcoin-dev wrote: Schemes proposing to pay with difficulty / hashpower to change block size should be avoided. The miners incentive has always been fairly straightforward - it is rational to deploy new hashpower as soon as you can get it online. Introduci

Re: [bitcoin-dev] block size - pay with difficulty

2015-09-03 Thread Jorge Timón via bitcoin-dev
Greg, I believe Jeff is focusing on BtcDrak's proposal ( https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the increased nBits are used to vote for the block size to raise permanently ( or until it gets voted down). His arguments don't seem to apply to your original proposal (where the s

Re: [bitcoin-dev] block size - pay with difficulty

2015-09-03 Thread Gregory Maxwell via bitcoin-dev
On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik wrote: > Expanding on pay-with-diff and volatility (closing comment), > > Users and miners will have significant difficulty creating and/or predicting > a stable block size (and fee environment) with pay-with-diff across the > months. The ability of bus

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Peter Todd via bitcoin-dev
On Thu, Sep 03, 2015 at 06:32:09PM +0100, Btc Drak via bitcoin-dev wrote: > Just use a 4-byte unsigned integer where the integer is the size in > bytes. It's concise and less complex (and less complex to implement). > There's no need for human readable strings here. Solid NACK on making string par

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Btc Drak via bitcoin-dev
Just use a 4-byte unsigned integer where the integer is the size in bytes. It's concise and less complex (and less complex to implement). There's no need for human readable strings here. On Thu, Sep 3, 2015 at 5:35 PM, Jeff Garzik via bitcoin-dev wrote: > Take a look at the latest update: > > - s

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Jeff Garzik via bitcoin-dev
Take a look at the latest update: - swiped Tier Nolan verbiage, which I agree was usefully more clear - added 'M' suffix and removed 'V' from coinbase scriptSig On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 1. I think there is no need

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread jl2012 via bitcoin-dev
1. I think there is no need to have resolution at byte level, while resolution at MB level is not enough. kB would be a better choice. 2. In my specification a v4 block without a vote is invalid, so there is no need to consider absent or invalid votes 3. We should allow miners to explicitly v

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Jorge Timón via bitcoin-dev
On Sep 3, 2015 5:58 PM, "Btc Drak via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik wrote: > > A discussion of rolling out BIP 100 will not be avoided :) > > > > It is a hard fork; it would be silly to elide discussion of these key > >

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Btc Drak via bitcoin-dev
On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik wrote: > A discussion of rolling out BIP 100 will not be avoided :) > > It is a hard fork; it would be silly to elide discussion of these key > issues. > > I don't get the community's recent interest in avoiding certain topics. It's not a matter of avoi

Re: [bitcoin-dev] block size - pay with difficulty

2015-09-03 Thread Jeff Garzik via bitcoin-dev
Expanding on pay-with-diff and volatility (closing comment), Users and miners will have significant difficulty creating and/or predicting a stable block size (and fee environment) with pay-with-diff across the months. The ability of businesses to plan is low. Chaos and unpredictability are bad i

Re: [bitcoin-dev] block size - pay with difficulty

2015-09-03 Thread Jeff Garzik via bitcoin-dev
It's written as 'a' and/or 'b'. If you don't have idle hashpower, then paying with difficulty requires some amount of collusion ('a') Any miner paying with a higher difficulty either needs idle hashpower, or self-increase their own difficulty at the possible *opportunity cost* of losing an entire

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Jeff Garzik via bitcoin-dev
Thanks - several good suggestions, including some in common. Will comment & revise today. Currently in "collecting" mode, to avoid duplicative comments in multiple locales. On Thu, Sep 3, 2015 at 3:57 AM, wrote: > Some comments: > > >- The 75% rule is meaningless here. Since this is a pu

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Jeff Garzik via bitcoin-dev
A discussion of rolling out BIP 100 will not be avoided :) It is a hard fork; it would be silly to elide discussion of these key issues. I don't get the community's recent interest in avoiding certain topics. On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak wrote: > We should avoid discussing actual

Re: [bitcoin-dev] block size - pay with difficulty

2015-09-03 Thread Jeff Garzik via bitcoin-dev
Thanks for the link. I readily admit only having given pay-to-future-miner a little bit of thought. Not convinced it sets a minimal tx fee in all cases. On Thu, Sep 3, 2015 at 12:55 AM, wrote: > Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到: > >> Schemes proposing to pay with difficulty /

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Tier Nolan via bitcoin-dev
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > >1. > >hardLimit floats within the range 1-32M, inclusive. > > > Does the 32MB limit actually still exist anywhere in the code? In effect, it is re-instating a legacy limitation. The

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Btc Drak via bitcoin-dev
We should avoid discussing actual hard fork/softfork deployment methodologies when discussing blocksize proposals because deployment is a separate issue. As a recent case in point, look at how BIP65 (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy. That lead to a focused discus

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread jl2012 via bitcoin-dev
Some comments: * The 75% rule is meaningless here. Since this is a pure relaxation of rules, there is no such thing as "invalid version 4 blocks" * The implication threshold is unclear. Is it 95% or 80%? * Softfork requires a very high threshold (95%) to "attack" the