Re: [bitcoin-dev] BIP 100 specification

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.

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

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

Re: [bitcoin-dev] BIP 100 specification

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

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

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

Re: [bitcoin-dev] BIP 100 specification

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

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

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.

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

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

Re: [bitcoin-dev] BIP 100 specification

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

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

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

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

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

Re: [bitcoin-dev] BIP 100 specification

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

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

Re: [bitcoin-dev] BIP 100 specification

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

Re: [bitcoin-dev] BIP 100 specification

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

Re: [bitcoin-dev] BIP 100 specification

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

Re: [bitcoin-dev] BIP 100 specification

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

[bitcoin-dev] Adhoc Bitcoin Network

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

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

On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev wrote: > (b) requiring miners to have idle > hashpower on hand to change block size are both unrealistic and potentially I really cannot figure out how you could characterize pay with difficty has

Re: [bitcoin-dev] BIP 100 repo

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Excellent - thank you. Jeff Garzik via bitcoin-dev: > Oops, link paste fail. > > The repo: https://github.com/jgarzik/bip100 > > > On Wed, Sep 2, 2015 at 7:51 PM, Jeff Garzik > wrote: > >> Opened a repo containing the full

Re: [bitcoin-dev] BIP 100 specification

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

Re: [bitcoin-dev] BIP 100 specification

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

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

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] [BIP/Draft] BIP Acceptance Process

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

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

> 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

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

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

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

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

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

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

[bitcoin-dev] Multi-chain payment channel nodes

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

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

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

Re: [bitcoin-dev] BIP 100 specification

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