On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman jer...@taplink.co wrote:
Might I propose reusable address.
I like this too.
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are
One challenge with reusable addresses is that while they result in a
small constant overhead for full nodes in searching for their own
transactions they create large overheads for SPV nodes.
One way to address this is for the SPV nodes to hand their servers
their blinding private key so that the
On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman jer...@taplink.co wrote:
Choosing how many bits to put in the prefix may be difficult, particularly
if transaction load changes dramatically over time. 0 or 1 bits may be
just fine for a single user running their own node, whereas a central
On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner etothe...@gmail.com wrote:
Then when someone
wants to pay you, you simply give them the multiplier and root key (they
already have the root key, but should verify).
advantages does stealth addresses have over this scheme? You could
On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi na...@shesek.info wrote:
I had an idea for a payment scheme that uses key derivation, but instead of
the payee deriving the addresses, the payer would do it.
It would work like that:
The payee publishes his master public key
The payer generates a
On Thu, Jan 2, 2014 at 9:22 PM, Troy Benjegerdes ho...@hozed.org wrote:
I believe this is self-explainatory:
1) Bitcoin usually runs on port 8333. Why?
2) Bitcoin does not show in up
On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote:
The NSA has the ability, right now to change every download of bitcoin-qt,
on the fly and the only cure is encryption.
Please cut it out with the snake oil pedaling. This is really over the
top. You're invoking the NSA as the threat
On Thu, Dec 19, 2013 at 5:47 PM, Mark Friedenbach m...@monetize.io wrote:
Hello fellow bitcoin developers. Included below is the first draft of
a BIP for a new Merkle-compressed data structure. The need for this
data structure arose out of the misnamed Ultimate blockchain
On Tue, Dec 17, 2013 at 2:41 PM, Troy Benjegerdes ho...@hozed.org wrote:
I want to get some feedback.. I've used distributed version control
systems for a long time, and the most useful feature is to be able
to merge two different forks.
We already automatically merge forks that we become
On Mon, Dec 9, 2013 at 7:19 AM, Drak d...@zikula.org wrote:
Why would it be made available for download at sourceforge.net if it's not
actually released? The files are available here:
Because it takes time to put the files up, propagate to mirrors, check
by multiple people that the downloads
On Sun, Dec 8, 2013 at 11:16 AM, Drak d...@zikula.org wrote:
BGP redirection is a reality and can be exploited without much
You're managing to argue against SSL. Because it actually provides
basically protection against an attacker who can actively intercept
traffic to the server. Against that
On Sun, Dec 8, 2013 at 12:40 PM, Drak d...@zikula.org wrote:
Let me clarify. SSL renders BGP redirection useless because the browser
holds the signatures of CA's it trusts: an attacker cannot spoof a
certificate because it needs to be signed by a trusted CA: that's the point
of SSL, it
On Fri, Nov 22, 2013 at 12:49 PM, Jeff Garzik jgar...@bitpay.com wrote:
Whitelist nodes against banning.
Is there a reason not to have a parallel get rpc to get the current list?
Shape the Mobile Experience: Free
On Tue, Nov 19, 2013 at 8:53 AM, Drak d...@zikula.org wrote:
It's quite normal for standards bodies to allocate numbers when in draft
status. If they don't pass, they don't pass - they are clearly labelled
+1 on having things in a github repository. Much better for collaboration,
On Tue, Nov 19, 2013 at 9:45 AM, Wladimir laa...@gmail.com wrote:
Talking about complete, BIP 40 and 41 don't even have an associated
I agree that was over-eager number assigning.
Maybe! The subject matter its assigned for is already _widely_
On Fri, Nov 8, 2013 at 11:49 AM, Andreas M. Antonopoulos
Nicholas Weaver is reporting that pools have already started delaying
blocks, something that hints at Selfish Mining, since Nov. 3rd.
On Tue, Nov 5, 2013 at 2:15 PM, Drak d...@zikula.org wrote:
If I understand the issue properly, this seems like a pretty elegant
solution: if two blocks are broadcast within a certain period of eachother,
chose the lower target. That's a provable fair way of randomly choosing the
On Mon, Nov 4, 2013 at 3:58 AM, Michael Gronager grona...@ceptacle.com wrote:
The suggested change is actually very simple (minutes of coding) and
elegant and addresses precisely the identified problem. It is actually a
mental shortcut in the assumption of how probability works when mining a
On Mon, Nov 4, 2013 at 8:39 PM, Peter Todd p...@petertodd.org wrote:
I suggested the mechanism myself for slightly different reasons, and if
you know me, you'd know I'm the first to jump on anyone pushing
Likewise, I did too and am also not very tolerant with trusted or
On Sun, Oct 27, 2013 at 7:32 AM, Mike Hearn m...@plan99.net wrote:
I'm really looking forward to this. Currently bitcoinj gets a small but
steady stream of bug reports of the form my transaction did not propagate.
It's flaky because the library picks one peer to send the transaction to,
On Mon, Oct 28, 2013 at 2:26 AM, Andreas Schildbach
HTTP also defines success codes (2xx). Are we also talking about ACK
messages now, rather than just REJECT messages?
I do not believe we should do that: It would be a non-trivial
increase the protocol bandwidth
On Fri, Oct 25, 2013 at 11:50 AM, Mike Caldwell
I have noticed that there was a recent change to BIP 0038
(Password-Protected Private Key) on the Wiki, which is a proposal I wrote in
late 2012. Gregory, it looks to me as though you have made this change, and
One limitation of the payment protocol as speced is that there is no
way for a hidden service site to make use of its full authentication
capability because they are unable to get SSL certificates issued to
A tor hidden service (onion site) is controlled by an RSA key.
It would be trivial
On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr l...@dashjr.org wrote:
Is there any point to additional encryption over tor (which afaik is already
encrypted end-to-end)? Is there a safe way to make this work through tor entry
The x.509 in the payment protocol itself is for
On Mon, Oct 21, 2013 at 11:59 PM, Jean-Paul Kogelman
Have you seen: https://en.bitcoin.it/wiki/Protocol_specification ?
Take care, the information in the wiki is woefully incomplete.
On Tue, Oct 22, 2013 at 12:34 AM, Martin Sustrik sust...@250bpm.com wrote:
There's also Security Considerations part in
every RFC that is pretty relevant for Bitcoin.
Which would say something interesting like If the bitcoin network
implements inconsistent behavior in the consensus critical
On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr l...@dashjr.org wrote:
See BIP 1 for the process.. proposals go to this mailing list first.
FWIW, he did post to the mailing list and he got an underwhelming response:
On Tue, Sep 17, 2013 at 4:00 AM, Mike Hearn m...@plan99.net wrote:
LevelDB is fast - very fast if you give it enough CPU time and disk seeks.
But it's not the last word in performance.
I'd looked at the hyperleveldb, but their performance graphs made it
seem like it would be slower for the
On Tue, Sep 10, 2013 at 2:03 PM, Matthew Mitchell
Well let's hope something like murder black people, stupid asian person
or whip african slave doesn't come up. :-) Maybe it would have been better
without the aggressive words?
This sounds like
Please return your seats and fasten your seat-belts.
All Bitcoin-qt / Bitcoind nodes will currently fail to come back up
after a restart, reporting
: *** coin database inconsistencies found
Do you want to rebuild the block database now?
Reindexing _will not_ correct the problem. In
On Mon, Sep 9, 2013 at 1:53 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
More information will be forthcoming once a patch is available.
I now have a patch up for review.
(You should wait until other developers have had a chance to review
On Thu, Aug 22, 2013 at 11:26 PM, Maciej Trebacz mac...@bitalo.com wrote:
So if you have multiple addresses you can't
sign them with a single private key and include that signature in the
transaction so other party can verify it against your public key. This could
become very handy though - a
On Thu, Aug 15, 2013 at 7:26 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
I am wondering if we shouldn't have a BIP32 addendum which makes the
following signing related recommendations:
Looks like we're in the midst of another DSA duplicated K disaster.
(Now, blockchain.info mywallet)
I've posted a somewhat blue-skies idea on troll^wBitcointalk that some
here might find interesting:
Get 100% visibility into Java/.NET code with AppDynamics Lite!
On Mon, Aug 19, 2013 at 1:09 PM, Frank F frank...@gmail.com wrote:
If there are technical problems with getwork, maybe they should be addressed
and fixed instead of outright abandoned.
They have been, resulting in a replacement called getblocktemplate
which (presumably) almost everyone talking
On Fri, Aug 16, 2013 at 6:41 AM, Warren Togami Jr. wtog...@gmail.com wrote:
If you disallow the same IP and/or subnet from establishing too many TCP
connections with your node,
has almost zero drawbacks,
There are whole countries who access the internet from single IP
I am wondering if we shouldn't have a BIP32 addendum which makes the
following signing related recommendations:
(1) Recommend a specific deterministic DSA derandomization procedure
(a deterministic way to generate the DSA nonce), presumably one based
on HMAC-SHA512 (since BIP32 uses that
On Sun, Aug 4, 2013 at 8:30 PM, Peter Vessenes pe...@coinlab.com wrote:
I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He
told me recently NTRU, which is lattice based, is one of the few (only?)
NIST-recommended QC-resistant algorithms.
Lamport signatures (and merkle
On Mon, Jul 29, 2013 at 10:01 PM, Randolph D. rdohm...@gmail.com wrote:
Secure P2P Email from Friend to Friend without relying on a central server.
Key- / Repleo-Exchange.
Full decentral Email-Network using the Echo Protocol.
Store Email for Offline-Friends in the P2P Network.
On Tue, Jul 23, 2013 at 1:01 PM, Mike Hearn m...@plan99.net wrote:
Some of us have put together an open letter to the Linux packaging
community, outlining why Bitcoin is different to other programs and asking
them to not patch or modify the upstream sources.
Please consider signing it
On Tue, Jul 23, 2013 at 4:23 PM, Greg Troxel g...@work.lexort.com wrote:
Is the repeatable build infrastructure portable (to any reasonable
mostly-POSIX-compliant system, with gcc or clang)? I have the vague
It's portable to anything that can run the relevant VMs. Uh
provided you don't mind
On Tue, Jul 23, 2013 at 7:35 PM, zooko zo...@zooko.com wrote:
I think some
package maintainers might perceive this version of the letter as high-handed
telling someone else how to do their job -- and they might not notice the
actual facts included in the letter explaining why Bitcoin
On Tue, Jul 23, 2013 at 8:54 PM, Wendell w...@grabhive.com wrote:
Forking for curiosity's sake:
Is there a substantial barrier to endian independence in the Bitcoin codebase?
Not really. The software was originally written to write out memory
order to and from the wire, which is part of why the
On Tue, Jul 23, 2013 at 9:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
order to and from the wire, which is part of why the protocol is LE
*before someone corrects me, it's not LE everywhere (I meant
manywhere :P)— there is just enough BE to keep you on your toes. :P
On Fri, Jul 12, 2013 at 7:28 AM, Rob Meijer rmei...@xs4all.nl wrote:
Completed the first draft of my slides+speaker-notes for my upcoming
Defeating Trojans talk at the OHM2013. BitCoin is one of the main
examples I use in this talk to emphasize the need for programs like
BitCoin to have
On Thu, Jun 27, 2013 at 3:23 AM, Arthur Gervais
-BEGIN PGP SIGNED MESSAGE-
Dear Bitcoin developers,
We would like to report a vulnerability which might lead, under some
assumptions, to a double-spending attack in a fast payment scenario.
On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@fastmail.co.uk wrote:
Let me know if you think this is a good idea (or not!)
and if you have any questions.
Being able to promote a fast SPV desktop wallet would be great!
I went through an cycle of testing on multibit after I saw some
On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote:
On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
* Very real possibility of an overall net reduction of full nodes on P2P
Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or
On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus rob...@robbak.com wrote:
So the decision has been made to make 0-conf double spends trivial, so no
one will ever trust 0-confs. If a later transaction appears with a
On Wed, May 15, 2013 at 6:24 PM, Gavin gavinandre...@gmail.com wrote:
Busy with pre-conference stuff, not following details of this conversation...
... but it sounds a lot like the guy fawkes protocol Zooko was thinking
about a year or so ago.
Sort of, but in a guy fawkes signature you use
On Wed, May 15, 2013 at 7:22 PM, Mike Hearn m...@plan99.net wrote:
Conceptually it sounds a lot like ZeroCoin (not in implementation)?
Zerocoin conceals the connection from everyone forever, assuming the
underlying trapdoor problem is computational infeasible, but at great
On Mon, May 6, 2013 at 10:19 AM, Peter Todd p...@petertodd.org wrote:
running hash of all messages sent on a connection so far. Add a new
protocol message that asks the node to sign the current accumulated
We already depend on OpenSSL, why not just use standard SSL?
SSL doesn't actually
On Mon, May 6, 2013 at 10:53 AM, Peter Todd p...@petertodd.org wrote:
We don't have non-repudiation now, why make that a requirement for the
first version? Adding non-repudiation is something that has to happen at
the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure
On Mon, May 6, 2013 at 3:51 PM, Adam Back a...@cypherspace.org wrote:
Maybe I could hack a pool to co-opt it into my netsplit and do the work for
me, or segment enough of the network to have some miners in it, and they do
Or you can just let it mine honestly and take the Bitcoins.
On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn m...@plan99.net wrote:
I'd imagined that nodes would be able to pick their own ranges to keep
rather than have fixed chosen intervals. Everything or two weeks is rather
X most recent is special for two reasons: It meshes well with actual demand,
On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
Have we considered just leaving that problem to a different protocol such as
BitTorrent? Offering up a few GB of storage capacity is a nice idea but it
means we would soon have to add structure to the network to
On Sat, Apr 13, 2013 at 2:43 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
Actual network rules will need to come later. However, even just not
accepting them into memory pools will it make very hard (if not impossible)
for the buggy clients that create transactions to get any confirmations.
On Tue, Apr 9, 2013 at 11:53 PM, Peter Todd p...@petertodd.org wrote:
Of course, either way you have the odd side-effect that it's now
difficult to pay further funds to a random txout seen on the
blockchain... strange, although possibly not a bad thing.
Oh wow, thats actually a quite good
On Tue, Apr 9, 2013 at 7:39 AM, Caleb James DeLisle
what anti-virus software might do when certain streams of bytes are sent
the tcp socket or persisted to disk. Perhaps worth contacting an AV company
asking what is the smallest data they have a
(1) Define a new address type, P2SH^2 like P2SH but is instead
H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is
a hash of a P2SH address.
(2) Make a relay rule so that to relay a P2SH^2 you must include
along the inner P2SH address. All nodes can trivially verify it by
On Tue, Apr 9, 2013 at 8:52 PM, Robert Backhaus rob...@robbak.com wrote:
That sounds workable. I take it that the P2SH address is not stored? I like
it that this denies the possibility of storing data in the block chain, but
does not block interesting uses like creating date stamps - You can
On Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho
There was some chat on IRC about a mining pool reaching 46%
The estimates on there may be a bit lossy.
What's the risk of a 51% attack.
The whole fixation on 51 as a magic number is a
On Fri, Apr 5, 2013 at 2:48 AM, Mike Hearn m...@plan99.net wrote:
but I think p2pool still has a lot of problems dealing with
FPGA/ASIC hardware and it hasn't been growing for a long time.
As an aside and a clarification— P2pool works great with FPGAs, and
one of the largest FPGA farms I've
On Fri, Apr 5, 2013 at 10:24 AM, Adam Ritter arit...@gmail.com wrote:
I just bought some BitCoins after being lazy to do it for the last few
years, but also looked at the client code and the messages that are
going on this mailing list.
I saw that there are quite some unit tests,
On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami r...@gnomon.org.uk wrote:
I'm not envisaging something as drastic as changing the rules to make
transactions to revoked addresses invalid - just an overlay protocol.
Although to be useful such a protocol would have to be pretty much
On Sat, Mar 23, 2013 at 10:47 AM, Jeff Garzik jgar...@exmulti.com wrote:
On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr l...@dashjr.org wrote:
Not for producing coinbases (where BIP 34 is implemented).
Sure, that is largely the pool server layer. But it is misleading to
imply that bitcoind is
On Sat, Mar 23, 2013 at 5:57 PM, Jay F j...@outlook.com wrote:
My first concern was that I and about everyone else only has TCP/UDP
You tunnel it!
You could do worse to have a data stream that looks like WEBRTC
On Fri, Mar 15, 2013 at 10:06 AM, Benjamin Lindner b...@benlabs.net wrote:
This. Software behavior which is not described by the source code should not
be considered an integral part of the rule set.
Any influence of external libraries on the consensus mechanism is
On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote:
If we're going to consider doing this, at minimum we need to also
I beg people to not derail discussion about fixing things with
discussion of other controversial changes.
Luke-jr, any chance in getting you to revise your
On Wed, Mar 13, 2013 at 1:10 PM, Matthew Mitchell
Why would it be a difficulty in getting people to update away from 0.7 and
earlier? How long would that roughly take? If people are hesitant to update,
imagine if a more serious vulnerability is
On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins andypark...@gmail.com wrote:
On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
Here's a simple proposal to start discussion from...
It seems to me that the biggest failure was not the development of two
chains, but the assurance to users (by the
On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami r...@gnomon.org.uk wrote:
The idea of the client detecting/warning about not-trivial forking
seems worthwhile too, though, assuming it doesn't already (AIUI it
It does warn— if its heard the fork and its on the lower difficulty
On Tue, Mar 12, 2013 at 2:10 AM, Mike Hearn m...@plan99.net wrote:
BDB ran out of locks.
However, only on some 0.7 nodes. Others, perhaps nodes using different
flags, managed it.
We have processed 1mb sized blocks on the testnet.
Therefore it isn't presently clear why that particular block
On Tue, Mar 12, 2013 at 2:47 AM, Peter Todd p...@petertodd.org wrote:
Followed by the actual replacement logic. We could change this logic to
instead evaluate if the candidate replacement does not remove or
decrease the value of any existing outputs. Adding outputs is ok.
Changing the set of
On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner etothe...@gmail.com wrote:
I don't want to misrepresent what happened, but how much of that was really
a risk? The block was rejected, but the transactions were not.
Some but not much. If someone flooded a bunch of duplicate
On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes pe...@coinlab.com wrote:
Can some enterprising soul determine if there were any double-spend attempts?
I'm assuming no, and if that's the case, we should talk about
On Mon, Mar 11, 2013 at 1:36 PM, Michael Gronager grona...@ceptacle.com wrote:
The point with UTXO is in the long run to be able to switch from a p2p
network where everyone stores, validates and verifies everything to a DHT
where the load of storing, validating and verifying can be shared.
On Sun, Mar 3, 2013 at 10:54 AM, Roy Badami r...@gnomon.org.uk wrote:
Would be nice to have a secure page at bitcoin.org, though, rathar
than having to go to github - certs from somewhere like Namecheap
should cost you next to nothing. For those of us too lazy (not
paranoid enough) to bother
On Wed, Feb 13, 2013 at 6:58 AM, Raph Frank raph...@gmail.com wrote:
Bitcoin is not a democracy— it quite intentionally uses the consensus
mechanism _only_ the one thing that nodes can not autonomously and
interdependently validate (the ordering of transactions).
So, how is max block size to
On Wed, Feb 13, 2013 at 3:10 PM, Stephen Pair step...@bitpay.com wrote:
If you've already validated the majority of transactions in a block, isn't
validating the block not all that compute intensive? Thus, it's really not
blocks that should be used to impose any sort of scarcity, but rather
On Wed, Feb 13, 2013 at 7:42 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
I hope that should it become necessary to do so that correct path will
be obvious to everyone, otherwise there is a grave risk of undermining
the justification for the confidence in the immutability of any of the
On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair step...@bitpay.com wrote:
One of the beauties of bitcoin is that the miners have a very strong
incentive to distribute as widely and as quickly as possible the blocks they
find...they also have a very strong incentive to hear about the blocks that
On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank raph...@gmail.com wrote:
Has this been considered?
If made sufficiently general, older clients could support any
extension of the rules.
Various hard parameters within the protocol are defined in main.h of
the official client.
In BIP-34, there
On Mon, Feb 11, 2013 at 11:12 AM, Timo Hanke timo.ha...@web.de wrote:
It's not about technical differences, but about the different use or
purpose, which can result in different security demands. I argue that
DNS has a lower demand in this respect than payment ids have. So DNS
data can be in a
On Wed, Feb 6, 2013 at 8:33 AM, Mike Hearn m...@plan99.net wrote:
Can somebody please unlock the BIP wiki page? I don't know why it was locked
but it's stale.
I asked for permissions to unlock it but haven't heard back— will prod.
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
On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach m...@monetize.io wrote:
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
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
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.
There is no fundamental completion between taking what actions we can
to maximize the
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
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 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
On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager grona...@ceptacle.com wrote:
Bitcoin aka the blockchain is defined by the majority of the miners. This is
what people have signed up to imo. A scheme that a) is of benefit for us all
and b) is also of economical benefit for the miners, will
On Mon, Dec 3, 2012 at 10:00 AM, Mike Hearn m...@plan99.net wrote:
The main source for these 1 Satoshi payouts is Sahtoshi Dice.
Because people are making 1 satoshi bets, or is this part of their
It's part of their messaging system. Every losing play results in a
On Mon, Dec 3, 2012 at 2:50 PM, Andreas Petersson andr...@petersson.at wrote:
These discussed features are all useful but quite contradicting.
I imagine that a user will be able to switch between different coin
selection policies minimize fees,max privacy,defragmentation,i
don't care and even
On Thu, Nov 29, 2012 at 12:31 PM, Mike Hearn m...@plan99.net wrote:
4) A longer term reason - in time, people may choose to not broadcast
transactions at all in some cases. I think how network speed will be
funded post-inflation is still an open question. Assuming the simplest
On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr l...@dashjr.org wrote:
On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote:
They could be included as well of course, but from a seller
perspective the most important thing is consistency. You have to be
able to predict what CAs the user has,
On Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish wal...@stani.sh wrote:
I see that draft-stanish-x-iso4217-a3 is not standards track, is there
a reason for this?
It also doesn't appear to address ~any of the the targeted items here.
Is there another draft I should be looking for
On Sat, Oct 6, 2012 at 12:37 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
I'm concerned about how the particular security model of electrum is
being described; or rather— not being described.
Just to close the loop on this: I finally got in touch with Thomas on
IRC and walked over the security
On Fri, Oct 26, 2012 at 10:01 AM, Mike Hearn m...@plan99.net wrote:
If you just want to waste bandwidth of nodes you can connect to nodes
and repeatedly download blocks, or fill the network with fake nodes
that spam random generated transactions to whoever connects. I don't
see how to avoid
201 - 300 of 358 matches
Mail list logo