On Monday 03 December 2012 11:19:37 Michael Gronager wrote:
The aged coins are simply included in the block mining reward, creating
another incentive for miners. Further, if we include all coins in this
recycle scheme coins will never be lost forever.
Ignoring the cost of storing these
So, if a bitcoin client is getting Invoice messages via email or from
a web server, the version will be specified as part of the MIME type;
for example:
Content-Type: application/x-bitcoin-invoice; version=1
The version= syntax is part of the MIME standard.
I think that's OK. However, you
On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn m...@plan99.net wrote:
The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
not convinced this is the best use of time, but if somebody steps up
to do it, that could also work.
I strongly believe that if community leads with client
Alan's UTxO meta-chain proposal becomes vastly easier to do now that
ultraprune is merged. That would allow the Satoshi client to know it's
wallet balance and operate with a =SPV level of security during the
initial block download, and keep them on the path of becoming a full node.
If users can
...or should we be directing people to a (vetted) list of cloud services -
I think this has a significantly lower entry cost than any client. I know
the mybitcoin debacle has clouded (pun intended) people's views of these
providers, but blockchain.info (for example) really does seem quite well
On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach m...@monetize.io wrote:
Alan's
:(
UTxO meta-chain proposal becomes vastly easier to do now that
ultraprune is merged.
No, not really. Somewhat easier due to some structural changes, but it
still needs to invent and get consensus on a
It sounds to me that you're insisting that you're asking people who
oppose degrading our recommendations to commit to a costly rushed
development timeline. I think this is a false choice.
Hardly. I don't have any particular timeline in mind. But I disagree
we have forever. New ideas have a
On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn m...@plan99.net wrote:
It sounds to me that you're insisting that you're asking people who
oppose degrading our recommendations to commit to a costly rushed
development timeline. I think this is a false choice.
Hardly. I don't have any particular
Jim, perfect idea with some logo indicating wallet compatibility! This
should cover BIP32 + some mnemonic algorithm for easy transferring of
wallets across various clients.
Btw I asked ThomasV for making BIP from his mnemonic algorithm and he
agreed, so I believe some proposal will be here pretty
On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner etothe...@gmail.com wrote:
Greg's point looks like it's veering towards we don't want to grow
the network unless we're going to get more full nodes out of it.
No…
There is no fundamental completion between taking what actions we can
to maximize the
Our divergence is on two points (personal opinions):
(1) I don't think there is any real risk to the centralization of the
network by promoting a SPV (purely-consuming) node to brand-new users.
In my opinion (but I'm not as familiar with the networking as you), as
long as all full nodes are
On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner etothe...@gmail.com wrote:
Our divergence is on two points (personal opinions):
(1) I don't think there is any real risk to the centralization of the
network by promoting a SPV (purely-consuming) node to brand-new users.
In my opinion (but I'm not
I've implemented an alternative to the BIP 32 proposal. I wanted a system
based on a hierarchical string representation (rather than hierarchy of
integers as BIP 32 proposes). For example I name keys like this:
[hd1.7549].store.1. 1D7GM5dkUtxvGeWgn7SYtanBuyj1MD1EZy
[hd1.7549].store.2.
On Tue, Dec 4, 2012 at 10:06 PM, Mike Koss m...@coinlab.com wrote:
I've implemented an alternative to the BIP 32 proposal. I wanted a system
based on a hierarchical string representation (rather than hierarchy of
integers as BIP 32 proposes). For example I name keys like this:
On Tue, Dec 4, 2012 at 9:23 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Dec 4, 2012 at 10:06 PM, Mike Koss m...@coinlab.com wrote:
I've implemented an alternative to the BIP 32 proposal. I wanted a system
based on a hierarchical string representation (rather than hierarchy of
On Tue, Dec 4, 2012 at 10:36 PM, Watson Ladd w...@uchicago.edu wrote:
being able to spend
a coin sent to an address generated by this scheme implies being able
to spend any coin generated
by this scheme.
If you have the the full extended secret there then you can spend
along the chain— but
Gavin's grandma needs to be able to use bitcoin. Here is a real world
sampling of the types of people wanting to use bitcoin but are having some
difficulty which I have collected from Facebook. Should we listen to the
end user? :-P
*what is the intention of Bitcoin? Is it supposed to be -
Jim,
Most of those issues don't have to do with the SPV versus non-SPV problem.
First person doesn't understand what Bitcoin is supposed to do (he's
confusing mining and running a node). An information problem that could be
solved by explaining what is going on.
Another one seems to have a
18 matches
Mail list logo
