On Mon, May 6, 2013 at 11:04 AM, Adam Back wrote:
> bitcoins primary
> vulnerability IMO (so far) is network attacks to induce network splits,
> local lower difficulty to a point that a local and artificially isolated
> area of the network can be fooled into accepting an orphan branch as the
> one
On Mon, May 6, 2013 at 10:53 AM, Peter Todd 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
> you're connection i
On Mon, May 6, 2013 at 10:19 AM, Peter Todd 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 provide non
On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
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 allow nodes to
> find
> eac
On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn 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 the data is
On Wed, Apr 24, 2013 at 7:51 AM, Gavin Andresen wrote:
>> Ian pointed out some errors in the BIP21 spec. What's the process for
>> amending the BIP? Do we need to create a new one and mark the old one as
>> replaced, or can we just fix it in place given the relatively exotic nature
>> of most of t
On Sat, Apr 13, 2013 at 2:43 PM, Pieter Wuille 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. I'm
> not sure... 0.
On Tue, Apr 9, 2013 at 11:53 PM, Peter Todd 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 thing— it's a proper
On Tue, Apr 9, 2013 at 8:52 PM, Robert Backhaus 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 still
> store the
(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
hashi
On Tue, Apr 9, 2013 at 7:39 AM, Caleb James DeLisle
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 signature on.
I stuff
On Fri, Apr 5, 2013 at 10:24 AM, Adam Ritter 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, but I didn't
On Fri, Apr 5, 2013 at 2:48 AM, Mike Hearn 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 heard of uses it.
On Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho
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 bit confused— I'll
On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami 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 implemented by clien
On Sat, Mar 23, 2013 at 5:57 PM, Jay F 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 traffic…
In so
On Sat, Mar 23, 2013 at 10:47 AM, Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr 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 nowhere in the stack.
You're both
On Fri, Mar 15, 2013 at 10:06 AM, Benjamin Lindner 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 thinks its contro
On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami 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. Extending that to also
On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins 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 client) that their
On Wed, Mar 13, 2013 at 1:10 PM, Matthew Mitchell
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 found. It could be disastrous.
The de
On Wed, Mar 13, 2013 at 11:27 AM, Mark Friedenbach wrote:
> This may be a semantic issue. I meant that it's not a hard-fork of the
> bitcoin protocol, which I'm taking to mean the way in which we all
> *expected* every version of the Satoshi client to behave: the rules which we
In our common lang
On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd 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 proposal to narrow
th
On Wed, Mar 13, 2013 at 5:56 AM, Luke-Jr wrote:
> FROM block 262144 to block 393216 (hard fork #1):
> - Never make, and reject any block that includes more than 24391 transaction
> modifications on its own (this *should* be equivalent to 1 MB)
> - (this rules can make older client backports safe u
On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell wrote:
> On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes 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 that publ
On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner 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 both spends to as
On Tue, Mar 12, 2013 at 2:47 AM, Peter Todd 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 inputs is also o
On Tue, Mar 12, 2013 at 2:10 AM, Mike Hearn 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 caused
> lock
On Mon, Mar 11, 2013 at 1:36 PM, Michael Gronager 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 believe you are co
On Mon, Mar 11, 2013 at 1:34 PM, Rune Kjær Svendsen wrote:
> The question is if we should define a new value, that we use solely to
> display in this text, or if we should use MIN_TX_FEE or MIN_RELAY_TX_FEE in
> some way. What are the dev's thoughts?
It should be a new value.
---
On Sun, Mar 3, 2013 at 10:54 AM, Roy Badami 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 with GPG, a (se
On Sat, Feb 23, 2013 at 5:06 PM, Peter Todd wrote:
> In the low-subsidy future fees will be the main source of income for
> miners. Thus in some circumstances large miners may even have a reason
> to delibrately try to mine a block that would orphan the current best
> block. A simple example would
On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair 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
> others find.
On Wed, Feb 13, 2013 at 7:42 AM, Gregory Maxwell 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 o
On Wed, Feb 13, 2013 at 3:10 PM, Stephen Pair 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 it's
> the cost
On Wed, Feb 13, 2013 at 1:02 PM, Gavin Andresen wrote:
> On Wed, Feb 13, 2013 at 10:42 AM, Gregory Maxwell
> wrote:
>> Since, in the long run,
>> Bitcoin can't meet its security and decenteralization promises without
>> blockspace scarcity to drive non-trivial fees
On Wed, Feb 13, 2013 at 6:58 AM, Raph Frank 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 be decided t
On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank 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 is a sug
On Mon, Feb 11, 2013 at 11:12 AM, Timo Hanke 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 chain with a
On Wed, Feb 6, 2013 at 8:33 AM, Mike Hearn 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 Sat, Dec 22, 2012 at 1:39 PM, Andreas Schildbach
wrote:
> Both blocks
>
> 38304 015bb4069249fa1f41ae61d8a7447aaacc33c50dacd3c3654377fa43
>
> and
>
> 40320 8011f56b8c92ff27fb502df5723171c5374673670ef0eee3696aee6d
>
> are difficulty transition blocks. However, block 40320 has a di
On Fri, Dec 21, 2012 at 3:53 AM, Eric Lombrozo wrote:
> I started working on a new feature to allow for watch-only addresses in
> wallets. https://github.com/bitcoin/bitcoin/pull/2121
>
> In order to integrate this feature nicely into bitcoin / bitcoin, it will be
> necessary to disable signing an
On Tue, Dec 4, 2012 at 10:36 PM, Watson Ladd 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 just the plain e
On Tue, Dec 4, 2012 at 10:06 PM, Mike Koss 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:
>
> [hd1.7549].store.1. 1
On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner 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 as familiar with
On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner 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 decentralization
On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn 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 timeline in
On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach 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 normative data structu
On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn 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 software which
On Thu, Nov 29, 2012 at 12:31 PM, Mike Hearn 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 where users pay
On Mon, Dec 3, 2012 at 2:50 PM, Andreas Petersson 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 switch
On Mon, Dec 3, 2012 at 10:17 AM, Alan Reiner wrote:
> Perhaps it could be improved by cleaning up dust from any address by default
> (not just ones already included in the tx), with the option for the user to
> disable that behavior. After all, anonymity was never a core feature of the
> network
On Mon, Dec 3, 2012 at 10:00 AM, Mike Hearn 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 output being
On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager 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 likely be accepted
>
On Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish 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 which has more ove
On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr wrote:
> On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
>> Obviously the state of the world with browsers is not that good... but
>> in our own UAs we can do better and get closer to that.
>
> This effectively centrali
On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr 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, otherwise you
On Sat, Oct 6, 2012 at 12:37 PM, Gregory Maxwell 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 securi
On Thu, Nov 8, 2012 at 4:19 AM, Mike Hearn wrote:
> Is it time to feature-freeze 0.8
>
> I'd like more time to get the bloom filtering work in. It'll be easier to
> promote the 0.8 release if we can sell it as "important
> scalability/performance improvement for the network, upgrade to help Bi
On Fri, Oct 26, 2012 at 10:21 AM, Mike Hearn 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 concern. Altco
On Fri, Oct 26, 2012 at 10:01 AM, Mike Hearn 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 that so it se
On Thu, Oct 25, 2012 at 12:56 PM, Gregory Maxwell wrote:
> I still don't understand what purpose the apparently gratuitous
> inefficiency of constantly resending common tree fragments.
Sorry for the rapid additional comment, but I should also have
mentioned that the in efficiency is a
On Wed, Oct 24, 2012 at 11:56 AM, Mike Hearn wrote:
> I've written a draft BIP describing the bloom filtering protocol
> extension developed by myself and Matt.
>
> https://en.bitcoin.it/wiki/BIP_0037
Thanks for taking the time to write this up.
I still don't understand what purpose the apparent
On Sat, Oct 20, 2012 at 1:55 PM, Pieter Wuille wrote:
> What do you think about these rules? If people want these rules,
> nothing would happen for now - just start try to find software that
> doesn't produce complying data. In a second step, these could be
> enabled as check similar to IsStandard
On Sun, Oct 14, 2012 at 6:09 PM, Christian Decker
wrote:
> Being an international team I'm pretty sure we can find someone who is in a
> more permissive country.
> Would someone knowledgeable point us to the specific laws, so that we can
> look it up in our respective jurisdiction?
The only restr
On Wed, Oct 10, 2012 at 7:19 AM, Mike Hearn wrote:
> +gary
>
>> Electrum also has a daemon for merchants.
>
> Well, I suggest taking it up with Thomas directly. A thread here won't do
> much.
I tried in IRC and got no response. These messages are copying the
only contact email address I could fi
On Tue, Oct 9, 2012 at 7:12 PM, Jeff Garzik wrote:
> * Data-driven tests: If possible, write software-neutral, data-driven
> tests. This enables clients other than the reference one (Satoshi
> client) to be tested. Embed tests in testnet3 chain, if possible.
The mention of testnet3 here reminds
On Tue, Oct 2, 2012 at 6:44 PM, Mike Hearn wrote:
> A simple way to solve this problem is just use the SSL identity of the
> server that is taking part in the protocol, but it's not much harder
SSL itself (as opposed to using the certs as you suggest) is not
non-reputablable, so it's not enough f
On Wed, Sep 26, 2012 at 8:53 PM, Matt Corallo wrote:
> Jenkins currently just runs the test script after each new commit to
> bitcoin (and provides binaries to anyone who wants them), so its pretty
> basic (though jenkins has way more features than we use). The bitcoin
> one lives at http://jenki
ns right now?
This is discussion about transactions which are not in the chain yet.
> On 9/23/12, Gregory Maxwell 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
>>
On Sun, Sep 23, 2012 at 4:30 PM, Jeff Garzik 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 size
aren't terribly
On Thu, Sep 13, 2012 at 10:05 AM, Matthew Mitchell
wrote:
> @Gregory
>
>> But you only need to request the transactions you don't have. Most of
>> time you should already have almost all of the transactions.
>
> Yes, my proposal allows you to do this. You skip out transactions your
> already hav
On Tue, Sep 11, 2012 at 5:48 PM, Matthew Mitchell
wrote:
> You wouldn't need to pipeline the requests, just place more than one
> inventory vector in get data, right? Well my messages would save the space of
> those inventory vectors. Instead of needing 36 byte inventory vectors for
> each tran
On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell
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 download the transactions s
On Mon, Sep 10, 2012 at 3:53 PM, Matt Corallo wrote:
> It seems to me the whole idea of segmenting blocks would add very little
> (to nothing) with any sane block size. Sure, if a block were to be
> 10GB, it may make sense. However, even in that case, it would be easier
As you know there is a h
On Mon, Sep 10, 2012 at 11:07 AM, Matthew Mitchell
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.
>
> https://en.bitcoin.it/wiki/
On Mon, Aug 13, 2012 at 10:24 AM, Jeff Garzik 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/"
>
> Therefore
On Mon, Jul 30, 2012 at 4:26 PM, Amir Taaki 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 this list:
http:
On Fri, Jul 27, 2012 at 1:59 AM, grarpamp 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 the chain, b
On Fri, Jul 27, 2012 at 12:20 AM, grarpamp 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 being accessed
On Thu, Jul 26, 2012 at 7:27 AM, Mike Hearn wrote:
>> OP_CODESEPARATOR 14
>> OP_DEPTH 182
>
> I'm interested to see what scripts were using OP_DEPTH and
> OP_CODESEPARATOR, as the latter appears to be useless to my eyes.
>
> Could you give some tx ids which use unusual opcodes?
The OP_DEPTH are a
On Sun, Jul 22, 2012 at 6:37 PM, grarpamp 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 takes
something lik
On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner wrote:
> What a feature matrix is good at though is it allows you to very quickly
> find the specific feature or general criteria you're looking for without
> reading through all of the text. So it might be a useful addition maybe
> not on Bitcoin.org,
On Mon, Jul 9, 2012 at 2:54 PM, Jim wrote:
> RE: The position randomisation - I have to admit I was secretly pleased
> with the original layout, as MultiBit just happened to have the "eye
> candy" position of "top and centre". It is only fair to have them
> switch around.
This ordering wasn't ac
On Mon, Jul 9, 2012 at 2:18 PM, Amir Taaki wrote:
> The only thing that's changed between now and this morning is:
>
> - Addition of Bitcoin Wallet for Android
> - Randomisation of entries
Yes, because I reverted eight commits to it by you because they were
clearly controversial, including the pr
On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki 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 randomization if y
On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki wrote:
> Took me a while, but finally got it working.
> Entries on the clients page are randomly ordered when the page is generated.
> https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
> We should regenerate the page
On Mon, Jul 9, 2012 at 10:00 AM, Gregory Maxwell 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 section
On Mon, Jul 9, 2012 at 5:21 AM, Amir Taaki wrote:
> Hey,
>
> I just saw this added to the clients page. One of the conditions we set for
> that page was that all the clients must have the entire sourcecode available
> for review, and users should be able to run it from the sourcecode. Is the
>
On Mon, Jul 9, 2012 at 7:34 AM, Jorge Timón 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?
> I would say it's
On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen wrote:
>> But those issues are solvable through other, non-backwards incompatible
>> means. For example, mandate that a refers
>> to the first such pair that is not already spent. No?
>
> Yes, that is essentially what BIP 30 did.
It's important to n
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] https://people.xi
On Tue, Jun 26, 2012 at 7:01 PM, grarpamp 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 overlay networks th
On Sun, Jun 24, 2012 at 8:45 AM, Mike Hearn 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 list (see the re
On Thu, Jun 21, 2012 at 5:42 PM, Mike Koss wrote:
> Are we just talking about pruning the spent transactions from an old block?
No.
We're talking about commitments to the state of _unspent_ transactions
which would allow ~memoryless nodes to engage in full validation
without having to trust anyt
On Tue, Jun 19, 2012 at 1:33 PM, Alan Reiner 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 be a disaster to
Right now we're seeing cases where block propagation is sometimes
taking minutes.
This doesn't cause much of a problem for general Bitcoin users but for
miners its problematic because it potentially increases the risk for
orphaning.
There are probably many contributing factors which can be improve
On Sun, Jun 17, 2012 at 7:04 PM, grarpamp wrote:
> Presumably the github/0.6.2 branch is safe for production?
0.6.2 is very widely used, more so than the other acceptably updated backports.
> What degree of caution about wallet eating should be
> made for those using github/master?
I can't spea
On Sun, Jun 17, 2012 at 5:35 PM, grarpamp wrote:
>> It isn't inside the ifdef in bitcoin git master.
>
> Oh, hmm, well then, what is the difference or usage
> between these two repositories in regards to the project?
> Which one are the formal releases tagged (tbz's cut) in?
>
> Which one has the
On Sun, Jun 17, 2012 at 5:22 AM, grarpamp wrote:
> Well, detachdb doesn't appear in the -\? help
> because it's stuffed under pnp, which is not set
> in my build. please fix for people, tx :)
It isn't inside the ifdef in bitcoin git master.
(For future reference this sort of request is probably
301 - 400 of 454 matches
Mail list logo
