On Wed, Nov 13, 2013 at 08:01:27PM +, John Dillon wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Last week I posted a writeup: On the optimal block size and why
transaction fees are 8 times too low (or transactions 8 times too big).
Peter Todd made some nice additions to it
While we're discussing the emotive (though actually of real relevance for
bitcoin user comprehension and sentiment) I couldnt resisnt to add some
trivia reference it is amusing that a currency rarely in history had to
deflate (remove 0s) rather than inflate (add 0s). Viz this hyperinflated
fifty
On Wed, Nov 13, 2013 at 12:52:21PM +0100, Michael Gronager wrote:
Last week I posted a writeup: On the optimal block size and why
transaction fees are 8 times too low (or transactions 8 times too big).
Peter Todd made some nice additions to it including different pool sizes
into the numbers.
On Fri, Nov 15, 2013 at 01:37:56AM -0800, Alex Kravets wrote:
Hi guys,
Alex, you're top-posting and not trimming your replies.
I've seen many many non-geeks be utterly intimidated and confused by
0.000X quantities and/or mBTC uBTC notation
Yes, people really can't tell any difference
On Wed, Nov 13, 2013 at 01:34:07PM +0100, Michael Gronager wrote:
Just a quick comment on the actual fees (checked at blockchain.info) the
average fee over the last 90 days is actually ~0.0003BTC/txn - so not
too far behind the theoretical minimum of 0.00037BTC/txn.
How did you get those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Peter,
Love to see things put into formulas - nice work!
Fully agree on the your fist section: As latency determines maximum
block earnings, define a 0-latency (big-miner never orphans his own
blocks) island and growing that will of course result
On Thu, Nov 07, 2013 at 10:58:42PM +0100, Michael Gronager wrote:
Q=0- f = 0.0033 BTC/kB Q=0.1 - f = 0.0027 BTC/kB Q=0.25 - f
= 0.0018 BTC/kB Q=0.40 - f = 0.0012 BTC/kB
You second list of numbers is an unlikely extreme:
k = 1mS/kB
The propagation latency in the network is more
On Fri, Nov 15, 2013 at 11:47:53AM +0100, Michael Gronager wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Peter,
Love to see things put into formulas - nice work!
Fully agree on the your fist section: As latency determines maximum
block earnings, define a 0-latency (big-miner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/11/13, 11:32 , Peter Todd wrote:
alpha = (1/113)*600s/134kBytes = 39.62uS/byte = 24kB/second
Which is atrocious...
alpha = P_fork*t_block/S = 1/113*454000/134 = 29ms/kb
or 272kbit pr second - if you assume this is a bandwidth then I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Q = Total pool size (fraction of all mining power) q = My mining
power (do.) e = fraction of block fee that pool reserves
Unfortunately the math doesn't work that way. For any Q, a bigger
Q gives you a higher return. Remember that the way I
On Fri, Nov 15, 2013 at 12:58:14PM +0100, Michael Gronager wrote:
My Q and q are meant differently, I agree to your Q vs Q-1 argument,
but the q is me as a miner participating in a pool Q. If I
participate in a pool I pay the pool owner a fraction, e, but at the
same time I become part of an
On Fri, Nov 15, 2013 at 12:47:46PM +0100, Michael Gronager wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/11/13, 11:32 , Peter Todd wrote:
alpha = (1/113)*600s/134kBytes = 39.62uS/byte = 24kB/second
Which is atrocious...
alpha = P_fork*t_block/S = 1/113*454000/134 =
It appears that someone is minting new blocks literally every couple of
seconds on the testnet chain right now.
You can see it on both blockexplorer:
http://blockexplorer.com/testnet
and also btclook:
http://testnet.btclook.com/
Is this something we should worry about?
thanks,
Mike
I don't use testnet much anymore, partly because it sometimes kind of
breaks like this. It's a public resource and people sometimes abuse it.
You can create your own local network with -regtest and that lets you mint
new blocks instantly. It's a much simpler way to do testing and app
development.
On Mon, Nov 04, 2013 at 11:11:34AM -0800, Mark Friedenbach wrote:
Now interpret the bits of that UUID as an allowed path: 0 = left, 1
= right, from the top of the tree. When you build the tree, make
sure everything that is going to be committed to uses it's allowed
path; the tree will look
On 14 November 2013 23:01, Luke-Jr l...@dashjr.org wrote:
I wonder if it might make sense to bundle some other terminology fixups at
the
same time.
A very good idea.
Right now, Bitcoin-Qt has been using the term confirmations (plural) to
refer to how many blocks deep a transaction is
On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
So a payment clears after one confirmation, but you might want to wait
until the payment has been confirmed n times.
Then at least you are not using the same word for two different meanings
and you're using stuff more familiar in popular
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/13 4:41 PM, Drak wrote:
For years, people had a problem with email address, instead
using email number but they got there eventually. Most people
nowadays use email address So payment address or bitcoin
address make better sense here
On Nov 15, 2013, at 05:10 PM, Luke-Jr l...@dashjr.org wrote:On Saturday, November 16, 2013 12:41:56 AM Drak wrote:So "a payment clears after one confirmation, but you might want to waituntil the payment has been confirmed n times".Then at least you are not using the same word for two different
On 16 November 2013 01:10, Luke-Jr l...@dashjr.org wrote:
On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
So a payment clears after one confirmation, but you might want to wait
until the payment has been confirmed n times.
Then at least you are not using the same word for two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/13 5:19 PM, Drak wrote:
Maybe, but again from the user's perspective they pay someone, and
they receive money - just like you do with paypal using an email
address. The technical bits in the middle dont matter to the user
and trying to
21 matches
Mail list logo
