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
DRAFTs.
+1 on having things in a github repository. Much better for collaboration,
The
On Fri, Nov 8, 2013 at 11:49 AM, Andreas M. Antonopoulos
andr...@rooteleven.com wrote:
Nicholas Weaver is reporting that pools have already started delaying
blocks, something that hints at Selfish Mining, since Nov. 3rd.
https://medium.com/something-like-falling/d321a2ef9317
He dismisses
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
winning block
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
centralization.
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,
and
On Mon, Oct 28, 2013 at 2:26 AM, Andreas Schildbach
andr...@schildbach.de wrote:
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
mcaldw...@swipeclock.com wrote:
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
them.
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
nodes/gateways?
The x.509 in the payment protocol itself is for
On Mon, Oct 21, 2013 at 11:59 PM, Jean-Paul Kogelman
jeanpaulkogel...@me.com wrote:
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
matthewmitch...@godofgod.co.uk wrote:
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?
Ouch.
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
and
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.
https://github.com/bitcoin/bitcoin/pull/2982
(You should wait until other developers have had a chance to review
before
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
I've posted a somewhat blue-skies idea on troll^wBitcointalk that some
here might find interesting:
https://bitcointalk.org/index.php?topic=277389.0
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's
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
addresses. There
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.
Chat and
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 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
everywhere,
*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 Thu, Jun 27, 2013 at 3:23 AM, Arthur Gervais
arthur.gerv...@inf.ethz.ch wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
complaints
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
network
Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or
MultiBit
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
cost.
Adamcoin,
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
hash.
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
the work.
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,
and
On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
john.dillon...@googlemail.com wrote:
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
calebdeli...@lavabit.com wrote:
what anti-virus software might do when certain streams of bytes are sent
across
the tcp socket or persisted to disk. Perhaps worth contacting an AV company
and
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 Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho
melvincarva...@gmail.com wrote:
There was some chat on IRC about a mining pool reaching 46%
http://blockchain.info/pools
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:
Hey guys,
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
universally
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
port forwarding,
You tunnel it!
http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-dtls-encaps-00
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
unacceptable.
No one
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
matthewmitch...@thelibertyportal.com wrote:
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
doesn't).
It does warn— if its heard the fork and its on the lower difficulty
side.
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 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
concurrently announcing
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.
I
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
rules
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 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:
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
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.
No…
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
messaging system?
It's part of their messaging system. Every losing play results in a
new 1e-8
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
arrangement
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:
X-ISO4217-A3
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
On Fri, Oct 26, 2012 at 10:21 AM, Mike Hearn m...@plan99.net wrote:
Anyway, it's trivial to DoS the entire Bitcoin network today. It
hasn't ever happened. Maybe one day it will, but the only rationale
people can come up with for such an attack beyond random griefing is
Which happens and is a
?
This is discussion about transactions which are not in the chain yet.
On 9/23/12, Gregory Maxwell gmaxw...@gmail.com wrote:
There are bursts of weird transactions (e.g. someone was flooding zero
value txn a few weeks ago; before that there were some enormous series
of double-spend induced orphans), and other
On Sun, Sep 23, 2012 at 4:30 PM, Jeff Garzik jgar...@exmulti.com wrote:
Yeah, my public nodes currently have 2200+ Over time, it gets
cluttered naturally due to the disconnect between what miners mine and
what relayers relay.
Right, this disconnect is why simple scalar measures of mempool
On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell
matthewmitch...@godofgod.co.uk wrote:
For some reason sourceforge is not sending me updates anymore but I can see
the replies online…
There could be a slightly more simple protocol which gives all the
transactions hashes and nodes can then
On Mon, Sep 10, 2012 at 11:07 AM, Matthew Mitchell
matthewmitch...@godofgod.co.uk wrote:
Here is a BIP draft for improving the block relaying and validation so that
it can be done in parallel and so that redundancy can be removed. This
becomes more beneficial the larger the block sizes are.
On Mon, Aug 13, 2012 at 10:24 AM, Jeff Garzik jgar...@exmulti.com wrote:
My only response is a weak one: inevitability. It seems likely that
-somebody- will implement their own P2P commands for their own client
subset, even if only a simple use 'getstatus' with strSubVer matching
/FooClient/
On Mon, Jul 30, 2012 at 4:26 PM, Amir Taaki zgen...@yahoo.com wrote:
Hi,
luke-jr wants me to split this BIP into 3 separate BIPs because he says that
other devs felt it was too unfocused and covered too many topics. However
this discussion took place on IRC, a
It actually took place on
On Fri, Jul 27, 2012 at 1:59 AM, grarpamp grarp...@gmail.com wrote:
I now have an 1.8 ghz p3 celeron (128k cache) which should be
substantially slower than your machine, running vintage 2.6.20 linux.
Unfortunately I forgot to turn on timestamp logging so I don't know
how long it took to sync
On Fri, Jul 27, 2012 at 12:20 AM, grarpamp grarp...@gmail.com wrote:
Update: this class of machine just became useless for bitcoin.
When blk0002.dat was created to store more blocks, all forward
progress processing blocks turned into losing ground by 20 or so
a day. Guessing both datfiles were
On Sun, Jul 22, 2012 at 6:37 PM, grarpamp grarp...@gmail.com wrote:
It already takes a month to build a new blockchain, let alone keep up
with new incoming blocks.
Please fix your software stack. Something is wrong with your system
and I doubt it has much to do with bitcoin. A full sync here
On Mon, Jul 9, 2012 at 7:34 AM, Jorge Timón timon.elvi...@gmail.com wrote:
Didn't even know that they were proprietary software bitcoin clients.
Should people trust them? Should the web promote them?
After all, you can't know what they do. What if one of them contains a
back door or something?
On Mon, Jul 9, 2012 at 10:00 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
I've reverted these additions to the page, nothing personal but—
Er, to be clear, I left the android software in because the source is
available (And I'm told its had some review).
I removed the proprietary software
On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki zgen...@yahoo.com wrote:
JS randomisation is bad. People shouldn't need JS to view a webpage.
JS randomization doesn't imply needing JS to view the page. It implies
needing JS to see it in random order. You could also combine it with
the server-side
Pieter's performance numbers are a bit conservative if anything—
profiles on ultraprune[1] show that the reference client's wasting of
a lot of time in redundant serialization and hashing operations is
the major time sink. Once thats cleared up it should be quite a
bit faster
[1]
On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen gavinandre...@gmail.com wrote:
But those issues are solvable through other, non-backwards incompatible
means. For example, mandate that a transaction hash, output index refers
to the first such pair that is not already spent. No?
Yes, that is
On Tue, Jun 26, 2012 at 7:01 PM, grarpamp grarp...@gmail.com wrote:
You are going to want to include the block of the Phatom project as well:
https://code.google.com/p/phantom/
fd00:2522:3493::/48
Perhaps some argument to add blocks to the IsRoutable check is in
order? Then people who use
On Sun, Jun 24, 2012 at 8:45 AM, Mike Hearn m...@plan99.net wrote:
d'aniel made a good proposal - having good nodes broadcast
announcements when they detect a rule that breaks the rules, along
with a proof that it did so. Checking the proof might be very
Link?
I also proposed this on this
On Tue, Jun 19, 2012 at 1:33 PM, Alan Reiner etothe...@gmail.com wrote:
One app developer updates their
RB tree code which updated the RB-tree optimizations/rebalancing, and
now a significant portion of the network can't agree on the correct
root. Not only would that be disruptive, it would
201 - 300 of 322 matches
Mail list logo
