On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote:
I suppose I mean that I don't understand how to reverse that into a URL
when one is presented only with a block, or perhaps a coinbase in a
transaction.
A new message can be added to the p2p relay network, similar to tx and alert
I see. That is undeniably more secure and bitcoin-y than my suggestion.
It's also really a lot more work, especially in that it requires extra
linkages between codebases that in my mind are largely separate.
I'm just one voice, but I persist in believing that the 'lighter' solution,
especially
I disagree with a bunch of your points, but I'll wait on others to comment,
except I will say that I don't understand what the 20 byte keyhash is. Can
you elucidate?
I am assuming major mining folks have written their own coinbasing
facilities, but perhaps this is not the case -- if so, I agree
I'm pleased to announce the release of BitCoinJ 0.5, the library that
powers Android Wallet, SatoshiDice, Bitcoin Status, the server side part of
BCCAPI and much more.
This release focusses on bug fixes, making the build more standard and
completing the transition to the protobuf wallet format.
Devs,
I have decided to upgrade Armory's blockchain utilities, partly out of
necessity due to a poor code decision I made before I even decided I was
making a client. In an effort to avoid such mistakes again, I want to
do it right this time around, and realize that this is a good
(response from Doug forwarded below)
It's a very good point. I have no experience with database engines. I
had assumed that in most cases, data could always be indexed in RAM, and
wanted to know where to go when that's not the case. I will look into
that solution, further.
I am very
Analysis, comments, constructive criticism, etc welcome for the following:
==Background==
At present, an attacker can harm a pool by intentionally NOT submitting shares
that are also valid blocks. All pools are vulnerable to this attack, whether
centralized or decentralized and regardless of
On Sat, Jun 2, 2012 at 7:52 PM, Luke-Jr l...@dashjr.org wrote:
Analysis, comments, constructive criticism, etc welcome for the following:
==Background==
At present, an attacker can harm a pool by intentionally NOT submitting shares
that are also valid blocks. All pools are vulnerable to this
On Sat, Jun 2, 2012 at 8:52 PM, Luke-Jr l...@dashjr.org wrote:
Analysis, comments, constructive criticism, etc welcome for the following:
==Background==
At present, an attacker can harm a pool by intentionally NOT submitting
shares
that are also valid blocks. All pools are vulnerable to
On Monday, June 04, 2012 1:43:42 AM Peter Vessenes wrote:
Does it have asymmetric payoff for an attacker, that is, over time does it
pay them more to spend their hashes attacking than just mining?
That depends on the pool's reward scheme. Some complicated forms are capable
of getting bonus
I don't understand how your proposal will work for decentralized pools -
can you explain it more concretely?
What would the new block header look like?
What is required for a share to to be earned?
What is required for a block to be valid (added to Block Chain)?
I don't think I understand what
- Forwarded message from Pieter Wuille pieter.wui...@gmail.com -
Date: Sun, 10 Jun 2012 01:10:54 +0200
From: Pieter Wuille pieter.wui...@gmail.com
To: bitcoin-development@lists.sourceforge.net
Subject: getmemorypool
User-Agent: Mutt/1.5.20 (2009-06-14)
Hello everyone,
Luke's
On Sun, Jun 10, 2012 at 7:06 PM, Mike Hearn m...@plan99.net wrote:
I remember some people, Greg in particular, who were not a fan of
approach (2) at all, though it has the benefit of speeding startup for
new users as there's no indexing overhead.
I'm not a fan of anything which introduces
I think the sourceforge mailing list system had the hiccups this
weekend; sorry for Pieter's messages appearing in your inbox multiple
times, it is not his fault.
I deleted the extra copies from the mailing list archives.
As for the contents of his message, since this mailing list was not
Actual BDB files are absolutely not deterministic. Nor is the raw
blockchain itself currently, because blocks aren't always added in the
same order (plus they get orphans in them)
That's true. Though if you prune up to the last checkpoint, orphans
before that point can be safely thrown away.
On Mon, Jun 11, 2012 at 08:10:22PM +0200, thoma...@gmx.de wrote:
discussion back here. The executive summary: Pieter and I feel like
BIP 22 is overly complicated, and would like it to be simpler. I'd
especially like to hear what people think will be the will be used by
lots of pool
I submitted a pull request yesterday that implements low-level raw
transaction, and am looking for feedback on the API and help with
trying to test/break it.
Design doc: https://gist.github.com/2839617
Pull request: https://github.com/bitcoin/bitcoin/pull/1456
Test plan:
On Thu, Jun 14, 2012 at 9:22 AM, Gavin Andresen gavinandre...@gmail.comwrote:
I've been asked a couple of times: why doesn't signrawtx handle the
BIP 0010 (https://en.bitcoin.it/wiki/BIP_0010) transaction format?
I considered parsing/writing BIP 10 format for raw transactions, but
decided
Block 177618 was rejected by BIP16-enabled backports (0.4.x and 0.5.x) due to
containing a P2SH redemption with over 200 bytes in. Since the BIP16 code uses
IsPushOnly to check the scriptSig for compliance, and IsPushOnly in these
versions also enforced the 200-byte is standard rule, they were
This is super cool!
I have a feature request: it would be awesome to be able to provide private
keys at the command line with the signature, turning the client into a
wallet-less signature machine.
Peter
On Thu, Jun 14, 2012 at 9:22 AM, Gavin Andresen gavinandre...@gmail.comwrote:
I
I had to hit the sack last night as it was 2am CET, but I'd like to
sum up the discussion we had on IRC about scalability and SatoshiDice
in particular.
I think we all agreed on the following:
- Having senders/buyers pay no fees is psychologically desirable even
though we all understand that
Need to specify the format of how these arrive. It means that when a
new block is found instead of inv-getdata-block we'd see something
like inv-getdata-merkleblock where a merkleblock structure is a
header + list of transactions + list of merkle branches linking them
to the root.
Thinking
On Thu, 2012-06-14 at 13:52 +0200, Mike Hearn wrote:
filterinit(false positive rate, number of elements): initialize
filterload(data): input a serialized bloom filter table metadata and data.
Why not combine these two?
I believe its because it allows the node which will have to use the
Yes, the format is something that must be hashed out (no pun
intended). Need input from potential users about what information
they might need.
Matts point that a branch-per-transaction may duplicate data is well
made, that said, I suspect a format that tries to fix this would be
much more
On Fri, 2012-06-15 at 15:23 +0200, Mike Hearn wrote:
Why not combine these two?
I believe its because it allows the node which will have to use the
bloom filter to scan transactions to chose how much effort it wants to
put into each transaction on behalf of the SPV client.
If that's
On Fri, 2012-06-15 at 15:43 +0200, Mike Hearn wrote:
Yes, the format is something that must be hashed out (no pun
intended). Need input from potential users about what information
they might need.
Matts point that a branch-per-transaction may duplicate data is well
made, that said, I
On Fri, Jun 15, 2012 at 9:43 AM, Mike Hearn m...@plan99.net wrote:
How about see this project as a three part change?
First step - add the mempool command and make nodes sync up their
mempools on startup.
Here's the mempool implementation:
https://github.com/bitcoin/bitcoin/pull/1470
SPV
On Fri, Jun 15, 2012 at 4:59 PM, Peter Vessenes pe...@coinlab.com wrote:
Hi all,
I've been wondering about whether it would be possible to wipe out the GUI
completely from the satoshi client, and reimplement any necessary data
requests as RPC calls, allowing us to fork -QT and other GUIs
On Fri, 2012-06-15 at 15:34 +0200, Mike Hearn wrote:
The idea can be more generalized in that there are many cases where the
generator of a transaction doesn't care about confirmation times, and
would really be willing to make their transaction lower priority than
other 0-fee transactions.
On Fri, 2012-06-15 at 11:32 -0400, Jeff Garzik wrote:
As for full nodes... I like the organic growth and random nature of
the mempools. On the fence, WRT full node mempool sync at startup.
I dont particularly care either way, but I have a feeling miners will
really want that so that they can
[I originally sent an earlier version of this message to Mike off
list, but I figure it's worth adding to the public discussion]
On Fri, Jun 15, 2012 at 7:29 AM, Mike Hearn m...@plan99.net wrote:
(4) Making the block size limit float is better than picking a new
arbitrary threshold.
On the
Thanks Mike for the writeup - I'm very sad to have missed the discussion
on IRC since fee economics are probably my favorite topic, but I'll try
to contribute to the email discussion instead.
(4) Making the block size limit float is better than picking a new
arbitrary threshold.
Fees are a
On Fri, Jun 15, 2012 at 12:56 PM, Stefan Thomas m...@justmoon.de wrote:
The artificial limits like the block size limit are essentially putting
[...]
Changing the block size is an item for the hard-fork list. The chance
of the block size limit changing in the short term seems rather low...
it
I do agree that changing/lifting the block size limit is a hard fork
measure, but Mike raised the point and I do believe that whatever we
decide to do now will be informed by our long term plan as well. So I
think it is relevant to the discussion.
Can someone please help quantify the situation?
Grouping mempool transactions based on fees of the group seems
an unnecessary complexity; it makes it harder to predict if an isolated
transaction has enough juice to be included in the next Block.
Given your point about economic actors adapting to conditions, would it not
be simpler to use a
Why though? The bottleneck is not network traffic but disk space
usage/blockchain validation time.
- Original Message -
From: Mike Hearn m...@plan99.net
To: Jeff Garzik jgar...@exmulti.com
Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net
Sent: Friday, June 15, 2012
less expensive. This is no more real or less artificial then an
imposed licensing fee or the like and it is not subject to market
forces.
Sure, the market is not always efficient nor desirable. This seems more like a
social question though about choice and information. I do strongly feel that
On Fri, Jun 15, 2012 at 2:50 PM, Amir Taaki zgen...@yahoo.com wrote:
Part of the problem is that Satoshi didn't totally anticipate the growth of
the network. The block reward (the subsidy) is too high, which is why
transactions can afford to be so cheap. What would happen if blocks required
(1) Change the mining code to group transactions together with their
mempool dependencies and then calculate all fees as a group.
I think there is general consensus this is a good idea.
(2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to
avoid paying excessive fees and
On Fri, Jun 15, 2012 at 04:58:55PM -0400, grarpamp wrote:
When bitcoind exits cleanly, it does not seem safe for the blockchain
to clean up the following hierarchy with rm -r ?
Use -detachdb if you want to detach the blockchain database files from the
database environment at exit. This was
Outside of major features advertised network-wide in nService bits,
P2P protocol lacks a good method of enumerating minor features or
extensions. The version number increment is coarse-grained, and is
not self-documenting. A simple extension which lists supported
commands is added, as
Introspection/command discovery is nice, but I would prefer it to be
immediately done in the first version exchange so no assumptions as to how a
network is operating need to be made.
I like the idea of a flat list of commands. It might make sense to have
meta-commands that alias to groups of
Yes, I measure mainnet confirmation times on a regular basis.
http://bitcoinstats.org/post/tx-confirmation-times-June2012.png
Before fairly recently, fee-paying transactions never took anywhere close to
this long to be confirmed.
Jonathan Warren
(Bitcointalk: Atheros)
-Original
Did anyone try sending them an email asking them to stop or offering help to
fix their site? What did they say? I'm sure they would try to be accomodating.
- Original Message -
From: Jonathan Warren jonat...@bitcoinstats.org
To: bitcoin-development@lists.sourceforge.net
Cc:
Sent:
On Saturday 16 Jun 2012 07:45:00 Wladimir wrote:
As replied on the github issue:
Personally I still think it's better to have a clear standardized
protocol version, that implies what capabilities are supported,
instead of a capability-based system that explicitly lists them.
The bottleneck for the android Bitcoin Wallet app is rapidly becoming
bandwidth and parse time.
On Fri, Jun 15, 2012 at 8:42 PM, Amir Taaki zgen...@yahoo.com wrote:
Why though? The bottleneck is not network traffic but disk space
usage/blockchain validation time.
- Original Message
Hello all,
while OpenSSL's silent support for compressed public keys allowed us to
enable them in a fully backward-compatible way, it seems OpenSSL supports yet
another (and non-standard, and apparently useless) encoding for public keys.
As these are supported by (almost all?) fully validating
On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen gavinandre...@gmail.com wrote:
RE: 0x06/0x07 'hybrid' public keys:
Any opinions? Forbidding it certainly makes alternative implementation
slightly easier in the future, but I'm not sure the hassle of a network
rule change is worth it.
I say
On Saturday, June 16, 2012 11:39:00 PM Gregory Maxwell wrote:
On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
RE: 0x06/0x07 'hybrid' public keys:
Any opinions? Forbidding it certainly makes alternative implementation
slightly easier in the future, but I'm not
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 :)
#ifdef USE_UPNP
#if USE_UPNP
-upnp\t + _(Use Universal Plug and
Play to map the listening port (default: 1)) + \n +
#else
On Sun, Jun 17, 2012 at 5:22 AM, grarpamp grarp...@gmail.com 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
* 0x04 [32-byte X coord] [32-byte Y coord]: uncompressed format
* 0x06 [32-byte X coord] [32-byte Y coord]: hybrid format for even Y coords
* 0x07 [32-byte X coord] [32-byte Y coord]: hybrid format for odd Y coords
So what's the actual difference in format? Is there any at all, or
it's just
On Sun, Jun 17, 2012 at 2:04 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
On Sun, Jun 17, 2012 at 01:01:12PM +0200, Mike Hearn wrote:
* 0x04 [32-byte X coord] [32-byte Y coord]: uncompressed format
* 0x06 [32-byte X coord] [32-byte Y coord]: hybrid format for even Y
coords
* 0x07
All,
With the flurry of discussion about blockchain compression, I thought it
was time to put forward my final, most-advanced idea, into a single,
well-thought-out, *illustrated*, forum post. Please check it out:
https://bitcointalk.org/index.php?topic=88208.0
This is a huge
On Sun, Jun 17, 2012 at 02:39:28PM -0400, Alan Reiner wrote:
All,
With the flurry of discussion about blockchain compression, I
thought it was time to put forward my final, most-advanced idea,
into a single, well-thought-out, *illustrated*, forum post.
Please check it out:
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 branches with the commits that will
make it into the next
On Sun, Jun 17, 2012 at 5:35 PM, grarpamp grarp...@gmail.com 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
Hi,
I did describe a very similar thing back in January (also illustrated,
and, if I'm not mistaken, more simple and efficient to recalculate),
and I wanted to do a prototype, but I have been very busy with other
projects since then.
https://en.bitcoin.it/wiki/User:DiThi/MTUT
I just saw Gavin
Hi Alberto,
Your thread was part of the inspiration for the idea that I proposed.
But as I read it more, I see that I originally misunderstood it
(mistaking it for a simpler unspent-TxOut tree idea). Even after
reading it, I'm not entirely clear how your proposal would work, but I
see that
On Sunday, June 17, 2012 11:04:42 PM grarpamp wrote:
https://github.com/bitcoin/bitcoin
https://git.gitorious.org/bitcoin/bitcoind-stable
The latter is Luke's backports of security and stability fixes to
otherwise unmaintained old versions.
Ah ok, coming from cvs/svn, it's a bit
On Sun, Jun 17, 2012 at 7:04 PM, grarpamp grarp...@gmail.com 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
Sorry for the duplication Amir, I meant to send this to everyone:
BitTorrent might be an example to look to here. It's a peer-to-peer network
that has undergone many significant protocol upgrades over the years while
maintaining compatibility. More recent clients have had the ability to
expose
On Mon, Jun 18, 2012 at 12:46:47AM +0200, Alberto Torres wrote:
Hi,
I did describe a very similar thing back in January (also illustrated,
and, if I'm not mistaken, more simple and efficient to recalculate),
and I wanted to do a prototype, but I have been very busy with other
projects since
I switched the transaction database to use the Google LevelDB library,
which is a refactored out part of BigTable.
Here are my results. All tests are done on this hard disk:
+list
On Mon, Jun 18, 2012 at 9:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
In addition to the ECDSA caching, ECDSA can can easily be run on
multiple cores for basically a linear speedup.. so even with the
checking in place once ECDSA was using multiple threads we'd be back
to the DB
OK, to make progress on this work I need a few decisions (Gavin?)
1) Shall we do it?
What problem does it solve?
If the problem it will solve is it will only take 4 hours to download
the entire blockchain next year instead of taking 16 hours then no, I
don't think we should do it, both 4 and
Peter Todd wrote:
My solution was to simply state that vertexes that happened to cause the
tree to be unbalanced would be discarded, and set the depth of inbalance
such that this would be extremely unlikely to happen by accident. I'd
rather see someone come up with something better though.
I hope that someone else here would chime in on the issue raised in the
thread, about using a tree-structure that has multiple valid
configurations for the same set of unspent-TxOuts. If you use any
binary tree, you must replay the entire history of insertions and
deletions in the correct
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
On 06/19/2012 01:59 PM, Gregory Maxwell wrote:
On Tue, Jun 19, 2012 at 1:33 PM, Alan Reineretothe...@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
On Tue, Jun 19, 2012 at 10:33 AM, Alan Reiner etothe...@gmail.com wrote:
I hope that someone else here would chime in on the issue raised in the
thread, about using a tree-structure that has multiple valid
configurations for the same set of unspent-TxOuts. If you use any
binary tree, you
Alan Reiner wrote:
A PATRICIA tree/trie would be ideal, in my mind, as it also has a
completely deterministic structure, and is an order-of-magnitude more
space-efficient. Insert, delete and query times are still O(1).
However, it is not a trivial implementation. I have occasionally looked
Flights booked. Mike Hearn and I will be there. :)
On 6/22/2012 1:03 AM, Amir Taaki wrote:
This is happening in Berlin if anyone is around: http://bitcoin-hackathon.com/
I am happy to host if space is needed.
--
I think there may be an ideal order of ops bug around rescan,
wallet upgrades/import and last block markers.
I dropped an old wallet in a current blockchain.
First ran - in rescan mode.
It said old walletver.
Then rescanned whole chain.
AddToWallet some blockhash, blocks out of range,
I've been having a discussion with d'aniel from the forums about how
to handle the possibility of a majority-miner conspiracy to raise
inflation, if most economic actors use SPV clients.
Because of how blocks are formatted you cannot check the coinbase of a
transaction without knowing the fees in
Very interesting for you to bring this up. I had a similar idea for a
totally different use case. Greg recently pointed out an interesting
dilemma saying that (significantly) larger blocks would lead to
centralization. So I've been working on a design for a decentralized
pool that can handle
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
Link?
It was a private conversation for some reason.
I also proposed this on this list (see the response in the tree
datastructures thread) along with more elaboration on IRC.
Ah OK. I wasn't paying much attention to those threads.
I've added some more commits:
https://github.com/mikehearn/bitcoin/commits/leveldb
It's still not ready for a pull req but is a lot closer:
1) Auto-migration is there but not well tested enough (I only tested
with empty wallets).
2) Migration progress UI is there so you have something to watch
Here's the conversation I had with Mike that Gregory requested a
link to:
Thanks!
Bad or hacked client devs is indeed a huge, worrying problem.
The official client is addressing this with a system called
gitian, where multiple
Hello everyone,
a few days ago we merged Tor hidden service support in mainline. This means
that it's now possible to run a hidden service bitcoin node, and connect to
other bitcoin hidden services (via a Tor proxy) when running git HEAD. See
doc/Tor.txt for more information. This is expected to
Additionally, such addresses are exchanged and relayed via the P2P network.
To do so, we reused the fd87:d87e:eb43::/48 IPv6 range. Each address in this
80-bit range is mapped to an onion address, and treated as belonging to a
separate network. This network range is the same as used by the
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
GregM, wasn't sure how to answer your question, and as to
conflicts [1]. I think I grasped it in my reply to something on
tor-talk, which is on its way here pending moderation due to bcc.
I put that part below. The FYI referred to seednodes as
they exist on Tor / I2P today.
You are going to want
Hello all,
I've implemented a new block/transaction validation system for the
reference client, called ultraprune.
Traditionally, pruning for bitcoin is considered to be the ability to
delete full transactions from storage once all their outputs are spent,
and they are buried deeply enough in
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik jgar...@exmulti.com wrote:
On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes pe...@coinlab.com wrote:
The proposal is simple, and it's a small change for miners, I imagine.
My question is: why?
I worry about stuffing too many requirements on
So,
The proposal is simple, and it's a small change for miners, I imagine.
My question is: why?
I worry about stuffing too many requirements on the coinbase. I suppose the
coinbase is easily extendible if we run out of bytes, but I think I'd like
to see some more discussion / good / bad type
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]
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 essentially what BIP 30 did.
We want to do this also, partly for belt and
It would be nice if Bitcoin was engineered this way from the start. The amount
of workarounds, special cases and code bloat to deal with the fact that txs are
non-unique was a massive headache for me.
From: Mark Friedenbach m...@monetize.io
To: Jeff Garzik
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
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
sourcecode for this client available for review? I couldn't
Sources are available here:
http://code.google.com/p/bitcoin-wallet/
Mats
Quoting Amir Taaki zgen...@yahoo.com:
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,
OK thanks. I just went and made those sections then saw your posts.
Anyway we have a section for proprietary clients now. Please tell me if
anything looks disagreeable, http://bitcoin.org/clients.html
One thing I'm going to do is randomise the positioning order within sections
upon refresh.
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
Any chance the blockchain.info iphone app could be included on the clients
page? The source is available under an lGPL license:
https://github.com/blockchain/My-Wallet-iPhone. More
info:https://blockchain.info/wallet/iphone-app
Also the javascript web front end can be reviewed using a
JS randomisation is bad. People shouldn't need JS to view a webpage.
Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be
first either when it dominates the front page. It is perfectly fine as it is.
You are not a developer of any alternative clients, and this is a
You are not a developer of any alternative clients
I am and I'm going to have to agree with Greg. Information about clients
is bound to be transient and controversial.
My relatively naive suggestion would be to move it to the Wiki. If it
can handle the controversies involved with the Trade
On Mon, Jul 9, 2012 at 11:21 AM, Amir Taaki zgen...@yahoo.com wrote:
Is the sourcecode for this client available for review? I couldn't find it.
yes:
http://code.google.com/p/bitcoin-wallet/
and it is built upon
http://code.google.com/p/bitcoinj/
harald
501 - 600 of 6197 matches
Mail list logo
