Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QwGvV-0004lD-EF for bitcoin-development@lists.sourceforge.net; Wed, 24 Aug 2011 17:07:41 +0000 X-ACL-Warn: Received: from mail-gy0-f175.google.com ([209.85.160.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QwGvT-0001uB-5d for bitcoin-development@lists.sourceforge.net; Wed, 24 Aug 2011 17:07:41 +0000 Received: by gyg4 with SMTP id 4so1284950gyg.34 for ; Wed, 24 Aug 2011 10:07:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.154.3 with SMTP id o3mr2076215icw.221.1314205653362; Wed, 24 Aug 2011 10:07:33 -0700 (PDT) Received: by 10.42.244.130 with HTTP; Wed, 24 Aug 2011 10:07:33 -0700 (PDT) In-Reply-To: References: <201108241215.36847.luke@dashjr.org> Date: Wed, 24 Aug 2011 10:07:33 -0700 Message-ID: From: Rick Wesson To: Gregory Maxwell Content-Type: multipart/alternative; boundary=90e6ba6e83f021694c04ab435960 X-Spam-Score: 1.4 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message 0.4 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QwGvT-0001uB-5d Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 17:07:41 -0000 --90e6ba6e83f021694c04ab435960 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 24, 2011 at 9:46 AM, Gregory Maxwell wrote: > On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr wrote: > > > - Replace hard limits (like 1 MB maximum block size) with something that > can > > dynamically adapt with the times. Maybe based on difficulty so it can't > be > > gamed? > > Too early for that. > > Could you provide a reference to why in your estimation it is "to early." Simpy stating this as fact isn't enough to sway demand. > - Adjust difficulty every block, without limits, based on a N-block > sliding > > window. I think this would solve the issue when the hashrate drops > > overnight, but maybe also add a block time limit, or perhaps include the > > "current block" in the difficulty calculation? > > The quantized scheme limits the amount of difficulty skew miners can > create by lying about timestamps to about a half a percent. A rolling > window with the same time constant would allow much more skew. > > > Replacing the "Satoshi" 64-bit integers with > > "Satoshi" variable-size fractions (ie, infinite numerator + denominator) > > Increasing precision I would agree with but, sadly, causing people to > need more than 64 bit would create a lot of bugs. > > how about we agree that increasing precision is a goal and worry about how to encode that once its on the road map. > infinite numerator + denominator is absolutely completely and totally > batshit insane. For one, it has weird consequences that the same value > can have redundant encodings. > > Most importantly, it suffers factor inflation: If you spend inputs > 1/977 1/983 1/991 1/997 the smallest denominator you can use for the > output 948892238557. > > Not to mention that the idiots writing financial software can only > barely manage to not use radix-2 floating point on everything. Asking > them to use arbitrary rational numbers with mixed radix will never > fly. > > > - Remove the 100 confirmation requirement for spending generated coins. > If > > they are respent before 100 confirmations, clients can/should flag the > new > > outputs as also "generated" or "recently generated" so recipients are > aware > > of the risk. > > Please lets not make bitcoin _less_ trustworthy. > > The 100 block maturity on generated coins is good. The generation from > an orphaning is lost forever like the losing side of a double spend, > but far far worse... because orphaning happens all the time on its own > without any malice. > > I agree it's obnoxious that you can't pad your generation payouts > without creating more transactions, but I don't see a solution for > that. Repeat the addresses... make up for it by increasing your payout > threshold. > > > ------------------------------------------------------------------------------ > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --90e6ba6e83f021694c04ab435960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 24, 2011 at 9:46 AM, Gregory= Maxwell <gmaxwe= ll@gmail.com> wrote:
On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr <luke@dashjr.org> wrote:

> - Replace hard limits (like 1 MB maximum block size) with something th= at can
> dynamically adapt with the times. Maybe based on difficulty so it can&= #39;t be
> gamed?

Too early for that.


Could you prov= ide a=A0reference=A0to why in your estimation it is "to early." = =A0Simpy stating this as fact isn't enough to sway demand.
> - Adjust difficulty every block, without limits, based on a N-block sl= iding
> =A0window. I think this would solve the issue when the hashrate drops<= br> > =A0overnight, but maybe also add a block time limit, or perhaps includ= e the
> =A0"current block" in the difficulty calculation?

The quantized scheme limits the amount of difficulty skew miners can<= br> create by lying about timestamps to about a half a percent. A rolling
window with the same time constant would allow much more skew.

> Replacing the "Satoshi" 64-bit integers with
> "Satoshi" variable-size fractions (ie, infinite numerator + = denominator)

Increasing precision I would agree with but, sadly, causing people to=
need more than 64 bit would create a lot of bugs.


how about we agree that=A0increasing= =A0precision is a goal and worry about how to encode that once its on the r= oad map.

=A0
infinite numerator + denominator is absolutely completely and totally
batshit insane. For one, it has weird consequences that the same value
can have redundant encodings.

Most importantly, it suffers factor inflation: If you spend inputs
1/977 1/983 1/991 1/997 the smallest denominator you can use for the
output 948892238557.

Not to mention that the idiots writing financial software can only
barely manage to not use radix-2 floating point on everything. Asking
them to use arbitrary rational numbers with mixed radix will never
fly.

> - Remove the 100 confirmation requirement for spending generated coins= . If
> =A0they are respent before 100 confirmations, clients can/should flag = the new
> =A0outputs as also "generated" or "recently generated&q= uot; so recipients are aware
> of the risk.

Please lets not make bitcoin _less_ trustworthy.

The 100 block maturity on generated coins is good. The generation from
an orphaning is lost forever like the losing side of a double spend,
but far far worse... because orphaning happens all the time on its own
without any malice.

I agree it's obnoxious that you can't pad your generation payouts without creating more transactions, but I don't see a solution for
that. Repeat the addresses... make up for it by increasing your payout
threshold.

---------------------------------------------------------------------------= ---
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--90e6ba6e83f021694c04ab435960--