public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] SatoshiDice and Near-term scalability
@ 2012-06-15 17:17 Jeff Garzik
  2012-06-15 17:52 ` Stefan Thomas
  2012-06-16  2:35 ` Jonathan Warren
  0 siblings, 2 replies; 5+ messages in thread
From: Jeff Garzik @ 2012-06-15 17:17 UTC (permalink / raw)
  To: bitcoin-development

On Fri, Jun 15, 2012 at 12:56 PM, Stefan Thomas <moon@justmoon•de> wrote:
> The artificial limits like the block size limit are essentially putting
[...]

Changing the block size is an item for the hard-fork list.  The chance
of the block size limit changing in the short term seems rather low...
 it is a "nuclear option."

Hard-fork requires a very high level of community buy-in, because it
shuts out older clients who will simply refuse to consider >1MB blocks
valid.

Anything approaching that level of change would need some good, hard
data indicating that SatoshiDice was shutting out the majority of
other traffic.  Does anyone measure mainnet "normal tx" confirmation
times on a regular basis?  Any other hard data?

Clearly SatoshiDice is a heavy user of the network, but there is a
vast difference between a good stress test and a network flood that is
shutting out non-SD users.

Can someone please help quantify the situation?  kthanks :)

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bitcoin-development] SatoshiDice and Near-term scalability
  2012-06-15 17:17 [Bitcoin-development] SatoshiDice and Near-term scalability Jeff Garzik
@ 2012-06-15 17:52 ` Stefan Thomas
  2012-06-16  2:35 ` Jonathan Warren
  1 sibling, 0 replies; 5+ messages in thread
From: Stefan Thomas @ 2012-06-15 17:52 UTC (permalink / raw)
  To: bitcoin-development

I do agree that changing/lifting the block size limit is a hard fork
measure, but Mike raised the point and I do believe that whatever we
decide to do now will be informed by our long term plan as well. So I
think it is relevant to the discussion.

> Can someone please help quantify the situation?  kthanks :)

According to BlockChain.info we seem to have lots of small blocks of
0-50KB and some larger 200-300 KB blocks. So in terms of near term
measure one thing I would like to know is why miners (i.e. no miners at
all) are fully exhausting the available block size despite thousands of
transactions in the memory pool. I'm not too familiar with the default
inclusion rules, so that would certainly be interesting to understand.
There are probably some low hanging fruit here.

The fact that SatoshiDice is able to afford to pay 0.0005 BTC fees and
fill up the memory pool means that either users who care about speedy
confirmation have to pay higher fees, the average actual block size has
to go up or prioritization has to get smarter. If load increases more
then we need more of any of these three tendencies as well. (Note that
the last one is only a very limited fix, because as the high priority
transactions get confirmed faster, the low priority ones take even longer.)


On 6/15/2012 7:17 PM, Jeff Garzik wrote:
> On Fri, Jun 15, 2012 at 12:56 PM, Stefan Thomas <moon@justmoon•de> wrote:
>> The artificial limits like the block size limit are essentially putting
> [...]
>
> Changing the block size is an item for the hard-fork list.  The chance
> of the block size limit changing in the short term seems rather low...
>  it is a "nuclear option."
>
> Hard-fork requires a very high level of community buy-in, because it
> shuts out older clients who will simply refuse to consider >1MB blocks
> valid.
>
> Anything approaching that level of change would need some good, hard
> data indicating that SatoshiDice was shutting out the majority of
> other traffic.  Does anyone measure mainnet "normal tx" confirmation
> times on a regular basis?  Any other hard data?
>
> Clearly SatoshiDice is a heavy user of the network, but there is a
> vast difference between a good stress test and a network flood that is
> shutting out non-SD users.
>
> Can someone please help quantify the situation?  kthanks :)
>




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bitcoin-development] SatoshiDice and Near-term scalability
  2012-06-15 17:17 [Bitcoin-development] SatoshiDice and Near-term scalability Jeff Garzik
  2012-06-15 17:52 ` Stefan Thomas
@ 2012-06-16  2:35 ` Jonathan Warren
  2012-06-16  4:33   ` Amir Taaki
  1 sibling, 1 reply; 5+ messages in thread
From: Jonathan Warren @ 2012-06-16  2:35 UTC (permalink / raw)
  To: bitcoin-development

Yes, I measure mainnet confirmation times on a regular basis.
http://bitcoinstats.org/post/tx-confirmation-times-June2012.png

Before fairly recently, fee-paying transactions never took anywhere close to
this long to be confirmed. 

Jonathan Warren
(Bitcointalk: Atheros)

-----Original Message-----
From: Jeff Garzik [mailto:jgarzik@exmulti•com] 
Sent: Friday, June 15, 2012 1:17 PM
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] SatoshiDice and Near-term scalability

Hard-fork requires a very high level of community buy-in, because it shuts
out older clients who will simply refuse to consider >1MB blocks valid.

Anything approaching that level of change would need some good, hard data
indicating that SatoshiDice was shutting out the majority of other traffic.
Does anyone measure mainnet "normal tx" confirmation times on a regular
basis?  Any other hard data?





^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bitcoin-development] SatoshiDice and Near-term scalability
  2012-06-16  2:35 ` Jonathan Warren
@ 2012-06-16  4:33   ` Amir Taaki
  2012-06-16  8:30     ` Mike Hearn
  0 siblings, 1 reply; 5+ messages in thread
From: Amir Taaki @ 2012-06-16  4:33 UTC (permalink / raw)
  To: bitcoin-development

Did anyone try sending them an email asking them to stop or offering help to fix their site? What did they say? I'm sure they would try to be accomodating.



----- Original Message -----
From: Jonathan Warren <jonathan@bitcoinstats•org>
To: bitcoin-development@lists•sourceforge.net
Cc: 
Sent: Saturday, June 16, 2012 4:35 AM
Subject: Re: [Bitcoin-development] SatoshiDice and Near-term scalability

Yes, I measure mainnet confirmation times on a regular basis.
http://bitcoinstats.org/post/tx-confirmation-times-June2012.png

Before fairly recently, fee-paying transactions never took anywhere close to
this long to be confirmed. 

Jonathan Warren
(Bitcointalk: Atheros)

-----Original Message-----
From: Jeff Garzik [mailto:jgarzik@exmulti•com] 
Sent: Friday, June 15, 2012 1:17 PM
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] SatoshiDice and Near-term scalability

Hard-fork requires a very high level of community buy-in, because it shuts
out older clients who will simply refuse to consider >1MB blocks valid.

Anything approaching that level of change would need some good, hard data
indicating that SatoshiDice was shutting out the majority of other traffic.
Does anyone measure mainnet "normal tx" confirmation times on a regular
basis?  Any other hard data?



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bitcoin-development] SatoshiDice and Near-term scalability
  2012-06-16  4:33   ` Amir Taaki
@ 2012-06-16  8:30     ` Mike Hearn
  0 siblings, 0 replies; 5+ messages in thread
From: Mike Hearn @ 2012-06-16  8:30 UTC (permalink / raw)
  To: Amir Taaki; +Cc: bitcoin-development

Joseph is quite accommodating and doesn't want to hurt the network.
That said "asking him to stop" seems like the worst possible solution
possible. His site is quite reasonable.

I think if I fix bitcoinj to have smarter fee code he might stop
attaching a small fee to every TX, but I'm not sure.

On Sat, Jun 16, 2012 at 6:33 AM, Amir Taaki <zgenjix@yahoo•com> wrote:
> Did anyone try sending them an email asking them to stop or offering help to fix their site? What did they say? I'm sure they would try to be accomodating.
>
>
>
> ----- Original Message -----
> From: Jonathan Warren <jonathan@bitcoinstats•org>
> To: bitcoin-development@lists•sourceforge.net
> Cc:
> Sent: Saturday, June 16, 2012 4:35 AM
> Subject: Re: [Bitcoin-development] SatoshiDice and Near-term scalability
>
> Yes, I measure mainnet confirmation times on a regular basis.
> http://bitcoinstats.org/post/tx-confirmation-times-June2012.png
>
> Before fairly recently, fee-paying transactions never took anywhere close to
> this long to be confirmed.
>
> Jonathan Warren
> (Bitcointalk: Atheros)
>
> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@exmulti•com]
> Sent: Friday, June 15, 2012 1:17 PM
> To: bitcoin-development@lists•sourceforge.net
> Subject: [Bitcoin-development] SatoshiDice and Near-term scalability
>
> Hard-fork requires a very high level of community buy-in, because it shuts
> out older clients who will simply refuse to consider >1MB blocks valid.
>
> Anything approaching that level of change would need some good, hard data
> indicating that SatoshiDice was shutting out the majority of other traffic.
> Does anyone measure mainnet "normal tx" confirmation times on a regular
> basis?  Any other hard data?
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-06-16  8:30 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-15 17:17 [Bitcoin-development] SatoshiDice and Near-term scalability Jeff Garzik
2012-06-15 17:52 ` Stefan Thomas
2012-06-16  2:35 ` Jonathan Warren
2012-06-16  4:33   ` Amir Taaki
2012-06-16  8:30     ` Mike Hearn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox