Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
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 including different pool sizes
into the numbers.
Peter claims on IRC that he is writing a paper of some kind on this topic. I
suggest he submit it to that crypto-currency thing the foundation is
sponsoring. Given the Nov 24th deadline, I also suggest at least making part
of
it public ASAP so some peer review can be done. It would be a shame for a
simple math error to cause embarassment later.
Here's what I've got to date. The first two sections is just a
relatively simple proof that mining is more profitable as centralization
increases under any circumstance, even before any real-world factors are
taken into account. (other than non-zero latency and bandwidth) Nice
homework problem, and neat that you can easily get a solid proof, but
academic because it doesn't say anything about the magnitude of the
incentives.
The latter part is the actual derivation with proper model of
supply-and-demand for fees. Or will be: while you can of course solve
the equations with mathematica or similar - getting a horrid mess - I'm
still trying to see if I can simplify them sanely in a way that's
step-by-step understandable. Taking me longer than I'd like; sobering to
realize how rusty I am. That said if any you do just throw it at
Mathematica, looks like you get a result where the slope of your
expected block return is at least quadratic with increasing hashing
power. (though I spent all of five minutes eyeballing that result)
\documentclass{article}
\usepackage{url}
\usepackage{mathtools}
\begin{document}
\title{Expected Return}
\author{Peter Todd}
\date{FIXME}
\maketitle
\section{Expected return of a block}
\label{sec:exp-return-of-a-block}
Let $f(L)$, a continuous function,\footnote{Transactions do of course give a
discontinuous $f$. For a large $L$ the approximation error is negligible.} be
the fee-per-byte available to a rational miner for the last transaction
included in a block of size $L$. $f(L)$ is a continuous function defined for $L
\ge 0$. Supply and demand dictates that:
\begin{equation}
f(L) \ge f(L+\epsilon) \label{eq:f-increases}
\end{equation}
A reasonable example for $f$ might be $f(L) = kL$, representing the demand side
of a linear supply and demand plot. For a block of size $L$ that is optimally
filled with transactions the value of those fees is just the integral:
\begin{equation}
E_f(L) = \int_0^L f(l)\,dl
\end{equation}
Let $P(Q,L)$, a continuous function, be the probability that a block of size
$L$ produced by a miner with relative hashing power $Q$ will be orphaned.
Because a miner will never orphan their own blocks the following holds true:
\begin{equation}
P(Q,L) \le P(Q + \epsilon,L) \label{eq:p-increases}
\end{equation}
Similarly because larger blocks take longer to propagate and thus risk getting
orphaned by another miner finding a block at the same time:
\begin{equation}
P(Q,L) \ge P(Q,L + \epsilon)
\end{equation}
By combining $P(Q, L)$, $E_f(L)$ and the inflation subsidy $B$, gives us the
expected return of a block for a given size and hashing power:\footnote{Note
how real world marginal costs can be accommodated easily in the definitions of
$f$ and $B$.}
\begin{equation}
E(Q,L) = P(Q,L)[E_f(L) + B]
\end{equation}
The optimal size is simply the size $L$ at which $E(Q, L)$ no longer increases:
\begin{equation}
\frac{d}{dL}\big[E(Q, L(Q))\big] = 0
\end{equation}
We will define the function $L(Q)$ as the optimal value for a given $Q$. A
miner creating optimal blocks will thus have an expected return per block found
of $E'(Q)=E(Q,L(Q))$. Note how this definition is per unit hashing power by
virtue of being per block found.
\section{Optimal return $E'$ vs. hashing power $Q$}
We want to know if a large miner has a larger return for a given amount of
hashing power. We do this by taking the derivative with respect to $Q$ of the
expected return given optimal strategy:
\begin{align*}
\frac{d}{dQ}\big[E'(Q)\big] =
\frac{d}{dQ}\big[P(Q,L(Q))\big]\big[E_f(L(Q)) + B\big] +
P(Q,L(Q))\frac{d}{dQ}\big[E_f(L(Q))\big] \\
=
\frac{dL(Q)}{dQ}\Big[\frac{dP(Q,L(Q))}{dQ}\big[E_f(L(Q)) + B\big] +
P(Q,L)\frac{dE_f(L(Q))}{dQ}\Big]
\end{align*}
We know that $L(Q)$, $E_f$, $P$, and $B$ are all $\ge 0$. Thus for $dE'/dQ$ to
be negative requires either $dL/dQ$ to be negative, or for $dL/dQ$ to be
positive and one of $dP/dQ$ or $dE_f/dQ$ negative.
Suppose $dP/dQ$ negative and $dL/dQ$ positive:
\begin{align}
\frac{dL(Q)}{dQ} 0\implies L(Q + \epsilon) L(Q) \notag \\
\frac{dP(L(Q))}{dQ} 0 \implies P(Q + \epsilon, L(Q + \epsilon)) P(Q,
L(Q)) \label{eq:dl-pos-dp-neg}
\end{align}
But that contradicts our definition
Re: [Bitcoin-development] moving the default display to mbtc
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 trillion zimbabwe dollar note I carry in my wallet for bitcoin contrast/amusement purposes: http://www.ebay.com/itm/50-TRILLION-ZIMBABWE-DOLLARS-CURRENCY-MONEY-US-SELLER-/110671104681 I like Alan's suggestion to show both to avoid denomination confusion. That is the one danger, and high risk given irrevocability. Adam -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
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. However, it occurred to me that things can in fact be calculated even simpler: The measured fork rate will mean out all the different pool sizes and network latencies and will as such provide a simple number we can use to estimate the minimum fee. Key assumption is that the latency will depend on block size (# txns) and the fork rate will depend on latency. Using the formulas from last week: P_fork = t_propagate/t_blocks and: t_propagate = t_0 + alpha*S ~= alpha*S Assuming t_0 is negligible is wrong in this case. Or, it should be... We get a measure for alpha as a function of the average fork rate and average block size: alpha = P_fork*t_block/S So alpha has units of seconds/byte, which lets us indirectly figure out the bandwidth the blocks are propagating at assuming t_0=0 and all links are equal. When you realize that P_fork is basically a multiplier on the bandwidth required to get a block out fast enough, the derivation makes sense. In any case we get: alpha = (1/113)*600s/134kBytes = 39.62uS/byte = 24kB/second Which is atrocious... but when you remember that Bitcoin nodes send blocks to all peers simultaneously,(1) thus dividing up the bandwidth and ruining latency you see why. t_0 shouldn't be at all negligible due to speed of light, but with this low bandwidth it is anyway. 1) To be precise, nodes answer queries for blocks from all peers simultaneously. This also indicates that pools haven't taken the simple step of peering with each other using high-bandwidth nodes with restricted numbers of peers, which shows you how little attention they are paying to optimizing profits. Right now mining pulls in $1.8 million/day, so that's up to $16k wasted. However, because miners don't orphan themselves, that $16k loss is born disproportionately by smaller miners... which also means the 24kB/sec bandwidth estimate is wrong, and the real number is even worse. In theory anyway, could just as easily be the case that larger pools have screwed up relaying still such that p2pool's forwarding wins. -- 'peter'[:-1]@petertodd.org 000658459cd64e63243e719106014257870d073207c2d5460137 signature.asc Description: Digital signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
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 between mm, cm, m, dm and km. Not. Yes, $10 being rougnly 10,000 Won in South Korean is a great example where large amounts of units work very well in a major economy. You're trying to invent a new symbol for the same unit, instead of using an established, generic system of prefixes. That's pretty insane. FWIW, I would prefer the entire switch-over be done *once* *and *at the same time switching both BTC to XBT and using the following I would prefer that nobody does any such silly thing. Currency Code *: *XBT Unit Definition *: *1 Bit = 100 Satoshis Addition benefit is splitting the term Bitcoin/bitcoin (as in Network and currency unit) into Bitcoin (network) and Bit (the unit). Bitcoin is not measured in bits. Bits are units of information, and are measured in bits, kbits, Mbits, Gbits, Tbits, Pbits etc. http://en.wikipedia.org/wiki/Bit_rate Perhaps this project/process should have a name and be listed on a road map somewhere What would a sane person think if he saw that on the roadmap, you think? *BRCS: *Bitcoin Re-denomination and [Currency] Code Standardization project Ever heard of SI unit prefixes? http://en.wikipedia.org/wiki/Metric_prefix Cheers ... On Fri, Nov 15, 2013 at 1:23 AM, Eugen Leitl eu...@leitl.org wrote: On Thu, Nov 14, 2013 at 05:53:16PM -0500, Alan Reiner wrote: I really like the XBT idea. It makes a lot of sense to match the ISO I really don't. Just use the SI prefixes. currency symbol (though the ISO guys will have to adjust the way they've defined the XBT). And I do agree that going right to uBTC and skipping mBTC makes sense, too. The display units should be choosable by the user. I'd prefer them not be called micro bitcoins. I really want to call them microbes ... but I'm not sure that has the right flavor for money Why on earth? transfer :) Please give me 872 microbes. Perhaps we just call them bits. Or even micros or microbits. As I write this, I realize there's probably 872 threads on the forums about this already... But we would want to promote a consistent term, to avoid further confusion when people use different names for the new unit. It's not guaranteed to be successful, but if we pick a good name, and build it into the interface on the first release pushing the new unit, we have a chance to make the transition even easier. The reason SI prefixes were invented is exactly to preven that case. -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Alex Kravets http://www.linkedin.com/in/akravets def redPill = ' Scala http://www.scala-lang.org/ [[ brutal honesty http://goo.gl/vwydt is the best policy ]] -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
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 numbers exactly? Also fee per txn is *not* useful and we really shouldn't quote it so that newbies reading this stuff get the right understanding. -- 'peter'[:-1]@petertodd.org 00075ed91531e07d2045b5823da050fe373bde7bb363965e44ae signature.asc Description: Digital signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
-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 in increased earnings.
So build your own huge mining data center and you rock.
However, that is hardly the real work scenario today. Instead we have
pools (Huge pools). It would be interesting to do the calculation:
Q = Total pool size (fraction of all mining power)
q = My mining power (do.)
e = fraction of block fee that pool reserves
It is pretty obvious that given your formulas small miners are better
off in a pool (can't survive as solo miners), but there will be a
threshold q_min above which you are actually better off on you own -
depending also on e. (excluding here all benefits of a stable revenue
stream provided by pools)
Next interesting calculation would be bitcoin rate as a function of pool
size, I expect a sharp dip somewhere in the 40%s of hardware controlled
by one entity ;)
Finally, as you mention yourselves, qualification of the various
functions is needed. This could e.g. suggest if we are like to get 3 or
10 miners on the long run.
And now for section 2. You insert a definition of f(L) = a-bL. I think
the whole idea of letting f depend on L is superfluous. As a miner you
are always free to choose which transactions to include. You will always
choose those with the biggest fee, so really it is only the average fee
that is relevant: f(L) = c. Any dependence in L will be removed by the
reshuffeling. To include an extra transaction will require either that
it has a fee larger than another (kicking that out out) or that it has a
fee so large that it covers for the other transaction too. Also recall
that there is a logical minimum fee (as I have already shown), and a
maximum optimal block size - that is until the bounty becomes 0 (which
is where other effects kick in).
Here's what I've got to date. The first two sections is just a
relatively simple proof that mining is more profitable as centralization
increases under any circumstance, even before any real-world factors are
taken into account. (other than non-zero latency and bandwidth) Nice
homework problem, and neat that you can easily get a solid proof, but
academic because it doesn't say anything about the magnitude of the
incentives.
The latter part is the actual derivation with proper model of
supply-and-demand for fees. Or will be: while you can of course solve
the equations with mathematica or similar - getting a horrid mess - I'm
still trying to see if I can simplify them sanely in a way that's
step-by-step understandable. Taking me longer than I'd like; sobering to
realize how rusty I am. That said if any you do just throw it at
Mathematica, looks like you get a result where the slope of your
expected block return is at least quadratic with increasing hashing
power. (though I spent all of five minutes eyeballing that result)
\documentclass{article}
\usepackage{url}
\usepackage{mathtools}
\begin{document}
\title{Expected Return}
\author{Peter Todd}
\date{FIXME}
\maketitle
\section{Expected return of a block}
\label{sec:exp-return-of-a-block}
Let $f(L)$, a continuous function,\footnote{Transactions do of course give a
discontinuous $f$. For a large $L$ the approximation error is negligible.} be
the fee-per-byte available to a rational miner for the last transaction
included in a block of size $L$. $f(L)$ is a continuous function defined for
$L
\ge 0$. Supply and demand dictates that:
\begin{equation}
f(L) \ge f(L+\epsilon) \label{eq:f-increases}
\end{equation}
A reasonable example for $f$ might be $f(L) = kL$, representing the demand
side
of a linear supply and demand plot. For a block of size $L$ that is optimally
filled with transactions the value of those fees is just the integral:
\begin{equation}
E_f(L) = \int_0^L f(l)\,dl
\end{equation}
Let $P(Q,L)$, a continuous function, be the probability that a block of size
$L$ produced by a miner with relative hashing power $Q$ will be orphaned.
Because a miner will never orphan their own blocks the following holds true:
\begin{equation}
P(Q,L) \le P(Q + \epsilon,L) \label{eq:p-increases}
\end{equation}
Similarly because larger blocks take longer to propagate and thus risk getting
orphaned by another miner finding a block at the same time:
\begin{equation}
P(Q,L) \ge P(Q,L + \epsilon)
\end{equation}
By combining $P(Q, L)$, $E_f(L)$ and the inflation subsidy $B$, gives us the
expected return of a block for a given size and hashing power:\footnote{Note
how real world marginal costs can be accommodated easily in the definitions of
$f$ and $B$.}
\begin{equation}
E(Q,L) = P(Q,L)[E_f(L) + B]
\end{equation}
The optimal size is simply the size $L$ at which $E(Q,
Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)
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 due to the block verification than due to its network (fiber) propagation time, bringing down the number of hops helps tremendously, so I agree that we can probably bring down k by a factor of ~10 (k=8-12) if we consider only pools directly connected. This should bring us close to break even with the current fee size, but we should really get some empirical data for interconnected large pools. Well if large pools wanted it would be trivial for all of them to just connect to each other... but my 25kB/s average data rate sure indicates that they either aren't bothering, or aren't bothering to do that correctly. However - important note - if you are a 1% miner - don't include transactions! Which is an awful solution, although probably a correct one After all, if you don't include transactions, you can start mining blocks earlier too based on just the header. Q=0- f = 0.42 BTC/kB Q=0.1 - f = 0.34 BTC/kB Q=0.25 - f = 0.23 BTC/kB Q=0.40 - f = 0.15 BTC/kB This problem is inherent to the fundemental design of Bitcoin: regardless of what the blocksize is, or how fast the network is, the current Bitcoin consensus protocol rewards larger mining pools with lower costs per KB to include transactions. I don't see a problem of rewarding economy of scale, as long as the effect is not too grave (raising the min fee would actually make it more profitable for smaller miners). That's a fundemental misunderstanding; there's no such thing as a min fee. As for economies of scale, the product we're paying miners for is decentralization and resistance to 51% attack. If instead only get 51% attack resistance, we're getting a bum deal. If that's all we're getting, we don't actually have 51% resistance... -- 'peter'[:-1]@petertodd.org 00075ed91531e07d2045b5823da050fe373bde7bb363965e44ae signature.asc Description: Digital signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
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 never orphans his own blocks) island and growing that will of course result in increased earnings. So build your own huge mining data center and you rock. However, that is hardly the real work scenario today. Instead we have pools (Huge pools). It would be interesting to do the calculation: Q = Total pool size (fraction of all mining power) q = My mining power (do.) e = fraction of block fee that pool reserves It is pretty obvious that given your formulas small miners are better off in a pool (can't survive as solo miners), but there will be a threshold q_min above which you are actually better off on you own - depending also on e. (excluding here all benefits of a stable revenue stream provided by pools) Unfortunately the math doesn't work that way. For any Q, a bigger Q gives you a higher return. Remember that the way I setup those equations in section 3.2 is such that I'm actually modeling two pools, one with Q hashing power and one with (1-Q) hashing power. Or maybe more accurately, it's irrelevant if the (1-Q) hashing power is or isn't a unified pool. The other thing is the fraction of the block fee the pool reserves indicates you're talking about real-world costs... and the moment you do that you find that pools themselves have economies of scale simply by virtue of using a small overhead infrastructure, their nodes etc., for a large number of miners. On that basis alone a small miner joining a larger pool would always be financially advantageous modulo situations where the large pool had legal restrictions that artificially increased their overheads. Next interesting calculation would be bitcoin rate as a function of pool size, I expect a sharp dip somewhere in the 40%s of hardware controlled by one entity ;) Bitcoin rate? Finally, as you mention yourselves, qualification of the various functions is needed. This could e.g. suggest if we are like to get 3 or 10 miners on the long run. The equations give an incentive to centralize all the way up to 1 miner with 100% hashing power. Of course, if that one pool were p2pool, that might be ok! And now for section 2. You insert a definition of f(L) = a-bL. I think the whole idea of letting f depend on L is superfluous. As a miner you are always free to choose which transactions to include. You will always choose those with the biggest fee, so really it is only the average fee that is relevant: f(L) = c. Any dependence in L will be removed by the reshuffeling. To include an extra transaction will require either that it has a fee larger than another (kicking that out out) or that it has a fee so large that it covers for the other transaction too. Also recall that there is a logical minimum fee (as I have already shown), and a maximum optimal block size - that is until the bounty becomes 0 (which is where other effects kick in). By defining f(L) you can model supply and demand, which can be relevant in that a steep demand curve with a small number of high-fee transactions can reduce centralization pressure in my model. Of course, by defining f(L) = a-bL you also wind up with mathematica spitting out some truly hideous polynomials. :P Setting f(L) = c as you suggest is something I looked at, and results in equations that are more reasonable, so I think I'll likely wind up doing that. You can make a good argument anyway that the centralization would cause a flattening of any demand curve anyway, as in the no-blocksize-limit case the larger pools cost per transaction tends towards zero as their hashing power increases - why pay high fees when the large pool will mine them almost as fast? -- 'peter'[:-1]@petertodd.org b4ff49cd2cad865d6cbca99828987a02f3d5f41067eab00a signature.asc Description: Digital signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
-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 agree it is strikingly small (ISDN like), but this is not the case, the size dependence of this number originates both from the limited network bandwidth and from the validation and verification time of the blocks as well as the latency in sending thee again. The connection between propagation time and fork rate cannot be denied, and the bandwidth can be deducted from that alone - see Decket et al. t_0 on a 1km link is on the order of 40ms, and that is only counting the finite light speed in the fibers - if you ping the same distance you get roughly 1-200ms (due to latencies in network equipment). at a size of ~100kbyte t_0 hence becomes irrelevant. This also indicates that pools haven't taken the simple step of peering with each other using high-bandwidth nodes with restricted numbers of peers agree , which shows you how little attention they are paying to optimizing profits. Right now mining pulls in $1.8 million/day, so that's up to $16k wasted. yup, but the relevant comparison is not 16k vs 1.8m, but the pool operator earnings which are on the order of 1% of the 1.8m so it is 18k vs 16k - I wouldn't mind doubling my income... However, because miners don't orphan themselves, that $16k loss is born disproportionately by smaller miners... which also means the 24kB/sec bandwidth estimate is wrong, and the real number is even worse. Yes, agree In theory anyway, could just as easily be the case that larger pools have screwed up relaying still such that p2pool's forwarding wins. Yeah, we should resurrect p2pool ;) -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJShgniAAoJEKpww0VFxdGRrwQIALKsOtBUaAaQTX9ikN+10mSE pE2dp2VnUvfUqpXf3MgJtAvg2RFqHjziyBMYmpMw5tLJPpeUthpNXm6Vm/Yg0DdL JXSESIrd4Pdb/xPk2Fh9OKHmR1SB/8VxtRL2Vj1HmzzBcBiCylcaBuKlRkizvGSF KrUm3EOFUfzgGYFUnqNceZ3CuQHWFAXbsitNqU6Vop8JOTgiSLhUrvb7r3W7Ewuy jM3H2KAk/PrdGXwna3sUfDXmmOxmPm1pBy6+OaBTHEv+ALkreD++XSUnLUUTky9N nZt2g7eMEFHIkVooj/HOGiwAvVwd7r86etiyUi8c2Pd46ff2OP5h1uiP/Qr28MA= =Bsv9 -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
-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 setup those equations in section 3.2 is such that I'm actually modeling two pools, one with Q hashing power and one with (1-Q) hashing power. Or maybe more accurately, it's irrelevant if the (1-Q) hashing power is or isn't a unified pool. 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 economy of scale (well actually a math of scale...) and that can end up paying for the lost e. The question is what is the ratio q/Q where I should rather mine on my own ? This question is interesting as it will make bigger miners break away from pools into solo mining, but I also agree that from pure math the most advantageous scenario is the 100% mining rig. The equations give an incentive to centralize all the way up to 1 miner with 100% hashing power. Of course, if that one pool were p2pool, that might be ok! Ha, yes, and then the math for p2pool starts... a math where we have much more stales... -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJShgxWAAoJEKpww0VFxdGRoiwH/3RGTH503PJ8UWuyKjrxscb4 dG3TyThZCDs12DvtC+2TPKnIkQFinGx9442tZU/O+qmwsGJsNVoEcnGmKEYz/vlI XzFF30ugslB4FKwHZYRqXELaKR4RvUtSzu6td8P3n+e6d0MZsuemMornpbXZkw3n CbMlYuiG4h3iUAwTaOTS26cFbZoo6eyogydDjnS7Ogi2Ur85Rydi/Lj24rj7UxYB +WUkYAv3bCqCzTkv1LxO7HwY1SICZDmoGRbuil5M7bJ+MftYt6Q6DVprGSVP0mOV 9eEVeMVY/WmMZCI/01ruXpzC3gxU60vOd/a3q9G2hd9Tn00HzugAllEXh7ZzzUs= =unP8 -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
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 economy of scale (well actually a math of scale...) and that can end up paying for the lost e. The question is what is the ratio q/Q where I should rather mine on my own ? This question is interesting as it will make bigger miners break away from pools into solo mining, but I also agree that from pure math the most advantageous scenario is the 100% mining rig. The underlying issue is what is the pools expenses compared to yours. There is an overhead to mining, you need to spend money and time (and hence money) running and administering full nodes at the very minimum. The pool can amortise that cost over many hashers; the solo miner can't. Pools will of course have some profit margin, but why would you expect that margin to not be sufficiently low to make it in a solo-miner's interest to join the pool? Both the pool and the former solo-miner earn more return after all if they centralize. The fundemental issue is that in the design of Bitcoin there is an incentive for miners to join into pools, and that incentive exists at any amount of hashing power. Sure second order effects like regulation and social pressure can counteract that incentive in some circumstances, but that's not very strong protection. The equations give an incentive to centralize all the way up to 1 miner with 100% hashing power. Of course, if that one pool were p2pool, that might be ok! Ha, yes, and then the math for p2pool starts... a math where we have much more stales... However p2pool doesn't necessarily need a linear blockchain to function, so there is a potential for stales to be much less relevant. -- 'peter'[:-1]@petertodd.org 000772f720b0a231150f22af20760c1463ef920f71ba3daab819 signature.asc Description: Digital signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize
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 = 29ms/kb Huh? Where did 454000 come from? , which shows you how little attention they are paying to optimizing profits. Right now mining pulls in $1.8 million/day, so that's up to $16k wasted. yup, but the relevant comparison is not 16k vs 1.8m, but the pool operator earnings which are on the order of 1% of the 1.8m so it is 18k vs 16k - I wouldn't mind doubling my income... That's only true for a PPS pool though, not the more usual pools that pay relative to blocks actually found. Heh, actually, that might be part of the problem... also doesn't help how varience is going to make noticing 1% hard. In theory anyway, could just as easily be the case that larger pools have screwed up relaying still such that p2pool's forwarding wins. Yeah, we should resurrect p2pool ;) P2Pool has 1% hashing power right now; I mine on it myself with what little hashing power I have. The more interesting thing is how do you grow P2Pool - requiring a full node is going to make that tricky. Also the once we start adding more efficient block propagation by transmitting headers + txids p2pool's current advantage goes away. -- 'peter'[:-1]@petertodd.org 0005fbc1840bbd5bd71d4d6cd2930e20da9e697710f58bd4f69d signature.asc Description: Digital signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Testnet under attack?
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 -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Testnet under attack?
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 Fri, Nov 15, 2013 at 8:34 PM, Mike Belshe m...@belshe.com wrote: 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 -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Committing to extra block data/a better merge-mine standard
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 a bit jagged. If everyone picks their per-purpose UUIDs randomly the paths won't collide for very many levels on average, and path lengths will remain short. Validating that some given data was committed properly is simple and easy: just check the path, and check that the directions from the top of the tree followed the spec. You mean... an authenticated prefix tree? Composable/commutative properties are not needed as far as I can see, so you could make the path validation, traversal, and proof size smaller by using level compression. You don't need level compression if you adopt my per-block randomization idea. I think we'd be better off keeping the proofs as simple as possible, just dumb merkle paths. I had previously proposed to this list a hash256-to-UUID mechanism explicitly for this purpose. Recap: use 122 of the low 128 bits of the aux-chain's genesis block to form a version=4 (random) or version=6 (previously unused) UUID. However since making that proposal I am now leaning towards simply using the hash of the genesis block directly to identify aux chains since level compression will allow longer keys with the same path length. I mentioned UUID more in spirit than in terms of the official UUID standard; any large randomly picked integer is fine. If there is general interest, I can make finishing this a higher priority. Wouldn't hurt to run the idea past forrestv, given p2pool will be affected as it'd need to adopt the standard. He's run into some oddness with mining hardware and nonces that would be good to understand. (note how p2pool blocks don't commit to a fully random hash - there's some extra bytes in there due to stratum or something IIRC) -- 'peter'[:-1]@petertodd.org 000601a5b2f2b4a597851fdf00f6fc3572bbc03f26857c170032 signature.asc Description: Digital signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
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 buried. We also use the term confirmation to refer to the point where a transaction is accepted as paid. IMO, the latter use makes sense, but the former leads to confusion especially in light of scamcoins which abuse this confusion to claim they have faster confirmations, implying that the actual confirmation occurs faster when it really doesn't. 5 blocks deep may not be more clear to laymen, but at least it makes it harder for people to confuse with actual confirmation. I think people are more familiar with check clearance - the payment/check has cleared. If confirmation and n confirmations together are problematic, I'd talk about cleared payments and n confirmations 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 lexicon. I dont think it's helpful for users if we use the word blocks. Without the technical details, I just explain to normal bitcoin users that the Bitcoin network checks and confirms the payment is valid (multiple times). I think we all know the problems with the term address. People naturally compare it to postal addresses, email addresses, etc, which operate fundamentally different. I suggest that we switch to using invoice id to refer to what is now known as addresses, as that seems to get the more natural understanding to people. On the other hand, with the advent of the payment protocol, perhaps address/invoice id use will die out soon? I think key id is a bit alien at user level - it's not something they are used to. 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 when qualified as a foo address and not just an address You could also call it payment id, but I dont think invoice id since no-one pays to an invoice id that's just a reference for a payment, not the destination. People are very familiar with Paypal these days, and are familiar with paypal address or their paypal id so again I think valid contenders are bitcoin address or bitcoin id. Regards, Drak -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
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 lexicon. I dont think it's helpful for users if we use the word blocks. Confirmations in a numeric context isn't correct, though. We're using to it because we've been using Bitcoin so long, but to the average person they would expect it to mean something more than it is. If not referring to blocks, then perhaps witnessed N times? 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 when qualified as a foo address and not just an address You could also call it payment id, but I dont think invoice id since no-one pays to an invoice id that's just a reference for a payment, not the destination. People are very familiar with Paypal these days, and are familiar with paypal address or their paypal id so again I think valid contenders are bitcoin address or bitcoin id. I think you might be demonstrating my point with regard to user confusion here. Bitcoin addresses are *not* like email addresses, paypal ids, etc. Bitcoin addresses aren't the destination - they're point to a destination (an account in a wallet), but they also represent information such as who is paying and what for - in other words, a specific invoice. Luke -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
-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 when qualified as a foo address and not just an address You could also call it payment id, but I dont think invoice id since no-one pays to an invoice id that's just a reference for a payment, not the destination. People are very familiar with Paypal these days, and are familiar with paypal address or their paypal id so again I think valid contenders are bitcoin address or bitcoin id. No, no no. That's precisely the problem! Bitcoin pubkey-hashes are not like email address, physical address, or paypal address. These latter things are fixed pieces of information that stay constant over time. Bitcoin keys, on the other hand, must be one-use-only. We want to break this association, not strengthen it. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShsDqAAoJEAdzVfsmodw4e+UQAJBk3N7y/1ph8k6K/tPn2RB4 t0TiI46j0WuUghnCiDSOhQiL0EnUWUX8tCa6jH/3ASafBLKVey2LA7LeYoFZXpqJ QEk5S7+eroA6uzzhViDTcoJJ7yH+ivd6dioVApirfnHVYiq6TZuTULhN/5zM6g1J WehI9Rg2C7wj+I71yPJDeGAdtyOeX0iKQy3hN+q7+RIgeZC1viwsq81u6dzVjIZM aPIk6S2VYHSUKhd7wSg+AprCV7jwftKhxDrW6R6KmOGYIG+JdqVnaErc5Wm7ujXk Jnoh6UsQrcx9ck8I4sRTcbb5jGme1taN8RDcKifYqzTVQAr/ziVRqYY57fNAJMm2 lJZ0ctVD1+UB96DzQB4wCuWRoFF5+I9kD2hoEAXA4O9tqcou48lTQ25DAnkcusd+ dD0SfcRsgda8XqnWffGPYaW0E0dQuvu6elO+rzSh4DSCMkroKIvUwdak8Ah5M2lC DyE/efwO9csImbTc1QukedkPskbOqPOo36sH5GdmObKKFCpORIzIO0aDQE1NM2Ib rJurpU0iJ8eA+QT9lpyWG+jjahYpqyVhPcpfVsIewKhI0izBa352IYPbpCv/pdfM oMO/tBfIwUW3jjav3zyFE47hAwistqfV4xds93K9rqpOmLtDIhSuzfmbuXwmciCM d7/3rYQ6FxtyNkEUa27L =5MWw -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
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 meaningsand you're using stuff more familiar in popular lexicon.I dont think it's helpful for users if we use the word "blocks". "Confirmations" in a numeric context isn't correct, though. We're using to it because we've been using Bitcoin so long, but to the average person they would expect it to mean something more than it is. If not referring to blocks, then perhaps "witnessed N times"? Why not call it "Clearing" for transactions with 6 confirmations and "Cleared" for = 6?The round ticker should be enough of an indication of the progress.-- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
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 different meanings and you're using stuff more familiar in popular lexicon. I dont think it's helpful for users if we use the word blocks. Confirmations in a numeric context isn't correct, though. We're using to it because we've been using Bitcoin so long, but to the average person they would expect it to mean something more than it is. If not referring to blocks, then perhaps witnessed N times? If you are talking about user interface, I don't think you have to be technically correct. It must make sense to the user. A user cares about his balance, and did a payment go through, and did my payment arrive/clear. The UI is for their benefit. 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 when qualified as a foo address and not just an address You could also call it payment id, but I dont think invoice id since no-one pays to an invoice id that's just a reference for a payment, not the destination. People are very familiar with Paypal these days, and are familiar with paypal address or their paypal id so again I think valid contenders are bitcoin address or bitcoin id. I think you might be demonstrating my point with regard to user confusion here. Bitcoin addresses are *not* like email addresses, paypal ids, etc. Bitcoin addresses aren't the destination - they're point to a destination (an account in a wallet), but they also represent information such as who is paying and what for - in other words, a specific invoice. 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 crap stuff in to be technically correct is just confusing to them. The UI needs to be about the user and fit with his experience of the world. Drak -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
-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 crap stuff in to be technically correct is just confusing to them. The UI needs to be about the user and fit with his experience of the world. It's not about being technically correct. It is about protecting the user from grave breaches of privacy. It is for their own benefit that they should not be reusing addresses, and if they understood why they wouldn't. Unfortunately calling it a bitcoin address and including an address book in the reference client has had the effect of making people think that these objects are like paypal address, or email addresses, but they are not and they should not be treated the same. Mark -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShsr4AAoJEAdzVfsmodw46nIP/AlDcJh2ET9qYT2ZvddciTk3 dtQDArCkwCW3kYbVjIFT8YtNFftEfkq/qBNnILipLJNN49QduAIlt3aetEE6eJBZ oqYOV2R7GW2yhLDv/GrT6GnB1C9nQ4OuKC6RNpXX4bMpZSrbP9yfyyLqecF1tMBV i8De4XLz1uUvZOo/jwHNeYy/BAZktwdk5hWlgG2yKebRbqVX1Xv70Qb1cPpBgCWm uRDL3bqdZuh6i8NNDQpBqMJ/MP4ZWpIgdHkfO6a3QCq3H0JXyug4t5lkNngCrAI3 KGlSOuYK4Fsfw97xQUBFIaSYFOU+yPDRQK4UGcTqWPLt5YHzUxBFNkOXSnVReudq Em/wlbDkPqm7R6by54fVkG85snJrwmTbD7uxGz2fe1LyzB3HhdOTZyZ1KiyDHqGA zDUFxmH0XNhvVcJvcSFlc38A54oOHTJmfJ3rxJU/q0/5N3ZIBdF8fQ4xIvXXDeeA dO+tul5q78tbO6xyTrbsHO8JRYt4Un8Hjc5mkdqp9gzA8beJFm5+jMZlGBfdl5jR lS9sW7QBxr6m+n2PJ97i+1CgoxTfzOh3jyj93G6Hqx3reTfCu5fSWUhwRnFzJXav qqPBP4Cl+6ocK7+4V1lyfAzMqpYx+GCJ1JZhD0hhwrGglgVPfE0bz7BUGea8U3+T 0pCTlkhWzEbzDp7NtFdY =ShxL -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
