* [Bitcoin-development] [ANNOUNCE] BitCoinJ 0.5 released
@ 2012-05-30 15:58 99% Mike Hearn
0 siblings, 0 replies; 87+ results
From: Mike Hearn @ 2012-05-30 15:58 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
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. It also includes
the first preview of the native API, allowing you to access bitcoinj from
C++/Objective-C++ using a straightforward, intuitive mapping from the Java
API. Much easier than JNI and no JVM is required, just the libgcj support
library. Examples of a native Cocoa app for OS X and a command line hello
world app are included. Because it's not fully finished/documented yet,
this work is available on a branch rather than in the main release.
We now have a Google+ page where we'll post announcements and developer
tips/ideas: https://plus.google.com/102614914114364947458
New in this release:
- Address.getParameters() and Address.getParametersFromAddress() let you
figure out for what network the address is for (test, production, etc).
BitcoinURI no longer requires a NetworkParameters for the same reason.
- Updated to latest bouncy castle version, remove the need for the
Android artifact by using the SpongyCastle build
- Receives pending transactions much faster than before
- Update to the testnet2 rules
- Wallets now store the current chain head
- wallet-tool can now create and broadcast transactions from the command
line
- Wallets will now be auto-migrated to protobuf format if they were
previously serialized Java objects
- Now uses the standard Maven directory layout
- Many important bugfixes
I'd like to thank Jim Burton, Miron Cuperman, Andreas Schildbach and Gary
Young for their contributions to this release.
You can get it from the download page on www.bitcoinj.org
[-- Attachment #2: Type: text/html, Size: 2904 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-26 11:52 99% ` Stefan Thomas
2012-05-28 14:54 99% ` Peter Vessenes
@ 2012-05-29 16:30 99% ` Rebroad (sourceforge)
1 sibling, 0 replies; 87+ results
From: Rebroad (sourceforge) @ 2012-05-29 16:30 UTC (permalink / raw)
Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]
I'd like to garner consensus on whether anyone else thinks it desirable to
have a flag option for bitcoin to punish blocks for not including
transactions. I notice there are already pro-miner options, such as the
restricting the relaying of free transactions, and so including an option
to restrict relaying of blocks from "stingy" miners to balance against the
current bias, so that the default bitcoin client can be run as much
pro-miner as pro-non-miner.
On Monday, May 28, 2012, rebroad@gmail•com wrote:
> What i think this thread reveals is whether a bitcoin client is pro-miner
> or pro-non-miner. What i think is needed is a fork where one benefits
> miners (e.g. Limits relaying of free transactions, as has been added to the
> current default client), and one that benefits non-miners (e.g. Limits
> relaying of blocks not including free transactions). Then people can vote
> based on the client they use.
>
> It seems to me that the current main client is a pro-miner one, and
> possibly not what most people would vote for if they were given an easier
> choice.
[-- Attachment #2: Type: text/html, Size: 1306 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-29 15:18 99% ` Luke-Jr
@ 2012-05-29 15:28 99% ` Peter Vessenes
2012-05-29 15:34 99% ` Luke-Jr
0 siblings, 1 reply; 87+ results
From: Peter Vessenes @ 2012-05-29 15:28 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4012 bytes --]
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 that some
work is necessary for such miners.
Finally I will just comment that I am guided by the general perspective
that many things about bitcoins are opt-in; therefore it makes sense to me
put difficult work onto those who are motivated to do it, and keep things
as easy as possible for the 'maybes' to participate -- hence small
courtesies like allowing text/plain or text/html.
Peter
On Tue, May 29, 2012 at 11:18 AM, Luke-Jr <luke@dashjr•org> wrote:
> On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote:
> > 1) Germane to the original conversation, anything hard to implement will
> > not get implemented by miners.
>
> Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch,
> anything modifying the coinbase is hard to implement.
>
> > 2) Coinbase is hard-limited to 100 bytes; this has to include space for
> > voting as well as extra nonce, etc. So, I'm not sure that a full URL is a
> > good plan.
>
> Rather, I would suggest a 20 byte keyhash, which allows the owner to
> broadcast
> a full URI out-of-band.
>
> > 1) They shall prepend \mi: to the url to designate it as a url for miner
> > info, and append a trailing \ to the url
>
> How about a simple prefix to the fixed-size keyhash?
> Perhaps "MFR=" (Mining Fee Rules)
>
> > 2) The url given in the coinbase shall have http:// prepended to it
> before
> > processing.
>
> I would recommend miners use https, with a specified SSL keyhash in the URI
> (so we don't need to pay for a "proper" SSL cert).
>
> > 3) The destination may be a redirect (to allow short URLs), or may
> deliver
> > content
>
> Clients should simply be required to follow the relevant HTTP
> specification.
>
> > 4) The content-type returned by the final site post-redirect shall be
> > either (preferred text/json) or text/plain or text/html
>
> text/plain and text/html are just wrong and don't make any sense here.
>
> > Inre: Luke's complaint about JSON, it is the language of the web. There
> is
> > no easier format for both computers and humans to read, and in this case,
> > it includes extensibility, which is nice, since we have no idea how
> miners
> > will wish to divvy up their services; I think one would need to make a
> > strong case against JSON for a specific reason to not choose it by
> default.
>
> Bitcoin isn't "the web", it's a complicated script-based cryptocurrency.
> Everything in the Bitcoin protocol requires a computer's interpretation for
> humans, and there's no reason to stray from this default. Also, JSON is not
> extensible in any of the ways needed for this specific purpose.
>
> > 4) The text of the document delivered shall be a JSON format dictionary,
> > and shall include at minimum the following fields: 'min_fee',
> 'pool_name',
> > and 'last_modified' Optional fields can be determined over time as
> > necessary by the mining community
>
> Last Modified and other caching rules are dealt with in the relevant HTTP
> specification...
>
> > 5) The Service Level Agreement isn't binding, but miners who implement it
> > are expected to make a best efforts attempt to follow it.
>
> While it doesn't make sense to give it the full legal force of a contract,
> I
> think it should be expressed as a "MUST" in the BIP.
>
> > Generally a miner would occasionally publish the \mi:\ when they had
> > updated their SLA, or just every so often, but the canonical location
> would
> > be the final destination URL from the redirects.
>
> The coinbase advertisement MUST be part of every coinbase mined by the
> miner,
> or there's no reliable way to prove which blocks are theirs.
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
[-- Attachment #2: Type: text/html, Size: 5293 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-29 15:39 99% ` Luke-Jr
@ 2012-05-29 15:45 99% ` Peter Vessenes
0 siblings, 0 replies; 87+ results
From: Peter Vessenes @ 2012-05-29 15:45 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]
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 for something that may not be a particularly big problem in the
bitcoin world is good -- it carries much less technical implementation debt
going forward, and has a lower risk of sort of seizing up development with
additional necessary code to worry about for those implementing to-spec
clients.
If that lighter solution turns out to be gameable, or has problems that
require the full force of the bitcoin network and concepts, that would be
the time to implement the improved version. That's just my approach,
however. I worry that building in any additional requirements to the
protocol or codebase adds significant cost to the network as a whole over
the next 10 years.
Peter
On Tue, May 29, 2012 at 11:39 AM, Luke-Jr <luke@dashjr•org> wrote:
> 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
> broadcasts, that allow miners to publish/update their policy URI signed by
> the
> key in question. Counter-DDoS rules could decline to relay or store URIs
> for
> keys that haven't been published in - or achieved statistical significance
> in
> - the last N blocks.
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
[-- Attachment #2: Type: text/html, Size: 2576 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-29 15:36 99% ` Peter Vessenes
@ 2012-05-29 15:39 99% ` Luke-Jr
2012-05-29 15:45 99% ` Peter Vessenes
0 siblings, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-29 15:39 UTC (permalink / raw)
To: Peter Vessenes; +Cc: bitcoin-development, Michael
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
broadcasts, that allow miners to publish/update their policy URI signed by the
key in question. Counter-DDoS rules could decline to relay or store URIs for
keys that haven't been published in - or achieved statistical significance in
- the last N blocks.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-29 15:34 99% ` Luke-Jr
@ 2012-05-29 15:36 99% ` Peter Vessenes
2012-05-29 15:39 99% ` Luke-Jr
0 siblings, 1 reply; 87+ results
From: Peter Vessenes @ 2012-05-29 15:36 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
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.
Best,
Peter
On Tue, May 29, 2012 at 11:34 AM, Luke-Jr <luke@dashjr•org> wrote:
> On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote:
> > I don't understand what the 20 byte keyhash is. Can you elucidate?
>
> 20 byte keyhashes are a fundamental building block of the Bitcoin protocol.
>
> ripemd160(sha256(ecdsaPubKey))
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
[-- Attachment #2: Type: text/html, Size: 1318 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-29 14:47 99% ` Luke-Jr
@ 2012-05-29 15:05 99% ` Peter Vessenes
2012-05-29 15:18 99% ` Luke-Jr
0 siblings, 1 reply; 87+ results
From: Peter Vessenes @ 2012-05-29 15:05 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2924 bytes --]
OK, I have a few thoughts on this:
1) Germane to the original conversation, anything hard to implement will
not get implemented by miners.
2) Coinbase is hard-limited to 100 bytes; this has to include space for
voting as well as extra nonce, etc. So, I'm not sure that a full URL is a
good plan.
3) I'm a little fuzzy on the details of BIP governance; but I'm happy to
write one up and get my thoughts down, or someone who's more familiar could
do it, I suppose.
I propose the following spec:
periodically a miner may choose to publish a url through their coinbase as
follows:
1) They shall prepend \mi: to the url to designate it as a url for miner
info, and append a trailing \ to the url
2) The url given in the coinbase shall have http:// prepended to it before
processing.
3) The destination may be a redirect (to allow short URLs), or may deliver
content
4) The content-type returned by the final site post-redirect shall be
either (preferred text/json) or text/plain or text/html
4) The text of the document delivered shall be a JSON format dictionary,
and shall include at minimum the following fields: 'min_fee', 'pool_name',
and 'last_modified' Optional fields can be determined over time as
necessary by the mining community
5) The Service Level Agreement isn't binding, but miners who implement it
are expected to make a best efforts attempt to follow it.
So a valid coinbase could be:
/P2SH/\mi:goo.gl/mr2D\extra_nonce:2110
Generally a miner would occasionally publish the \mi:\ when they had
updated their SLA, or just every so often, but the canonical location would
be the final destination URL from the redirects.
Inre: Luke's complaint about JSON, it is the language of the web. There is
no easier format for both computers and humans to read, and in this case,
it includes extensibility, which is nice, since we have no idea how miners
will wish to divvy up their services; I think one would need to make a
strong case against JSON for a specific reason to not choose it by default.
Thoughts welcome!
Best,
Peter
On Tue, May 29, 2012 at 10:47 AM, Luke-Jr <luke@dashjr•org> wrote:
> On Tuesday, May 29, 2012 8:52:49 AM Michael Grønager wrote:
> > The format of the sla.php page should then be specified too - but it
> could
> > be a json-rpc call returning a json object like (as result): {
> > sla_version: "0.1",
> > accept_no_fee_tx: false,
> > min_fee: 50000,
> > big_tx_fee: 10000, // extra fee pr kb
> > }
> > I guess miners could work out a more suitable set of fees...
>
> Please not JSON, and not hard-coded logic. Bitcoin already has a secure
> scripting system - perhaps we can decide on an initial stack format and
> run a
> script retrieved from the URI?
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
[-- Attachment #2: Type: text/html, Size: 4031 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-29 15:28 99% ` Peter Vessenes
@ 2012-05-29 15:34 99% ` Luke-Jr
2012-05-29 15:36 99% ` Peter Vessenes
0 siblings, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-29 15:34 UTC (permalink / raw)
To: Peter Vessenes; +Cc: bitcoin-development, Michael
On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote:
> I don't understand what the 20 byte keyhash is. Can you elucidate?
20 byte keyhashes are a fundamental building block of the Bitcoin protocol.
ripemd160(sha256(ecdsaPubKey))
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-24 16:33 99% [Bitcoin-development] Punishing empty blocks? Jeff Garzik
` (5 preceding siblings ...)
2012-05-26 5:03 99% ` Zooko Wilcox-O'Hearn
@ 2012-05-29 15:33 99% ` Gregory Maxwell
6 siblings, 0 replies; 87+ results
From: Gregory Maxwell @ 2012-05-29 15:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Development
On Thu, May 24, 2012 at 12:33 PM, Jeff Garzik <jgarzik@exmulti•com> wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks.
In the last 2016 blocks, as I write this, there are only 35 1 txn blocks.
This is about 1.73%, which wouldn't be surprising just from timing
alone. Moreover, a fair amount (I didn't measure the percentage)
appear to be mined by Eligius— Luke does some clever pre-computation
of the hash tree for faster distribution right after new blocks.
Resources expended on fancy (and potentially risky) techno-economic
hacks to discourage empty blocks would probably be better spent
writing very fast transaction tree generating code.
Can we kill this thread now?
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-29 15:05 99% ` Peter Vessenes
@ 2012-05-29 15:18 99% ` Luke-Jr
2012-05-29 15:28 99% ` Peter Vessenes
0 siblings, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-29 15:18 UTC (permalink / raw)
To: Peter Vessenes; +Cc: bitcoin-development, Michael
On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote:
> 1) Germane to the original conversation, anything hard to implement will
> not get implemented by miners.
Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch,
anything modifying the coinbase is hard to implement.
> 2) Coinbase is hard-limited to 100 bytes; this has to include space for
> voting as well as extra nonce, etc. So, I'm not sure that a full URL is a
> good plan.
Rather, I would suggest a 20 byte keyhash, which allows the owner to broadcast
a full URI out-of-band.
> 1) They shall prepend \mi: to the url to designate it as a url for miner
> info, and append a trailing \ to the url
How about a simple prefix to the fixed-size keyhash?
Perhaps "MFR=" (Mining Fee Rules)
> 2) The url given in the coinbase shall have http:// prepended to it before
> processing.
I would recommend miners use https, with a specified SSL keyhash in the URI
(so we don't need to pay for a "proper" SSL cert).
> 3) The destination may be a redirect (to allow short URLs), or may deliver
> content
Clients should simply be required to follow the relevant HTTP specification.
> 4) The content-type returned by the final site post-redirect shall be
> either (preferred text/json) or text/plain or text/html
text/plain and text/html are just wrong and don't make any sense here.
> Inre: Luke's complaint about JSON, it is the language of the web. There is
> no easier format for both computers and humans to read, and in this case,
> it includes extensibility, which is nice, since we have no idea how miners
> will wish to divvy up their services; I think one would need to make a
> strong case against JSON for a specific reason to not choose it by default.
Bitcoin isn't "the web", it's a complicated script-based cryptocurrency.
Everything in the Bitcoin protocol requires a computer's interpretation for
humans, and there's no reason to stray from this default. Also, JSON is not
extensible in any of the ways needed for this specific purpose.
> 4) The text of the document delivered shall be a JSON format dictionary,
> and shall include at minimum the following fields: 'min_fee', 'pool_name',
> and 'last_modified' Optional fields can be determined over time as
> necessary by the mining community
Last Modified and other caching rules are dealt with in the relevant HTTP
specification...
> 5) The Service Level Agreement isn't binding, but miners who implement it
> are expected to make a best efforts attempt to follow it.
While it doesn't make sense to give it the full legal force of a contract, I
think it should be expressed as a "MUST" in the BIP.
> Generally a miner would occasionally publish the \mi:\ when they had
> updated their SLA, or just every so often, but the canonical location would
> be the final destination URL from the redirects.
The coinbase advertisement MUST be part of every coinbase mined by the miner,
or there's no reliable way to prove which blocks are theirs.
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] Testnet reset for the 0.7 release
@ 2012-05-29 14:54 99% Gavin Andresen
0 siblings, 0 replies; 87+ results
From: Gavin Andresen @ 2012-05-29 14:54 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]
Testnet "Mark III" will be part of the 0.7 release, and is now in the
master github branch.
"Mark III" because this is the third genesis block for the testnet. The
main reason for the reset is to get a more 'sane' test network; with the
BIP16 and BIP30 and testnet difficulty blockchain rule changes the old
testnet is a mess, with old clients serving up different, incompatible
chains. The good news is the mess uncovered a couple of
large-block-chain-reorganization bugs, but having a stable testnet to test
new implementations or services is more important.
Rules for tesnet3:
+ Minimum difficulty 1.0 (same as main net-- old testnet min difficulty
was 0.125)
+ max-difficulty-protection rule that allows blocks to be mined at min
difficulty if the block's timestamp is 20 minutes or more after the last
block AND the block isn't on a difficulty-adjustment boundary.
To make it easy to run either old code (using the old tesnet) and new code,
the wallet and blockchain are stored in $DATADIR/testnet3 instead of
$DATADIR/testnet.
And to make it easy to find other testnet3-running nodes, the IRC channel
used for bootstrapping is #bitcoinTEST3 (instead of #bitcoinTEST).
The new testnet comes with a new blockchain that is full of interesting
test cases. In particular, there are test cases for:
+ BIP16; early blocks were generated with a timestamp before the BIP16
switchover date, and there are transactions that test the BIP16 switchover
rules
+ Most of the enabled Script opcodes. I created thousands of transactions
that try to exercise edge cases in the Script interpreter. Missing are
comprehensive tests for the signature opcodes and SIGHASH_ modes.
+ Block acceptance rules, including the rule on maximum block size, block
times, etc (thanks to gmaxwell)
If you're re-implementing Bitcoin then accepting the Mark III testnet
blockchain is a good first test for compatibility. You'll still need to do
a lot of work to make sure you reject the same set of invalid transactions
or blocks as the original Bitcoin code.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2370 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-29 8:52 99% ` [Bitcoin-development] " Michael Grønager
@ 2012-05-29 14:47 99% ` Luke-Jr
2012-05-29 15:05 99% ` Peter Vessenes
0 siblings, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-29 14:47 UTC (permalink / raw)
To: bitcoin-development
On Tuesday, May 29, 2012 8:52:49 AM Michael Grønager wrote:
> The format of the sla.php page should then be specified too - but it could
> be a json-rpc call returning a json object like (as result): {
> sla_version: "0.1",
> accept_no_fee_tx: false,
> min_fee: 50000,
> big_tx_fee: 10000, // extra fee pr kb
> }
> I guess miners could work out a more suitable set of fees...
Please not JSON, and not hard-coded logic. Bitcoin already has a secure
scripting system - perhaps we can decide on an initial stack format and run a
script retrieved from the URI?
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-28 14:54 99% ` Peter Vessenes
[not found] ` <1338222334.48856.YahooMailNeo@web121001.mail.ne1.yahoo.com>
@ 2012-05-29 8:52 99% ` Michael Grønager
2012-05-29 14:47 99% ` Luke-Jr
1 sibling, 1 reply; 87+ results
From: Michael Grønager @ 2012-05-29 8:52 UTC (permalink / raw)
To: Peter Vessenes; +Cc: bitcoin-development
Peter, I like the idea of being able to know what fees to expect from different miners (it is like a service description / SLA for their service), but I would prefer a more distributed discovery mechanism for the information on the fees (Spent 10 years on Grid Computing...).
Miners could e.g. include a pointer to a webpage (or even their min fee) in the coinbase (encoded properly, like the "/P2SH/" string for BIP0016). That way clients could look it up them selves or you could create sites accumulating this information from the chain it self.
So something like :
const char* service_sla = "|https://my_ubercool_asic_mining_pool/sla.php|";
COINBASE_FLAGS << std::vector<unsigned char>(service_sla, service_sla+strlen(service_sla));
The format of the sla.php page should then be specified too - but it could be a json-rpc call returning a json object like (as result):
{
sla_version: "0.1",
accept_no_fee_tx: false,
min_fee: 50000,
big_tx_fee: 10000, // extra fee pr kb
}
I guess miners could work out a more suitable set of fees...
Seems like this calls for a BIP ?
/M
On 28/05/2012, at 16:54, Peter Vessenes wrote:
> One of the issues here though is that it would be nice if miners published their own tx rules -- it might be hard to impute them from data.
>
> I had started a thread about this on bitcoin.org some time ago, and I don't recall what the general outcome was.
>
> I had imagined an open service whereby a miner could publish a short string in their conbase tying to the service and the service would have different metadata, including the miner's transaction guarantees.
>
> We offered to host this before, and would still be willing to host such a service.
>
> Peter
>
> On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas <moon@justmoon•de> wrote:
> Zooko is spot on - slower confirmations will give people a reason to set
> higher fees. As soon as fees reach a level where they matter, even
> botnet operators will be looking into ways of including transactions for
> some extra profit.
>
> In the meantime slightly slower confirmations aren't a problem. Consider
> that even if it takes four blocks to get your transaction included
> instead of one, once it is included, you still benefit from every new
> block in terms of security. So if you're looking for six confirmations
> for example, even a three block delay will only be a 50% delay for you.
> And of course there are techniques for instant transactions which
> continue to be refined and improved.
>
> As for the proposed solutions: Punishing 1-tx blocks is complete and
> utter nonsense. It's trivial to include a bogus second transaction.
>
> Any additional challenges towards miners like hashes of the previous
> block are at best useless. If I was running a botnet, I'd just grab that
> hash from a website (pretty good chance Blockchain.info will have it :P)
> or mining pool or wherever and keep going undeterred. At worst they may
> affect scalability one day. You might imagine a peer-to-peer network of
> miners who for cost reasons don't download all blocks anymore, but
> verify only a percentage of them at random. They might then exchange
> messages about invalid blocks including a proof (invalid tx, merkle
> branch) why the block is invalid. This is just one idea, the point is
> that assumptions about what a legitimate miner looks like may not always
> hold in the future.
>
> Finally, there is an ethical aspect as well. If a miner wishes not to
> include my transaction that is his choice. He has no more an obligation
> to sell his service to me than I have to buy it from him. If I really,
> really want him to include my transaction I will have to offer to pay more.
>
> If we as developers think that confirmations are too slow or that more
> blocks should include transactions, then the right measures would be:
>
> - Educating users about the relationship between confirmation speed and fees
> - Raising the default transaction fee
>
> Every market has a supply curve, so it is economically to be expected
> that there will be some miners who don't include transactions, simply
> because they are at that end of the supply curve where it is not worth
> it for them to sell their service. All markets must have a certain
> tension - there must be miners who don't include transactions for there
> to be users who want their transactions included more quickly. In other
> words there must be somebody not confirming if confirmations are to have
> value. If you interfere with that all you'll accomplish is keep
> transaction fees below market level, which will make the transition from
> inflation-financed hashing to transaction-financed hashing more painful
> and disruptive.
>
> Cheers,
>
> Stefan
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
>
> Peter J. Vessenes
> CEO, CoinLab
> M: 206.595.9839
> Skype: vessenes
> Google+
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager@ceptacle•com
Web: http://www.ceptacle.com/
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] Fw: Punishing empty blocks?
[not found] ` <1338222334.48856.YahooMailNeo@web121001.mail.ne1.yahoo.com>
@ 2012-05-28 16:25 99% ` Amir Taaki
0 siblings, 0 replies; 87+ results
From: Amir Taaki @ 2012-05-28 16:25 UTC (permalink / raw)
To: bitcoin-development
That's a cool idea. Very meta.
________________________________
From: Peter Vessenes <peter@coinlab•com>
To: Stefan Thomas <moon@justmoon•de>
Cc: bitcoin-development@lists•sourceforge.net
Sent: Monday, May 28, 2012 4:54 PM
Subject: Re: [Bitcoin-development] Punishing empty blocks?
One of the issues here though is that it would be nice if miners published their own tx rules -- it might be hard to impute them from data.
I had started a thread about this on bitcoin.org some time ago, and I don't recall what the general outcome was.
I had imagined an open service whereby a miner could publish a short string in their conbase tying to the service and the service would have different metadata, including the miner's transaction guarantees.
We offered to host this before, and would still be willing to host such a service.
Peter
On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas <moon@justmoon•de> wrote:
Zooko is spot on - slower confirmations will give people a reason to set
>higher fees. As soon as fees reach a level where they matter, even
>botnet operators will be looking into ways of including transactions for
>some extra profit.
>
>In the meantime slightly slower confirmations aren't a problem. Consider
>that even if it takes four blocks to get your transaction included
>instead of one, once it is included, you still benefit from every new
>block in terms of security. So if you're looking for six confirmations
>for example, even a three block delay will only be a 50% delay for you.
>And of course there are techniques for instant transactions which
>continue to be refined and improved.
>
>As for the proposed solutions: Punishing 1-tx blocks is complete and
>utter nonsense. It's trivial to include a bogus second transaction.
>
>Any additional challenges towards miners like hashes of the previous
>block are at best useless. If I was running a botnet, I'd just grab that
>hash from a website (pretty good chance Blockchain.info will have it :P)
>or mining pool or wherever and keep going undeterred. At worst they may
>affect scalability one day. You might imagine a peer-to-peer network of
>miners who for cost reasons don't download all blocks anymore, but
>verify only a percentage of them at random. They might then exchange
>messages about invalid blocks including a proof (invalid tx, merkle
>branch) why the block is invalid. This is just one idea, the point is
>that assumptions about what a legitimate miner looks like may not always
>hold in the future.
>
>Finally, there is an ethical aspect as well. If a miner wishes not to
>include my transaction that is his choice. He has no more an obligation
>to sell his service to me than I have to buy it from him. If I really,
>really want him to include my transaction I will have to offer to pay more.
>
>If we as developers think that confirmations are too slow or that more
>blocks should include transactions, then the right measures would be:
>
>- Educating users about the relationship between confirmation speed and fees
>- Raising the default transaction fee
>
>Every market has a supply curve, so it is economically to be expected
>that there will be some miners who don't include transactions, simply
>because they are at that end of the supply curve where it is not worth
>it for them to sell their service. All markets must have a certain
>tension - there must be miners who don't include transactions for there
>to be users who want their transactions included more quickly. In other
>words there must be somebody not confirming if confirmations are to have
>value. If you interfere with that all you'll accomplish is keep
>transaction fees below market level, which will make the transition from
>inflation-financed hashing to transaction-financed hashing more painful
>and disruptive.
>
>Cheers,
>
>Stefan
>
>
>------------------------------------------------------------------------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-26 11:52 99% ` Stefan Thomas
@ 2012-05-28 14:54 99% ` Peter Vessenes
[not found] ` <1338222334.48856.YahooMailNeo@web121001.mail.ne1.yahoo.com>
2012-05-29 8:52 99% ` [Bitcoin-development] " Michael Grønager
2012-05-29 16:30 99% ` Rebroad (sourceforge)
1 sibling, 2 replies; 87+ results
From: Peter Vessenes @ 2012-05-28 14:54 UTC (permalink / raw)
To: Stefan Thomas; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4302 bytes --]
One of the issues here though is that it would be nice if miners published
their own tx rules -- it might be hard to impute them from data.
I had started a thread about this on bitcoin.org some time ago, and I don't
recall what the general outcome was.
I had imagined an open service whereby a miner could publish a short string
in their conbase tying to the service and the service would have different
metadata, including the miner's transaction guarantees.
We offered to host this before, and would still be willing to host such a
service.
Peter
On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas <moon@justmoon•de> wrote:
> Zooko is spot on - slower confirmations will give people a reason to set
> higher fees. As soon as fees reach a level where they matter, even
> botnet operators will be looking into ways of including transactions for
> some extra profit.
>
> In the meantime slightly slower confirmations aren't a problem. Consider
> that even if it takes four blocks to get your transaction included
> instead of one, once it is included, you still benefit from every new
> block in terms of security. So if you're looking for six confirmations
> for example, even a three block delay will only be a 50% delay for you.
> And of course there are techniques for instant transactions which
> continue to be refined and improved.
>
> As for the proposed solutions: Punishing 1-tx blocks is complete and
> utter nonsense. It's trivial to include a bogus second transaction.
>
> Any additional challenges towards miners like hashes of the previous
> block are at best useless. If I was running a botnet, I'd just grab that
> hash from a website (pretty good chance Blockchain.info will have it :P)
> or mining pool or wherever and keep going undeterred. At worst they may
> affect scalability one day. You might imagine a peer-to-peer network of
> miners who for cost reasons don't download all blocks anymore, but
> verify only a percentage of them at random. They might then exchange
> messages about invalid blocks including a proof (invalid tx, merkle
> branch) why the block is invalid. This is just one idea, the point is
> that assumptions about what a legitimate miner looks like may not always
> hold in the future.
>
> Finally, there is an ethical aspect as well. If a miner wishes not to
> include my transaction that is his choice. He has no more an obligation
> to sell his service to me than I have to buy it from him. If I really,
> really want him to include my transaction I will have to offer to pay more.
>
> If we as developers think that confirmations are too slow or that more
> blocks should include transactions, then the right measures would be:
>
> - Educating users about the relationship between confirmation speed and
> fees
> - Raising the default transaction fee
>
> Every market has a supply curve, so it is economically to be expected
> that there will be some miners who don't include transactions, simply
> because they are at that end of the supply curve where it is not worth
> it for them to sell their service. All markets must have a certain
> tension - there must be miners who don't include transactions for there
> to be users who want their transactions included more quickly. In other
> words there must be somebody not confirming if confirmations are to have
> value. If you interfere with that all you'll accomplish is keep
> transaction fees below market level, which will make the transition from
> inflation-financed hashing to transaction-financed hashing more painful
> and disruptive.
>
> Cheers,
>
> Stefan
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
[-- Attachment #2: Type: text/html, Size: 5582 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] IPv6 bitcoin support now live
2012-05-26 13:14 99% ` Pieter Wuille
@ 2012-05-27 17:02 99% ` Peter Todd
0 siblings, 0 replies; 87+ results
From: Peter Todd @ 2012-05-27 17:02 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 891 bytes --]
On Sat, May 26, 2012 at 03:14:40PM +0200, Pieter Wuille wrote:
> On Sat, May 12, 2012 at 3:42 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:
> > sipa just pushed out IPv6 support to bitcoin/bitcoin.git, and we have
> > a few IPv6 nodes live on the network already.
> >
> > If you have IPv6, please pull the latest bitcoin and test!
>
> Since yesterday, my DNS seeder (running at seed.bitcoin.sipa.be) also
> crawls the IPv6 network, and returns corresponding AAAA records.
> Hopefully this helps IPv6 nodes to find eachother.
I can confirm this seems to work quite well now. I tried running an
IPv6-only node a few days ago, and with the default seeds it couldn't
start up and sync with the network unless I manually created a dual-net
node and manually added it. Now things work just fine out of the box and
last I checked I had 5 peers.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] IPv6 bitcoin support now live
[not found] ` <CAPg+sBgf0uS9ua9kGcLraq_vQ+vx7o7XHfEdVRAEbYSG_6ibdQ@mail.gmail.com>
@ 2012-05-26 13:14 99% ` Pieter Wuille
2012-05-27 17:02 99% ` Peter Todd
0 siblings, 1 reply; 87+ results
From: Pieter Wuille @ 2012-05-26 13:14 UTC (permalink / raw)
To: Bitcoin Dev
On Sat, May 12, 2012 at 3:42 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:
> sipa just pushed out IPv6 support to bitcoin/bitcoin.git, and we have
> a few IPv6 nodes live on the network already.
>
> If you have IPv6, please pull the latest bitcoin and test!
Since yesterday, my DNS seeder (running at seed.bitcoin.sipa.be) also
crawls the IPv6 network, and returns corresponding AAAA records.
Hopefully this helps IPv6 nodes to find eachother.
--
Pieter
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-26 5:03 99% ` Zooko Wilcox-O'Hearn
@ 2012-05-26 11:52 99% ` Stefan Thomas
2012-05-28 14:54 99% ` Peter Vessenes
2012-05-29 16:30 99% ` Rebroad (sourceforge)
0 siblings, 2 replies; 87+ results
From: Stefan Thomas @ 2012-05-26 11:52 UTC (permalink / raw)
To: bitcoin-development
Zooko is spot on - slower confirmations will give people a reason to set
higher fees. As soon as fees reach a level where they matter, even
botnet operators will be looking into ways of including transactions for
some extra profit.
In the meantime slightly slower confirmations aren't a problem. Consider
that even if it takes four blocks to get your transaction included
instead of one, once it is included, you still benefit from every new
block in terms of security. So if you're looking for six confirmations
for example, even a three block delay will only be a 50% delay for you.
And of course there are techniques for instant transactions which
continue to be refined and improved.
As for the proposed solutions: Punishing 1-tx blocks is complete and
utter nonsense. It's trivial to include a bogus second transaction.
Any additional challenges towards miners like hashes of the previous
block are at best useless. If I was running a botnet, I'd just grab that
hash from a website (pretty good chance Blockchain.info will have it :P)
or mining pool or wherever and keep going undeterred. At worst they may
affect scalability one day. You might imagine a peer-to-peer network of
miners who for cost reasons don't download all blocks anymore, but
verify only a percentage of them at random. They might then exchange
messages about invalid blocks including a proof (invalid tx, merkle
branch) why the block is invalid. This is just one idea, the point is
that assumptions about what a legitimate miner looks like may not always
hold in the future.
Finally, there is an ethical aspect as well. If a miner wishes not to
include my transaction that is his choice. He has no more an obligation
to sell his service to me than I have to buy it from him. If I really,
really want him to include my transaction I will have to offer to pay more.
If we as developers think that confirmations are too slow or that more
blocks should include transactions, then the right measures would be:
- Educating users about the relationship between confirmation speed and fees
- Raising the default transaction fee
Every market has a supply curve, so it is economically to be expected
that there will be some miners who don't include transactions, simply
because they are at that end of the supply curve where it is not worth
it for them to sell their service. All markets must have a certain
tension - there must be miners who don't include transactions for there
to be users who want their transactions included more quickly. In other
words there must be somebody not confirming if confirmations are to have
value. If you interfere with that all you'll accomplish is keep
transaction fees below market level, which will make the transition from
inflation-financed hashing to transaction-financed hashing more painful
and disruptive.
Cheers,
Stefan
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-24 16:33 99% [Bitcoin-development] Punishing empty blocks? Jeff Garzik
` (4 preceding siblings ...)
2012-05-25 0:45 99% ` Luke-Jr
@ 2012-05-26 5:03 99% ` Zooko Wilcox-O'Hearn
2012-05-26 11:52 99% ` Stefan Thomas
2012-05-29 15:33 99% ` Gregory Maxwell
6 siblings, 1 reply; 87+ results
From: Zooko Wilcox-O'Hearn @ 2012-05-26 5:03 UTC (permalink / raw)
To: Bitcoin Development
For what it is worth, I question whether this is a problem. Or, I
guess I question whether the best solution to it isn't for people to
start including more transaction fees. In fact, I'm not entirely sure
that this problem doesn't actually *encourage* people to that
solution, which would be very good if true.
I would be more comfortable if the reward for mining were more
commensurate with the value it provides. Ultimately, of course, that
means that each transaction fee would have to be more of a proportion
of the value *to the spender* of that transaction being included in
the blockchain.
(Aside: in order to convey to outsiders that miners are providing a
useful service rather than gaining undeserved reward for wasting
electricity, I refer to them as "distributed transaction verification
servers" rather than "miners" whenever possible.)
I'm pretty sure that — assuming there isn't some Bitcoin-killing
disaster — transaction fees will eventually rise, but sooner might be
better, especially with the first coinbase-halving looming.
Perhaps people will be motivated to include transaction fees if they
know that some miners don't bother to validate their transactions and
others do. They may feel motivated to reward the miners that are
serving them and punish the ones that are not. (Note: this wouldn't be
a valid strategy on their part from a strictly game-theoretic
perspective, but if they act on those motivations, then I don't care
if it was rational or not.)
Also, they may decide that they want to counteract the added delay
which those no-transactions miners are adding to *all* transactions
(with or without fee), by putting a fee on their transactions in order
to make them take less long when they are processed by a miner which
does process (some) transactions.
Already this visualization, which I typically glance at a few times a
day, usually shows a good separation with fee-included transactions
sometimes doing much better than (some) free transactions:
http://bitcoinstats.org/
However, this graph shows that the aggregate reward to the miners for
processing transaction is minimal:
http://blockchain.info/charts/transaction-fees?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
You can see from the first visualization (assuming it is showing the
typical pattern that I've seen) how you risk greater delay by sending
your transaction without fees. The no-transactions miners push *all*
transactions, fee or no-fee to the right. This may incentivize more
people to change their transactions from red diamonds into blue
circles, in order to move their transactions further to the left, even
though the no-transactions miners are not currently discriminating
among the two types.
Therefore, the presence of those miners may help push the aggregate
fees in that latter graph up, which is something I would very much
like to see.
Regards,
Zooko
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-25 13:44 99% ` Alan Reiner
@ 2012-05-25 14:00 99% ` Peter Vessenes
0 siblings, 0 replies; 87+ results
From: Peter Vessenes @ 2012-05-25 14:00 UTC (permalink / raw)
To: Alan Reiner; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 6115 bytes --]
We just implemented our own mining tool, soup-to-nuts, and I would say that
the likely motivation for what I presume are botnet owners is just economic.
It's a lot more work to make sure your merkleing and keeping up-to-date are
happening than it is to just get an 80 byte header from a central server,
and re-calc a single transaction merkle client-side.
Not to mention the extra work to keep track of what version of
getmemorypool output you're receiving work for in a broadly distributed
pool.
For what it's worth, we did this extra engineering work since we care about
Bitcoin, but if I just wanted to pull value out of the ecosystem, we would
have skipped it.
The only solutions to this are economic solutions -- making such 'cheater'
blocks less valuable, or increasing the value of the transactions.
Also note that botnet operators likely care, in the end, about fiat
currency, so going to 25 btc per block in what I think of as transaction
fee subsidies won't necessarily impact this -- it's a matter of what
happens to exchange rates vs generation rates that will matter.
I think we also have to moderate this consideration against the rights (and
arguable benefits) of someone wanting to build an express-delivery mining
service, one that will provide provably faster certification for those
adding a transaction fee of, say, 1 btc.
My own experience now in the MMO world is that we have to carefully
understand how we deal with griefers who control massive resources (compute
or gold-farmers). It may not be a winning battle to choose a solution which
harms the rest of the network in exchange for harming the griefers.
This is definitely out of the box, but one solution might be to change the
difficulty calculations to just ignore 1tx blocks; that would minimize
impact on others to a great extent, and would let someone set up an express
block service if they chose. I guess we'd have to settle on whether or not
such blocks counted towards the issuance countdown as well. Or, we could
allow only 1/10 generation fees on such blocks.
Peter
On Fri, May 25, 2012 at 9:44 AM, Alan Reiner <etotheipi@gmail•com> wrote:
> I like the concept except that it only works if every node connected to
> the miner enforces the rule (if it works). Once any one of the nodes
> forwards the block, other nodes see it coming from a node that can pass
> the challenge.
>
> I don't think any solution based on node queries will succeed, especially
> if it requires spontaneous super-majority-of-nodes acceptance. I think
> it's gotta be based on the block itself and each nodes' own info.
>
> If you could spontaneously get all miners to agree not to build off of
> anti-social blocks (however that is defined) , it would have a chance of
> making a difference, but individual miners would have an advantage
> building off the antisocial block because they only need to produce one to
> create the longest chain (and collect reward) while the miners following
> the rules need two blocks.
>
> --Sent from my overpriced smartphone
> On May 25, 2012 3:48 AM, "Christian Decker" <decker.christian@gmail•com>
> wrote:
>
>> How about a simple proof of work test? This one though does not ask for
>> CPU work but asks the miner for a random old transaction. If the miner
>> really stores the entire blockchain he will not have any problem answering
>> to that getdata request, whereas a botnet would have to ask someone else
>> for it, which could be detected if the response time deviates too much from
>> what has been previously measured (compare it against getdata for the block
>> they advertise). It's not perfect but it allows an estimate of whether it
>> is a chainless miner.
>>
>> Regards,
>> Chris
>> --
>> Christian Decker
>>
>>
>>
>> On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:
>>
>>> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke@dashjr•org> wrote:
>>> > Block times are not accurate enough for that.
>>>
>>> The times in your log are very accurate, assuming your system clock is
>>> remotely accurate.
>>>
>>> --
>>> Jeff Garzik
>>> exMULTI, Inc.
>>> jgarzik@exmulti•com
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
[-- Attachment #2: Type: text/html, Size: 8629 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-25 7:47 99% ` Christian Decker
@ 2012-05-25 13:44 99% ` Alan Reiner
2012-05-25 14:00 99% ` Peter Vessenes
0 siblings, 1 reply; 87+ results
From: Alan Reiner @ 2012-05-25 13:44 UTC (permalink / raw)
To: Christian Decker; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 3150 bytes --]
I like the concept except that it only works if every node connected to the
miner enforces the rule (if it works). Once any one of the nodes forwards
the block, other nodes see it coming from a node that can pass the
challenge.
I don't think any solution based on node queries will succeed, especially
if it requires spontaneous super-majority-of-nodes acceptance. I think
it's gotta be based on the block itself and each nodes' own info.
If you could spontaneously get all miners to agree not to build off of
anti-social blocks (however that is defined) , it would have a chance of
making a difference, but individual miners would have an advantage
building off the antisocial block because they only need to produce one to
create the longest chain (and collect reward) while the miners following
the rules need two blocks.
--Sent from my overpriced smartphone
On May 25, 2012 3:48 AM, "Christian Decker" <decker.christian@gmail•com>
wrote:
> How about a simple proof of work test? This one though does not ask for
> CPU work but asks the miner for a random old transaction. If the miner
> really stores the entire blockchain he will not have any problem answering
> to that getdata request, whereas a botnet would have to ask someone else
> for it, which could be detected if the response time deviates too much from
> what has been previously measured (compare it against getdata for the block
> they advertise). It's not perfect but it allows an estimate of whether it
> is a chainless miner.
>
> Regards,
> Chris
> --
> Christian Decker
>
>
>
> On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:
>
>> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke@dashjr•org> wrote:
>> > Block times are not accurate enough for that.
>>
>> The times in your log are very accurate, assuming your system clock is
>> remotely accurate.
>>
>> --
>> Jeff Garzik
>> exMULTI, Inc.
>> jgarzik@exmulti•com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 4466 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-25 1:17 99% ` Jeff Garzik
@ 2012-05-25 7:47 99% ` Christian Decker
2012-05-25 13:44 99% ` Alan Reiner
0 siblings, 1 reply; 87+ results
From: Christian Decker @ 2012-05-25 7:47 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]
How about a simple proof of work test? This one though does not ask for CPU
work but asks the miner for a random old transaction. If the miner really
stores the entire blockchain he will not have any problem answering to that
getdata request, whereas a botnet would have to ask someone else for it,
which could be detected if the response time deviates too much from what
has been previously measured (compare it against getdata for the block they
advertise). It's not perfect but it allows an estimate of whether it is a
chainless miner.
Regards,
Chris
--
Christian Decker
On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:
> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke@dashjr•org> wrote:
> > Block times are not accurate enough for that.
>
> The times in your log are very accurate, assuming your system clock is
> remotely accurate.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 2344 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-25 0:57 99% ` Luke-Jr
@ 2012-05-25 1:17 99% ` Jeff Garzik
2012-05-25 7:47 99% ` Christian Decker
0 siblings, 1 reply; 87+ results
From: Jeff Garzik @ 2012-05-25 1:17 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke@dashjr•org> wrote:
> Block times are not accurate enough for that.
The times in your log are very accurate, assuming your system clock is
remotely accurate.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-25 0:51 99% ` Jeff Garzik
2012-05-25 0:57 99% ` Luke-Jr
@ 2012-05-25 1:00 99% ` Gregory Maxwell
1 sibling, 0 replies; 87+ results
From: Gregory Maxwell @ 2012-05-25 1:00 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
On Thu, May 24, 2012 at 8:51 PM, Jeff Garzik <jgarzik@exmulti•com> wrote:
> which ones are the lazy miners (> 120 seconds since last block).
It's important to understand the motivations before acting— otherwise
you'll fail to do anything useful.
E.g. if they're empty because some miners want to drive up fees or
fight against the rapidly increasing blockchain size there isn't much
you can do there.
If they're empty because they're mined by botnets which don't have a
local copy of the chain in order to load their victims less (and avoid
central pooling) then you want something like
https://bitcointalk.org/index.php?topic=68396.0
If they're produced by people who think they gain a mining speed
advantage by not including them then then we need education— dropping
their blocks won't help much: we've seen miners go a month with 100%
of their blocks being orphaned.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-25 0:51 99% ` Jeff Garzik
@ 2012-05-25 0:57 99% ` Luke-Jr
2012-05-25 1:17 99% ` Jeff Garzik
2012-05-25 1:00 99% ` Gregory Maxwell
1 sibling, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-25 0:57 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
On Friday, May 25, 2012 12:51:09 AM Jeff Garzik wrote:
> On Thu, May 24, 2012 at 8:45 PM, Luke-Jr <luke@dashjr•org> wrote:
> > On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
> >> Comments? It wouldn't be a problem if these no-TX blocks were not
> >> already getting frequent (1 in 20).
> >
> > FWIW, based on statistics for Eligius's past 100 blocks, it seems 10% (1
> > in 10) of 1-txn blocks is not actually unreasonable. This also means
> > these 1-txn mined blocks are not necessarily harming Bitcoin
> > intentionally. Anyone care to figure out the math for how fast miners
> > need to finish processing transactions to reduce the number of 1txn
> > blocks?
>
> Look at the time since last block, and correlate with the number of
> non-spam TX's in the memory pool at the time. It is obvious which
> ones are quick blocks (<60 seconds since last block, no big deal) and
> which ones are the lazy miners (> 120 seconds since last block).
Block times are not accurate enough for that.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-25 0:45 99% ` Luke-Jr
@ 2012-05-25 0:51 99% ` Jeff Garzik
2012-05-25 0:57 99% ` Luke-Jr
2012-05-25 1:00 99% ` Gregory Maxwell
0 siblings, 2 replies; 87+ results
From: Jeff Garzik @ 2012-05-25 0:51 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
On Thu, May 24, 2012 at 8:45 PM, Luke-Jr <luke@dashjr•org> wrote:
> On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
>> Comments? It wouldn't be a problem if these no-TX blocks were not
>> already getting frequent (1 in 20).
>
> FWIW, based on statistics for Eligius's past 100 blocks, it seems 10% (1 in
> 10) of 1-txn blocks is not actually unreasonable. This also means these 1-txn
> mined blocks are not necessarily harming Bitcoin intentionally. Anyone care to
> figure out the math for how fast miners need to finish processing transactions
> to reduce the number of 1txn blocks?
Look at the time since last block, and correlate with the number of
non-spam TX's in the memory pool at the time. It is obvious which
ones are quick blocks (<60 seconds since last block, no big deal) and
which ones are the lazy miners (> 120 seconds since last block).
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-24 16:33 99% [Bitcoin-development] Punishing empty blocks? Jeff Garzik
` (3 preceding siblings ...)
2012-05-24 20:31 99% ` Luke-Jr
@ 2012-05-25 0:45 99% ` Luke-Jr
2012-05-25 0:51 99% ` Jeff Garzik
2012-05-26 5:03 99% ` Zooko Wilcox-O'Hearn
2012-05-29 15:33 99% ` Gregory Maxwell
6 siblings, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-25 0:45 UTC (permalink / raw)
To: bitcoin-development
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
> Comments? It wouldn't be a problem if these no-TX blocks were not
> already getting frequent (1 in 20).
FWIW, based on statistics for Eligius's past 100 blocks, it seems 10% (1 in
10) of 1-txn blocks is not actually unreasonable. This also means these 1-txn
mined blocks are not necessarily harming Bitcoin intentionally. Anyone care to
figure out the math for how fast miners need to finish processing transactions
to reduce the number of 1txn blocks?
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-24 20:31 99% ` Luke-Jr
@ 2012-05-24 21:00 99% ` Jeff Garzik
0 siblings, 0 replies; 87+ results
From: Jeff Garzik @ 2012-05-24 21:00 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
On Thu, May 24, 2012 at 4:31 PM, Luke-Jr <luke@dashjr•org> wrote:
> These are problematic for legitimate miners:
> 1) The freedom to reject transactions based on fees or spam filters, is
> severely restricted. As mentioned in other replies, this is an important point
> of Bitcoin's design.
> 1b) This punishes miners with superior transaction spam filtering. As with all
> spam filtering, it is often an "arms race" and therefore the filter rules must
> be kept private by the miners, and therefore cannot be disclosed for the
> validating clients to take into consideration.
This is simply not true given current available data, i.e. the current
blockchain and ongoing not-spam transaction rate/pool.
> The argument that these are not rule changes is flawed:
> 1) As of right now, 99% of the network runs a single client. Anything this
> client rejects does de facto become a rule change.
According to your own numbers even, this is not true. 99% of the
network runs a wide variety of rules and versions. Even with a
"critical" security announcement, the percentage of those running the
latest version is not large.
> 2) Even if there were a diverse ecosystem of clients in place, discouragement
> rules that potentially affect legitimate miners significantly mess with the
> odds of finding a block.
> 3) If legitimate miners do not adopt counter-rules to bypass these new
> restrictions, the illegitimate miners are left with an even larger percentage
> of blocks found.
Miners are not the -only- ones that get a say in what is spam, and
what is not. If miners are generating garbage, network users have the
right to veto that garbage.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-24 16:33 99% [Bitcoin-development] Punishing empty blocks? Jeff Garzik
` (2 preceding siblings ...)
2012-05-24 17:27 99% ` Robert McKay
@ 2012-05-24 20:31 99% ` Luke-Jr
2012-05-24 21:00 99% ` Jeff Garzik
2012-05-25 0:45 99% ` Luke-Jr
` (2 subsequent siblings)
6 siblings, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-24 20:31 UTC (permalink / raw)
To: bitcoin-development
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks. Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rather than watch the network for new
> transactions.
>
> Therefore I was wondering what people thought about a client
> implementation change:
>
> - Do not store or relay empty blocks, if time since last block < X
> (where X = 60 minutes, perhaps)
>
> or even stronger,
>
> - Ensure latest block includes at least X percent of mempool
> unconfirmed TXs
These are problematic for legitimate miners:
1) The freedom to reject transactions based on fees or spam filters, is
severely restricted. As mentioned in other replies, this is an important point
of Bitcoin's design.
1b) This punishes miners with superior transaction spam filtering. As with all
spam filtering, it is often an "arms race" and therefore the filter rules must
be kept private by the miners, and therefore cannot be disclosed for the
validating clients to take into consideration.
2) For a few seconds after a new block is received, the new transaction merkle
root(s) are not finished calculating. During this time, most miners are
working on "blank" blocks with the new previousblockhash but no transactions.
If those blocks are ignored, miners are forced to shutdown mining during this
time.
3) As you mentioned, illegitimate miners can easily workaround these
restrictions (even the second one, by flooding the network with their own
transactions). This puts the legitimate miners at a disadvantage in their own
search for valid blocks, unless they also come up with counter-measures
themselves.
The argument that these are not rule changes is flawed:
1) As of right now, 99% of the network runs a single client. Anything this
client rejects does de facto become a rule change.
2) Even if there were a diverse ecosystem of clients in place, discouragement
rules that potentially affect legitimate miners significantly mess with the
odds of finding a block.
3) If legitimate miners do not adopt counter-rules to bypass these new
restrictions, the illegitimate miners are left with an even larger percentage
of blocks found.
To summarize, I believe such a change as proposed would be very harmful to
Bitcoin.
Luke
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-24 17:27 99% ` Robert McKay
@ 2012-05-24 18:16 99% ` Jeff Garzik
0 siblings, 0 replies; 87+ results
From: Jeff Garzik @ 2012-05-24 18:16 UTC (permalink / raw)
To: Robert McKay; +Cc: bitcoin-development
On Thu, May 24, 2012 at 1:27 PM, Robert McKay <robert@mckay•com> wrote:
> If miners wanted to continue mining empty blocks without bothering to
> monitor the Tx pool they would just switch to stuffing the empty blocks
> with a dummy transaction of their own to get round your new rules.
Yes. This was stated in the original email.
> Once the block reward halves in a few months time then receiving
> transaction fees will probably become more important to the miner's
> profit and loss calculations and they'll spend the extra time to
> implement proper transaction processing. I suspect if we do nothing this
> particular issue will go away. Perhaps it could be helped along by
> publishing some example code to make it easier for them.
At current rates it is potentially years before that point is reached
-- years of degraded service for existing users.
> The ability to refuse transactions seems like an important part of the
> game theory of transaction pricing. Miners are supposed to be able to
> jack up transaction costs by declining to process no fee or too low fee
> (in their opinion) transactions.. the counter balance is that they are
> losing money by doing that and leaving more on the table for the next
> miner to score a block.
>
> I expect that in the future there will be other instances when people
> complain that the miners are being 'unfair' and that the rules should be
> changed in some way to lower transaction fees (ie: increase block size).
If you see a rule change, you have misunderstood the proposal.
This is an -implementation- change, which users and miners are free to
accept or reject as part of their choice of software to use in the
bitcoin ecosystem.
As such, miners continue to be free to build upon empty blocks, and
let those blocks become part of a useful chain. You would not simply
/ban/ empty blocks completely, but avoid relaying top-of-chain empty
blocks.
Mining power and network collaborate to choose the best chain at that
point -- perhaps even including those empty blocks. Clients will
continue to follow the longest, strongest chain, even after this
implementation change.
An implementation change is a soft vote of choice by the user, not a
hard requirement on all users.
> I think it should be legitimate not to publish a transaction
> to the p2p network at all.. in the future there will probably be lots of
> networks other than the p2p network.. right now we have the IPv6 network
> and the IPv4 network.. in the future there could be many other protocols
> and perhaps not all transactions will make it back to the old legacy
> ipv4 p2p network or into the mempool of bitcoin nodes on that network..
> but they should still be able to get into the block chain.
See above -- such behavior is perfectly fine.
It should be noted that out of band (OOB) TXs, transited through third
party means outside P2P network, would not cause _empty_ blocks, as
the block chain will continue to have traffic for the foreseeable
future.
OOB TXs are a great idea, too. In a hyperscaled bitcoin future, OOB
TXs might even be the norm.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-24 16:33 99% [Bitcoin-development] Punishing empty blocks? Jeff Garzik
2012-05-24 17:05 99% ` Arthur Britto
2012-05-24 17:13 99% ` Joel Joonatan Kaartinen
@ 2012-05-24 17:27 99% ` Robert McKay
2012-05-24 18:16 99% ` Jeff Garzik
2012-05-24 20:31 99% ` Luke-Jr
` (3 subsequent siblings)
6 siblings, 1 reply; 87+ results
From: Robert McKay @ 2012-05-24 17:27 UTC (permalink / raw)
To: bitcoin-development
On Thu, 24 May 2012 12:33:12 -0400, Jeff Garzik wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks. Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rather than watch the network for new
> transactions.
>
> Therefore I was wondering what people thought about a client
> implementation change:
>
> - Do not store or relay empty blocks, if time since last block <
> X
> (where X = 60 minutes, perhaps)
>
> or even stronger,
>
> - Ensure latest block includes at least X percent of mempool
> unconfirmed TXs
If miners wanted to continue mining empty blocks without bothering to
monitor the Tx pool they would just switch to stuffing the empty blocks
with a dummy transaction of their own to get round your new rules. They
could also spam them to the p2p network so that they end up in the
mempool if that were necessary. This would probably still be slightly
easier than 'doing it properly'.
Once the block reward halves in a few months time then receiving
transaction fees will probably become more important to the miner's
profit and loss calculations and they'll spend the extra time to
implement proper transaction processing. I suspect if we do nothing this
particular issue will go away. Perhaps it could be helped along by
publishing some example code to make it easier for them.
The ability to refuse transactions seems like an important part of the
game theory of transaction pricing. Miners are supposed to be able to
jack up transaction costs by declining to process no fee or too low fee
(in their opinion) transactions.. the counter balance is that they are
losing money by doing that and leaving more on the table for the next
miner to score a block.
I expect that in the future there will be other instances when people
complain that the miners are being 'unfair' and that the rules should be
changed in some way to lower transaction fees (ie: increase block size).
If block sizes are increased ever larger and miners aren't allowed to
refuse to process transactions it will get rid of the financial
motivation for mining and less mining will happen. We should be very
careful when making these kinds of changes.
Setting percentage quotas of stuff in the mempool sounds dangerous..
miners that hear about a block from a rival miner soon enough could
possibly DOS the mempool on the rest of the network to get the block
rejected. I think it should be legitimate not to publish a transaction
to the p2p network at all.. in the future there will probably be lots of
networks other than the p2p network.. right now we have the IPv6 network
and the IPv4 network.. in the future there could be many other protocols
and perhaps not all transactions will make it back to the old legacy
ipv4 p2p network or into the mempool of bitcoin nodes on that network..
but they should still be able to get into the block chain.
Rob
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-24 17:13 99% ` Joel Joonatan Kaartinen
@ 2012-05-24 17:23 99% ` Jeff Garzik
0 siblings, 0 replies; 87+ results
From: Jeff Garzik @ 2012-05-24 17:23 UTC (permalink / raw)
To: Joel Joonatan Kaartinen; +Cc: Bitcoin Development
On Thu, May 24, 2012 at 1:13 PM, Joel Joonatan Kaartinen
<joel.kaartinen@gmail•com> wrote:
> optimization that avoids rechecking transactions that have already been
> verified as valid. Any transactions it doesn't have to verify are from the
> pool, of course :)
Work in this area is already progressing, though it is outside the
scope of this proposal regarding lazy miners and empty blocks.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-24 16:33 99% [Bitcoin-development] Punishing empty blocks? Jeff Garzik
2012-05-24 17:05 99% ` Arthur Britto
@ 2012-05-24 17:13 99% ` Joel Joonatan Kaartinen
2012-05-24 17:23 99% ` Jeff Garzik
2012-05-24 17:27 99% ` Robert McKay
` (4 subsequent siblings)
6 siblings, 1 reply; 87+ results
From: Joel Joonatan Kaartinen @ 2012-05-24 17:13 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]
I think the strong verification would go well if you add it along with an
optimization that avoids rechecking transactions that have already been
verified as valid. Any transactions it doesn't have to verify are from the
pool, of course :)
On Thu, May 24, 2012 at 7:33 PM, Jeff Garzik <jgarzik@exmulti•com> wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks. Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rather than watch the network for new
> transactions.
>
> Therefore I was wondering what people thought about a client
> implementation change:
>
> - Do not store or relay empty blocks, if time since last block < X
> (where X = 60 minutes, perhaps)
>
> or even stronger,
>
> - Ensure latest block includes at least X percent of mempool
> unconfirmed TXs
>
> The former is easier to implement, though there is the danger that
> no-TX miners simply include a statically generated transaction or two.
>
> The latter might be considered problematic, as it might refuse to
> relay quickly found blocks.
>
> Comments? It wouldn't be a problem if these no-TX blocks were not
> already getting frequent (1 in 20).
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 2628 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Punishing empty blocks?
2012-05-24 16:33 99% [Bitcoin-development] Punishing empty blocks? Jeff Garzik
@ 2012-05-24 17:05 99% ` Arthur Britto
2012-05-24 17:13 99% ` Joel Joonatan Kaartinen
` (5 subsequent siblings)
6 siblings, 0 replies; 87+ results
From: Arthur Britto @ 2012-05-24 17:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]
I think you need the stronger change. Otherwise, the mystery miner could
just put in a few transactions to himself to mask his block. His block
would appear to be of some use while not being helpful.
-Arthur
On Thu, May 24, 2012 at 9:33 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks. Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rather than watch the network for new
> transactions.
>
> Therefore I was wondering what people thought about a client
> implementation change:
>
> - Do not store or relay empty blocks, if time since last block < X
> (where X = 60 minutes, perhaps)
>
> or even stronger,
>
> - Ensure latest block includes at least X percent of mempool
> unconfirmed TXs
>
> The former is easier to implement, though there is the danger that
> no-TX miners simply include a statically generated transaction or two.
>
> The latter might be considered problematic, as it might refuse to
> relay quickly found blocks.
>
> Comments? It wouldn't be a problem if these no-TX blocks were not
> already getting frequent (1 in 20).
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 2619 bytes --]
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] Punishing empty blocks?
@ 2012-05-24 16:33 99% Jeff Garzik
2012-05-24 17:05 99% ` Arthur Britto
` (6 more replies)
0 siblings, 7 replies; 87+ results
From: Jeff Garzik @ 2012-05-24 16:33 UTC (permalink / raw)
To: Bitcoin Development
There appears to be some non-trivial mining power devoted to mining
empty blocks. Even with satoshi's key observation -- hash a fixed
80-byte header, not the entire block -- some miners still find it
easier to mine empty blocks, rather than watch the network for new
transactions.
Therefore I was wondering what people thought about a client
implementation change:
- Do not store or relay empty blocks, if time since last block < X
(where X = 60 minutes, perhaps)
or even stronger,
- Ensure latest block includes at least X percent of mempool
unconfirmed TXs
The former is easier to implement, though there is the danger that
no-TX miners simply include a statically generated transaction or two.
The latter might be considered problematic, as it might refuse to
relay quickly found blocks.
Comments? It wouldn't be a problem if these no-TX blocks were not
already getting frequent (1 in 20).
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)
2012-05-16 18:38 99% ` Jeff Garzik
@ 2012-05-16 18:46 99% ` Luke-Jr
0 siblings, 0 replies; 87+ results
From: Luke-Jr @ 2012-05-16 18:46 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
On Wednesday, May 16, 2012 6:38:28 PM Jeff Garzik wrote:
> On Wed, May 16, 2012 at 2:29 PM, Luke-Jr <luke@dashjr•org> wrote:
> > That assumes you already have a connection to the peer in question.
> > As I understand it, the service bits are propagated as part of the
> > address, so you can see at a glance which nodes you want to connect to
> > for some special service. Passing a huge list along might be unwieldy
> > (though it makes sense for protocol changes that don't add new
> > services).
>
> If the peer list becomes too, um, stratified maybe that's a Big Hint
> that said clients should be using another network entirely, and not
> overloading bitcoin's P2P network for wholly unrelated tasks. The
> bitcoin P2P network is not a general message transit network.
>
> Another argument against the proposal, IOW, if you ask me....
No, I meant the inverse. If only a small minority of nodes are stratified,
the clients need some way to figure out which ones, without connecting to
every node.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)
2012-05-16 18:29 99% ` Luke-Jr
@ 2012-05-16 18:38 99% ` Jeff Garzik
2012-05-16 18:46 99% ` Luke-Jr
0 siblings, 1 reply; 87+ results
From: Jeff Garzik @ 2012-05-16 18:38 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
On Wed, May 16, 2012 at 2:29 PM, Luke-Jr <luke@dashjr•org> wrote:
> That assumes you already have a connection to the peer in question.
> As I understand it, the service bits are propagated as part of the address,
> so you can see at a glance which nodes you want to connect to for some
> special service. Passing a huge list along might be unwieldy (though it
> makes sense for protocol changes that don't add new services).
If the peer list becomes too, um, stratified maybe that's a Big Hint
that said clients should be using another network entirely, and not
overloading bitcoin's P2P network for wholly unrelated tasks. The
bitcoin P2P network is not a general message transit network.
Another argument against the proposal, IOW, if you ask me....
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)
2012-05-16 18:18 99% [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes) Jeff Garzik
@ 2012-05-16 18:29 99% ` Luke-Jr
2012-05-16 18:38 99% ` Jeff Garzik
0 siblings, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-16 18:29 UTC (permalink / raw)
To: bitcoin-development
On Wednesday, May 16, 2012 6:18:27 PM Jeff Garzik wrote:
> Instead of further overloading service bits in the version message, or
> altering the version message, let us instead make feature discovery an
> easy, flexible, extensible process.
>
> We can add new commands without impacting older nodes, so let's create
> a new command "get-features" (or pick your name) that returns a list
> of key/value pairs. The key is a string, the value type is determined
> by the key.
That assumes you already have a connection to the peer in question.
As I understand it, the service bits are propagated as part of the address,
so you can see at a glance which nodes you want to connect to for some
special service. Passing a huge list along might be unwieldy (though it
makes sense for protocol changes that don't add new services).
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)
@ 2012-05-16 18:18 99% Jeff Garzik
2012-05-16 18:29 99% ` Luke-Jr
0 siblings, 1 reply; 87+ results
From: Jeff Garzik @ 2012-05-16 18:18 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
On Wed, May 16, 2012 at 12:34 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
> Please check out my proposal,
>
> https://en.bitcoin.it/wiki/BIP_0033
>
> I want to use the existing Bitcoin protocol to provide this functionality in order to maintain compatibility. This proposal does not affect current Bitcoin clients, but allows the parallel system to operate alongside and sometimes intersect with the main Bitcoin network in a positive way.
I do not object to the concept, but the discovery process should be
improved. Even venerable SMTP has a better, more flexible
capabilities discovery process.
Instead of further overloading service bits in the version message, or
altering the version message, let us instead make feature discovery an
easy, flexible, extensible process.
We can add new commands without impacting older nodes, so let's create
a new command "get-features" (or pick your name) that returns a list
of key/value pairs. The key is a string, the value type is determined
by the key.
Standard behavior of clients would be to send "get-features" after
seeing remote version info, as part of the initial connection
handshake.
In any case, the basic point is to move FAR away from fighting over a
limited, inflexible resource (service bits in "version" msg) to
something string-based and easily extensible.
I can create this as BIP 34, if people wish.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] BIP 33 - Stratized Nodes
2012-05-16 16:46 99% ` Mike Hearn
2012-05-16 17:32 99% ` Amir Taaki
@ 2012-05-16 18:22 99% ` Jeff Garzik
1 sibling, 0 replies; 87+ results
From: Jeff Garzik @ 2012-05-16 18:22 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
On Wed, May 16, 2012 at 12:46 PM, Mike Hearn <mike@plan99•net> wrote:
> Thanks for getting this started.
>
> With regards to the specific proposal, I don't believe it's the best option
> and still plan to eventually implement the original design outlined more
> than a year ago in this thread:
>
> https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
>
> Namely that you use a new protocol command to set a Bloom filter on a
> connection. Only transactions matching that filter will appear in relayed
> inventory. Blocks that are requested will arrive as a header plus
> transaction/merkle branch pairs. Clients are expected to maintain and track
> the block chain as per usual, but instead of downloading the whole chain and
> then dropping the irrelevant transactions, that filtering is done server
> side. By strengthening or weakening the Bloom filters you can choose your
> preferred point on the privacy/bandwidth-usage spectrum. It is a fairly
> simple change to the Satoshi and BitcoinJ codebases but still allows clients
> to gain confidence in their balance by examining the chain, and this is true
> even in the presence of a hijacked internet connection (you can't trust
> pending transactions that way, but you can still trust confirmed
> transactions).
Makes sense.
In an idealized model of a client as a set of private keys, they will
want to (a) notice new activity on these keys, (b) notice increased
confidence on existing transactions with those keys [confirmations],
and (c) be able to submit to the network new transactions. Your
proposal covers those bases, I believe.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] BIP 33 - Stratized Nodes
2012-05-16 16:49 99% ` Peter Vessenes
@ 2012-05-16 17:37 99% ` Amir Taaki
0 siblings, 0 replies; 87+ results
From: Amir Taaki @ 2012-05-16 17:37 UTC (permalink / raw)
To: bitcoin-development
> 1) This is cool and useful (but see 3)
> 2) This is significantly less secure than validating an entire blockchain; it's certainly worth working out some use cases here in more detail than just a sample conversation. More on this below
> 3) What about discovery? Will a client now have the chance to look for NODE_STRATIZED clients on IRC? How do you envision a stratized server decides which transactions to relay/store? Or is it just a caching layer in front of a high quality blockchain service? If it is just a caching service, the question of cache hits / misses is an interesting one as well.
Stratized nodes do discovery as normal. Service nodes are explicitly chosen like IRC servers are for IRC clients.
> 4) What are the economic motivations to run a stratized server? Other than cheating people of course.
None. Same as BitTorrent super-nodes, Tor relays or email servers. People don't need economic motivation for everything.
> 5) Seems like a 'send me everything for this source address' is going to save a lot of roundtrip conversations for what I imagine the most common request will be.
That's a bad idea. I prefer to keep each request minimal to prevent resource starvation and simplify the protocol (while shifting the onus onto the client). Also the history can be resolved with multiple services while the data is being downloaded and sorted.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] BIP 33 - Stratized Nodes
2012-05-16 16:46 99% ` Mike Hearn
@ 2012-05-16 17:32 99% ` Amir Taaki
2012-05-16 18:22 99% ` Jeff Garzik
1 sibling, 0 replies; 87+ results
From: Amir Taaki @ 2012-05-16 17:32 UTC (permalink / raw)
To: bitcoin-development
A bloom filter seems like an interesting idea. However this proposal is concerned mainly with the initialisation stage, whereas this bloom filter is for pushed blocks.
This proposal still updates new transactions and blocks in the same way, and it's not inconceivable to later use a bloom filter to make that part more efficient (although it's questionable if pushing this server side would be a good idea as it would now need to track an additional client state).
________________________________
From: Mike Hearn <mike@plan99•net>
To: Amir Taaki <zgenjix@yahoo•com>
Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
Sent: Wednesday, May 16, 2012 5:46 PM
Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes
Thanks for getting this started.
With regards to the specific proposal, I don't believe it's the best option and still plan to eventually implement the original design outlined more than a year ago in this thread:
https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
Namely that you use a new protocol command to set a Bloom filter on a connection. Only transactions matching that filter will appear in relayed inventory. Blocks that are requested will arrive as a header plus transaction/merkle branch pairs. Clients are expected to maintain and track the block chain as per usual, but instead of downloading the whole chain and then dropping the irrelevant transactions, that filtering is done server side. By strengthening or weakening the Bloom filters you can choose your preferred point on the privacy/bandwidth-usage spectrum. It is a fairly simple change to the Satoshi and BitcoinJ codebases but still allows clients to gain confidence in their balance by examining the chain, and this is true even in the presence of a hijacked internet connection (you can't trust pending transactions that way, but you can still trust confirmed transactions).
The filters would be applied to each data block in each script rather than having a specific knowledge of addresses. In this way you can select for things like multisig outputs or outputs which don't use addresses / pubkeys to authenticate.
I could write a BIP for this alternative protocol if somebody else wants to implement it. I was going to wait until I had time to do both BIP and implementation, but I think some simple optimizations to BitcoinJ can keep its performance good enough for the short term.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] BIP 33 - Stratized Nodes
2012-05-16 16:34 99% [Bitcoin-development] BIP 33 - Stratized Nodes Amir Taaki
2012-05-16 16:46 99% ` Mike Hearn
@ 2012-05-16 16:49 99% ` Peter Vessenes
2012-05-16 17:37 99% ` Amir Taaki
1 sibling, 1 reply; 87+ results
From: Peter Vessenes @ 2012-05-16 16:49 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
Thanks for this, Amir.
My initial reactions:
1) This is cool and useful (but see 3)
2) This is significantly less secure than validating an entire blockchain;
it's certainly worth working out some use cases here in more detail than
just a sample conversation. More on this below
3) What about discovery? Will a client now have the chance to look for
NODE_STRATIZED clients on IRC? How do you envision a stratized server
decides which transactions to relay/store? Or is it just a caching layer in
front of a high quality blockchain service? If it is just a caching
service, the question of cache hits / misses is an interesting one as well.
4) What are the economic motivations to run a stratized server? Other than
cheating people of course.
5) Seems like a 'send me everything for this source address' is going to
save a lot of roundtrip conversations for what I imagine the most common
request will be.
Inre: majority agreement on transactions, and even balances, it would be
nice to work out some theoretical security / cost / value calculations for
the following scenarios:
Likely value and cost to someone of subverting / lying about
1) An n-confirmation transaction, n > 0
2) A 0 confirmation transaction
3) A NODE_STRATIZED transaction chain for a client with m connections to
NODE_STRATIZED servers
4) An address balance request for a client with m connections to
NODE_BALANCE_INFO (I made this name up) servers
Peter
[-- Attachment #2: Type: text/html, Size: 1681 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] BIP 33 - Stratized Nodes
2012-05-16 16:34 99% [Bitcoin-development] BIP 33 - Stratized Nodes Amir Taaki
@ 2012-05-16 16:46 99% ` Mike Hearn
2012-05-16 17:32 99% ` Amir Taaki
2012-05-16 18:22 99% ` Jeff Garzik
2012-05-16 16:49 99% ` Peter Vessenes
1 sibling, 2 replies; 87+ results
From: Mike Hearn @ 2012-05-16 16:46 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
Thanks for getting this started.
With regards to the specific proposal, I don't believe it's the best option
and still plan to eventually implement the original design outlined more
than a year ago in this thread:
https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
Namely that you use a new protocol command to set a Bloom filter on a
connection. Only transactions matching that filter will appear in relayed
inventory. Blocks that are requested will arrive as a header plus
transaction/merkle branch pairs. Clients are expected to maintain and track
the block chain as per usual, but instead of downloading the whole chain
and then dropping the irrelevant transactions, that filtering is done
server side. By strengthening or weakening the Bloom filters you can choose
your preferred point on the privacy/bandwidth-usage spectrum. It is a
fairly simple change to the Satoshi and BitcoinJ codebases but still allows
clients to gain confidence in their balance by examining the chain, and
this is true even in the presence of a hijacked internet connection (you
can't trust pending transactions that way, but you can still trust
confirmed transactions).
The filters would be applied to each data block in each script rather than
having a specific knowledge of addresses. In this way you can select for
things like multisig outputs or outputs which don't use addresses / pubkeys
to authenticate.
I could write a BIP for this alternative protocol if somebody else wants to
implement it. I was going to wait until I had time to do both BIP and
implementation, but I think some simple optimizations to BitcoinJ can keep
its performance good enough for the short term.
[-- Attachment #2: Type: text/html, Size: 1910 bytes --]
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] BIP 33 - Stratized Nodes
@ 2012-05-16 16:34 99% Amir Taaki
2012-05-16 16:46 99% ` Mike Hearn
2012-05-16 16:49 99% ` Peter Vessenes
0 siblings, 2 replies; 87+ results
From: Amir Taaki @ 2012-05-16 16:34 UTC (permalink / raw)
To: bitcoin-development
Hi,
Please check out my proposal,
https://en.bitcoin.it/wiki/BIP_0033
I want to use the existing Bitcoin protocol to provide this functionality in order to maintain compatibility. This proposal does not affect current Bitcoin clients, but allows the parallel system to operate alongside and sometimes intersect with the main Bitcoin network in a positive way.
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] Stackoverflow with latest git head
@ 2012-05-12 7:00 99% Peter Todd
0 siblings, 0 replies; 87+ results
From: Peter Todd @ 2012-05-12 7:00 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
#220 0x00007ffff5d021a6 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib/libQtGui.so.4
(gdb)
#221 0x00007ffff5d086fb in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/libQtGui.so.4
(gdb)
#222 0x00007ffff582f06c in QCoreApplication::notifyInternal(QObject*,
QEvent*) () from /usr/lib/libQtCore.so.4
(gdb)
#223 0x00007ffff5d4da05 in QWidget::setToolTip(QString const&) () from
/usr/lib/libQtGui.so.4
(gdb)
#224 0x0000000000589e43 in
GUIUtil::ToolTipToRichTextFilter::eventFilter(QObject*, QEvent*) ()
(gdb)
#225 0x00007ffff582e54b in
QCoreApplicationPrivate::sendThroughApplicationEventFilters(QObject*,
QEvent*) () from /usr/lib/libQtCore.so.4
(gdb)
#226 0x00007ffff5d021a6 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib/libQtGui.so.4
(gdb)
The above is the loop that bitcoin seems to be stuck in. I ran
git-bisect and it looks like the first bad commit is
3793fa09ff920fc720dfad3738f105d2c9563662
My QT version is 4.6.2
Give me a shout if there are any other tests you want me to run.
--
http://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] IPv6 bitcoin support now live
@ 2012-05-12 1:42 99% Jeff Garzik
[not found] ` <CAPg+sBgf0uS9ua9kGcLraq_vQ+vx7o7XHfEdVRAEbYSG_6ibdQ@mail.gmail.com>
0 siblings, 1 reply; 87+ results
From: Jeff Garzik @ 2012-05-12 1:42 UTC (permalink / raw)
To: Bitcoin Development
sipa just pushed out IPv6 support to bitcoin/bitcoin.git, and we have
a few IPv6 nodes live on the network already.
If you have IPv6, please pull the latest bitcoin and test!
(and if you do not yet have IPv6, visit https://www.sixxs.net/ and get some)
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] Please review: getmemorypool (BIP 22) revision
@ 2012-05-11 15:33 99% Luke-Jr
0 siblings, 0 replies; 87+ results
From: Luke-Jr @ 2012-05-11 15:33 UTC (permalink / raw)
To: bitcoin-development; +Cc: Inaba, kinlo
I have finally got around to revising the BIP 22 draft, and would appreciate
further review: https://en.bitcoin.it/wiki/BIP_0022
I believe this revision addresses Geir's last email in March, as well as some
practical problems some pools recently came across.
To summarize the changes from the last revision in March:
- The submitblock(<data>, <params>) method is renamed to getmemorypool
- Requesting a job now uses getmemorypool(<params>) to provide client
capabilities and other information to the server
- Longpolls use a parameter in the getmemorypool request, not necessarily a
separate URI
- The client can inform the server of its own size and sigop requirements in
advance
- The client can request detailed transaction data from the server, necessary
to sanely manipulate the transactions included in the final block without
discarding fees or making the block invalid due to not having enough
- With both client and server support, blocks can be proposed before wasting
time mining them, to ensure they are otherwise valid
- Servers can be arranged into single logical services, with failover and load
balancing (similar to the getwork X-Host-List and X-Switch-To extensions).
You can see the full diff here:
https://en.bitcoin.it/w/?title=BIP_0022&action=historysubmit&diff=26408&oldid=25544
Luke
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] block difficulty - inherently stable or inherently unstable?
@ 2012-05-08 14:02 99% Rebroad (sourceforge)
0 siblings, 0 replies; 87+ results
From: Rebroad (sourceforge) @ 2012-05-08 14:02 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
I was just thinking about the way block difficulty is calculated, and how
people may (in future) decide whether to mine or not.
Is it possible that when the difficulty is low, many will decide to mine,
producing blocks every 3 or 5 minutes, and then in 1 week, bitcoin will
increase the difficulty, and many will decide it is no longer cost
effective, stop mining, and find blocks are being produced every 30 minutes
for the next 6 weeks, before the returning to a previous difficulty where
people decide to mine again, etc, etc.
Seems reasonably possible in my mind, and I'm wondering if the stability so
far has been purely due to people mining without thinking too much about
the immediate cost-effectiveness (or mining by zombie-farms).
Thoughts, anyone?
Ed
[-- Attachment #2: Type: text/html, Size: 871 bytes --]
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] Bitcoin intro and talks in Berlin (11th May at 20:00)
@ 2012-05-08 12:24 99% Amir Taaki
0 siblings, 0 replies; 87+ results
From: Amir Taaki @ 2012-05-08 12:24 UTC (permalink / raw)
To: bitcoin-development
c-base is holding a day on p2p technologies on the 11th. From 20:00 will be the section on Bitcoin.
If you want to do a talk, then email me (genjix@riseup•net) and I’ll add you to the schedule.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] Potential network split when individual tx used as coinbase?
2012-05-05 8:31 99% ` [Bitcoin-development] Potential network split when individual tx used as coinbase? Rebroad (sourceforge)
@ 2012-05-05 11:40 99% ` Pieter Wuille
0 siblings, 0 replies; 87+ results
From: Pieter Wuille @ 2012-05-05 11:40 UTC (permalink / raw)
To: Rebroad (sourceforge); +Cc: bitcoin-development
On Sat, May 05, 2012 at 09:31:39AM +0100, Rebroad (sourceforge) wrote:
> Hi,
> >
> >
> Looking at:
> https://github.com/bitcoin/bitcoin/commit/3e52aaf2121d597ab1ed012b65e37f9cb5f2754e#src/main.cpp-P52
>
> It appears that 8 months ago the code was changed to DoS(100) nodes sending
> on txs that use individual txs as the coinbase. Does this mean txs that are
> 0 confirmed?
>
> Or have I misread the code?
I think so, see my comment there.
--
Pieter
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] free tx rate limiter potentially causes more traffic not less?
@ 2012-05-05 8:37 99% Rebroad (sourceforge)
0 siblings, 0 replies; 87+ results
From: Rebroad (sourceforge) @ 2012-05-05 8:37 UTC (permalink / raw)
To: Rebroad (sourceforge); +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
I recently was dabbling with AskFor() and changing the time waited from 2
minutes to 10 seconds (I think perhaps this value may change in future
versions when "network tuning" is implemented).
I noticed that, when used with the -limitfreerelay option that is causes
significant increase in traffic between peers. This is because the tx gets
asked for (from all connected peers usually), but AlwaysHave never becomes
true as it's never stored, always rejected, so it effectively getdatas the
transaction from every single connected peer.
Would it perhaps be better to set up a memory pool for rejected txs and
blocks (perhaps keeping only the hash) so that these rejected items can
continue being ignored?
I hope these observations are ok - I consider myself at the "trying to
understand the code/protocol/algorithm" stage so might sometimes make false
assumptions of what the code intends to do.
Ed
[-- Attachment #2: Type: text/html, Size: 1030 bytes --]
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] Potential network split when individual tx used as coinbase?
[not found] <CAFBxzADBoEU9ncCxsHg7_tMz_WmAnhDrh_m8kWw4Nb5FykjfEg@mail.gmail.com>
@ 2012-05-05 8:31 99% ` Rebroad (sourceforge)
2012-05-05 11:40 99% ` Pieter Wuille
0 siblings, 1 reply; 87+ results
From: Rebroad (sourceforge) @ 2012-05-05 8:31 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
Hi,
>
>
Looking at:
https://github.com/bitcoin/bitcoin/commit/3e52aaf2121d597ab1ed012b65e37f9cb5f2754e#src/main.cpp-P52
It appears that 8 months ago the code was changed to DoS(100) nodes sending
on txs that use individual txs as the coinbase. Does this mean txs that are
0 confirmed?
If so, then, is this a risk of a network split, as I'm sure I've read about
services popping up using bitcoin that are specifically allowing 0
confirmed transactions, and therefore there must be peers around that
accept these.
Or have I misread the code?
Cheers,
Ed
PS. Would a BIP have been applicable for the above-mentioned change?
[-- Attachment #2: Type: text/html, Size: 1047 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] URI Handling in Bitcoin-Qt
2012-05-03 5:46 99% ` Wladimir
@ 2012-05-04 0:54 99% ` Alan Reiner
0 siblings, 0 replies; 87+ results
From: Alan Reiner @ 2012-05-04 0:54 UTC (permalink / raw)
To: Wladimir; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]
On 05/03/2012 01:46 AM, Wladimir wrote:
>
> Label is a label for the destination address, message is a freeform
> message describing the transaction.
>
> I don't think the message is currently stored in the Satoshi client.
> That feature is somewhere on our way-too-long issue and todo list.
>
> But I understand that you want to add transaction meta-data fields
> such as contact information, bought items, item prices?
>
>
I don't want to add fields to the URI-spec, I just want to add them /to
the client/. To me, it is ideal to have separate strings for labeling
/addresses/ vs labeling /transactions/ -- i.e. different strings would
show up in the address book (owner info) than what shows up in the
transaction history (purchase info). I say it's ideal because that
concept seems to fit perfectly with availability of "label=" and
"message=" fields in BIP 21, but it won't actually work if Bitcoin-Qt
won't/can't do it that way.
For now, it seems that I should count on all important information being
in the /label/ field, since users creating URLs would have to assume
anything in the /message/ field will not be saved. Though I imagine the
message data will be /displayed/ after the URI is clicked, just not saved.
To expand the concept slightly further, it might make sense in the
future for users to populate the /message/ and /label /fields with lots
of data, using newlines. The first line would be used as a summary and
displayed in the address book and ledger. The extra lines would all be
displayed when the user opens up a details window. All of it would be
automatically generated by the merchant, and the purchaser would end up
with detailed documentation on every purchase they've made for zero effort.
-Alan
[-- Attachment #2: Type: text/html, Size: 2515 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-03 9:53 99% ` Andreas Schildbach
@ 2012-05-03 10:25 99% ` Jorge Timón
0 siblings, 0 replies; 87+ results
From: Jorge Timón @ 2012-05-03 10:25 UTC (permalink / raw)
To: Andreas Schildbach; +Cc: bitcoin-development
Maybe he didn't configured them well or didn't tried the right ones.
He said that on the freicoin forum:
http://www.freicoin.org/mobile-app-t28.html
Back to topic...
What do you think about including some smartphone clients in the list?
On 5/3/12, Andreas Schildbach <andreas@schildbach•de> wrote:
> On 05/03/2012 11:24 AM, Jorge Timón wrote:
>> On 5/3/12, Andreas Schildbach <andreas@schildbach•de> wrote:
>>> Can we add Bitcoin Wallet?
>>
>> Someone said to me that the cell phone apps they had tried were still
>> too slow. I'm still using an old phone so I didn't know well what to
>> answer him.
>
> I never measured exactly, but Bitcoin Wallet takes about an hour to
> update its blockchain initially on good WLAN (lightweight approach,
> headers only).
>
> After that, Bitcoin Wallet is just as fast as any other client.
>
> The advantage of that approach is that you are not dependent on any
> server (like Spinner or Electrum). Essentially you're carrying the
> blockchain in your pocket.
>
> Cheers,
>
> Andreas
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Timón
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-03 9:24 99% ` Jorge Timón
@ 2012-05-03 9:53 99% ` Andreas Schildbach
2012-05-03 10:25 99% ` Jorge Timón
0 siblings, 1 reply; 87+ results
From: Andreas Schildbach @ 2012-05-03 9:53 UTC (permalink / raw)
To: bitcoin-development
On 05/03/2012 11:24 AM, Jorge Timón wrote:
> On 5/3/12, Andreas Schildbach <andreas@schildbach•de> wrote:
>> Can we add Bitcoin Wallet?
>
> Someone said to me that the cell phone apps they had tried were still
> too slow. I'm still using an old phone so I didn't know well what to
> answer him.
I never measured exactly, but Bitcoin Wallet takes about an hour to
update its blockchain initially on good WLAN (lightweight approach,
headers only).
After that, Bitcoin Wallet is just as fast as any other client.
The advantage of that approach is that you are not dependent on any
server (like Spinner or Electrum). Essentially you're carrying the
blockchain in your pocket.
Cheers,
Andreas
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-03 7:28 99% ` Andreas Schildbach
@ 2012-05-03 9:24 99% ` Jorge Timón
2012-05-03 9:53 99% ` Andreas Schildbach
0 siblings, 1 reply; 87+ results
From: Jorge Timón @ 2012-05-03 9:24 UTC (permalink / raw)
Cc: bitcoin-development
On 5/3/12, Andreas Schildbach <andreas@schildbach•de> wrote:
> Can we add Bitcoin Wallet?
Someone said to me that the cell phone apps they had tried were still
too slow. I'm still using an old phone so I didn't know well what to
answer him. I recomended him bitcoin wallet and bitcoin spinner, but I
warned him that I haven't really used them.
It would be nice to also have a list with smartphone clients near the
list that is being prepared.
--
Jorge Timón
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 18:29 99% ` Jeff Garzik
2012-05-02 19:25 99% ` Amir Taaki
@ 2012-05-03 9:06 99% ` grarpamp
1 sibling, 0 replies; 87+ results
From: grarpamp @ 2012-05-03 9:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
> "Reply-To" Munging Considered Harmful
> http://www.unicom.com/pw/reply-to-harmful.html
Ok, ok. but only because this reminds me of the
top-posting and formatting advice page that
I can't seem to find right now.
But I'm not munging what my client decides to
put in to/cc on a g reply either :)
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 13:22 99% ` Mike Hearn
` (3 preceding siblings ...)
2012-05-02 16:53 99% ` grarpamp
@ 2012-05-03 7:28 99% ` Andreas Schildbach
2012-05-03 9:24 99% ` Jorge Timón
4 siblings, 1 reply; 87+ results
From: Andreas Schildbach @ 2012-05-03 7:28 UTC (permalink / raw)
To: bitcoin-development
On 05/02/2012 03:22 PM, Mike Hearn wrote:
> We're debating the descriptions on the thread. I provided rewritten
> descriptions that try and keep with the "theme per client" goal, whilst
> being less technical.
Can we add Bitcoin Wallet? I'm not very good at writing descriptions, so
I would just add this for starters:
--
Bitcoin Wallet is a standalone wallet for Android devices. Its primary
focus is ease of use and being independant of central network components
(servers). It supports initiating transactions via QR code, Bitcoin
URIs or near-field communication (NFC). It has a useful currency
conversion calculator.
Platforms: Android
Market: https://play.google.com/store/apps/details?id=de.schildbach.wallet
Project: http://code.google.com/p/bitcoin-wallet/
--
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] URI Handling in Bitcoin-Qt
2012-05-03 4:28 99% [Bitcoin-development] URI Handling in Bitcoin-Qt Alan Reiner
2012-05-03 5:46 99% ` Wladimir
@ 2012-05-03 7:16 99% ` Andreas Schildbach
1 sibling, 0 replies; 87+ results
From: Andreas Schildbach @ 2012-05-03 7:16 UTC (permalink / raw)
To: bitcoin-development
On 05/03/2012 06:28 AM, Alan Reiner wrote:
> *(3) *How are the other clients implementing this? Do you make any
> distinction between "label" and "message"?
Bitcoin Wallet for Android currently ignores both fields. At least
temporarly displaying the transaction message is on my short-term todo list.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] URI Handling in Bitcoin-Qt
2012-05-03 4:28 99% [Bitcoin-development] URI Handling in Bitcoin-Qt Alan Reiner
@ 2012-05-03 5:46 99% ` Wladimir
2012-05-04 0:54 99% ` Alan Reiner
2012-05-03 7:16 99% ` Andreas Schildbach
1 sibling, 1 reply; 87+ results
From: Wladimir @ 2012-05-03 5:46 UTC (permalink / raw)
To: Alan Reiner; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]
On Thu, May 3, 2012 at 6:28 AM, Alan Reiner <etotheipi@gmail•com> wrote:
> **
> *(1) *What is the status & plans for supporting "bitcoin:" URIs in the
> Satoshi client? My understanding is that it currently creates URIs, but
> does *not* register itself with the OS to handle such links. Is this
> accurate? This seems like a very high-value feature, and I'd recommend
> that we consider it a priority -- I can't think of any other upgrade that
> can improve usability so dramatically on the desktop.
>
It is already implemented for Linux (Gnome) and Windows, but there is an
issue with boost::ipc that crashed bitcoin at startup on windows, so it's
temporarily disabled on Windows.
> *(2) *I need to understand better what the intentions were behind
> "label=" and "message=". The way I understand it is that Bitcoin-Qt uses
> and stores only address-labels, and no other transactional info is stored
> in the wallet. As such, the "message=" field would be displayed to the
> user when a "bitcoin:" link is clicked, but that message wouldn't be saved
> anywhere.
>
Label is a label for the destination address, message is a freeform message
describing the transaction.
I don't think the message is currently stored in the Satoshi client. That
feature is somewhere on our way-too-long issue and todo list.
But I understand that you want to add transaction meta-data fields such as
contact information, bought items, item prices?
Wladimir
[-- Attachment #2: Type: text/html, Size: 2195 bytes --]
^ permalink raw reply [relevance 99%]
* [Bitcoin-development] URI Handling in Bitcoin-Qt
@ 2012-05-03 4:28 99% Alan Reiner
2012-05-03 5:46 99% ` Wladimir
2012-05-03 7:16 99% ` Andreas Schildbach
0 siblings, 2 replies; 87+ results
From: Alan Reiner @ 2012-05-03 4:28 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]
I want to follow up on BIP 21 (URI scheme), which I have recently
implemented in Armory and I have become a huge fan of it. But I've got
a couple gripes:
*(1) *What is the status & plans for supporting "bitcoin:" URIs in the
Satoshi client? My understanding is that it currently creates URIs, but
does *not* register itself with the OS to handle such links. Is this
accurate? This seems like a very high-value feature, and I'd recommend
that we consider it a priority -- I can't think of any other upgrade
that can improve usability so dramatically on the desktop.
After implementing it all in Armory, I wrote up a walk-thru
<https://bitcointalk.org/index.php?topic=79010.msg879804#msg879804>
recounting how I did the OS-registration in Windows and gnome-based *nix
systems. Perhaps it can give the Bitcoin-Qt devs a jumpstart on getting
it implemented. (and then I can get feedback about doing for generic
Linux and Mac/OSX)
*(2) *I need to understand better what the intentions were behind
"label=" and "message=". The way I understand it is that Bitcoin-Qt
uses and stores only address-labels, and no other transactional info is
stored in the wallet. As such, the "message=" field would be displayed
to the user when a "bitcoin:" link is clicked, but that message wouldn't
be saved anywhere.
However, I think, especially if a new wallet format is in the works,
that both should be supported: "Address Labels" *and *"Transaction
Labels". The real difference is that merchants can include things
Order#, purchase information, etc, in the "message" field, and then put
only their business name in the "label" field. This means that when the
user is looking at their address book, they see just the owners of the
addresses. When they look at the transaction ledger/history, they see a
full list of everything they purchased, prices, contact info, etc. The
distinction is much more important for persistent addresses, but still
important.
This is exactly how I did it in Armory, but if Bitcoin-Qt won't do it
that way, I should be promoting all important information be jammed into
the "label" field.
*(3) *How are the other clients implementing this? Do you make any
distinction between "label" and "message"?
-Alan
[-- Attachment #2: Type: text/html, Size: 2835 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
@ 2012-05-02 23:04 99% ` Jeff Garzik
1 sibling, 0 replies; 87+ results
From: Jeff Garzik @ 2012-05-02 23:04 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
> Check it :) https://github.com/bitcoin/bitcoin.org/pull/34
Personally, all this seems far too focused on a centralized website
(bitcoin.org), and presents far too many choices at once to the user.
On bitcoin.org (registered by Satoshi), I would rather see the Satoshi
reference client and perhaps an "other clients" link on the wiki.
Modern websites are working hard to _reduce_ the number of download
links, not _increase_ them. See, e.g.
http://fedoraproject.org/en/get-fedora where a single download choice
is presented, and then an "other options" link is below the great big
download button.
Rather than fighting over what a particular bitcoin.org page should
look like, why not maintain an independently managed
BitcoinClients.org website? Or GetBitcoinClient.org or somesuch.
Solve this problem in a distributed fashion, rather than stuffing it
all onto bitcoin.org. Bitcoin.org, IMO, is the home of the "reference
project" not the entire bitcoin community. Emphasizing that months
ago was why the forum was moved to bitcointalk.org.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
@ 2012-05-02 20:41 99% Jim
0 siblings, 0 replies; 87+ results
From: Jim @ 2012-05-02 20:41 UTC (permalink / raw)
To: bitcoin-development
Hi Amir,
I am fine with the MultiBit description (+ subsequent suggestions like taking the language text out).
Looking forward to seeing it on the bitcoin.org site.
Jim
jim618@fastmail•co.uk
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 20:25 99% ` Luke-Jr
@ 2012-05-02 20:39 99% ` Gary Rowe
0 siblings, 0 replies; 87+ results
From: Gary Rowe @ 2012-05-02 20:39 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
Now that I've seen and read through the forum thread on this, I think I'll
step back and let others get on with it. As Amir notes, we could be "Bike
Shedding" this for years.
On 2 May 2012 21:25, Luke-Jr <luke@dashjr•org> wrote:
> On Wednesday, May 02, 2012 3:34:35 PM Gary Rowe wrote:
> > Bitcoin-Qt
> > * Developed in C
>
> This is far less relevant than license...
>
> > Armory
> > * Requires the entire blockchain
> > * Dependent client of Bitcoin-Qt
>
> Or bitcoind?
>
> > Electrum
> > * Dependent client of Bitcoin-Qt (on server)
>
> Dependent on centralized server, not any particular client
>
> > Bitcoin Wallet (Android client)
>
> There are multiple Android clients. There is (or was) an OS selection to
> the
> left of the client choices...
>
> On Wednesday, May 02, 2012 3:43:23 PM Alan Reiner wrote:
> > I'm not sure what "designed for occasional use" means. Many users of
> > other clients use them exclusively without touching other clients.
> Armory
> > is designed to be your only wallet (if bitcoind[d/-qt] is running in
> bkgd).
> > I'm sure the other clients are the same.
>
> Pretty sure it means "not running continuously".
>
> > Btw, Armory now has full installers for both Windows and Linux
> > (Ubuntu/Debian), with uninstallers and automatic URI registration
>
> Would be awesome if it took after Spesmilo and managed bitcoind itself in
> the
> background...
>
>
[-- Attachment #2: Type: text/html, Size: 1930 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 19:34 99% ` Gary Rowe
` (2 preceding siblings ...)
2012-05-02 19:43 99% ` Amir Taaki
@ 2012-05-02 20:25 99% ` Luke-Jr
2012-05-02 20:39 99% ` Gary Rowe
3 siblings, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-02 20:25 UTC (permalink / raw)
To: bitcoin-development
On Wednesday, May 02, 2012 3:34:35 PM Gary Rowe wrote:
> Bitcoin-Qt
> * Developed in C
This is far less relevant than license...
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
Or bitcoind?
> Electrum
> * Dependent client of Bitcoin-Qt (on server)
Dependent on centralized server, not any particular client
> Bitcoin Wallet (Android client)
There are multiple Android clients. There is (or was) an OS selection to the
left of the client choices...
On Wednesday, May 02, 2012 3:43:23 PM Alan Reiner wrote:
> I'm not sure what "designed for occasional use" means. Many users of
> other clients use them exclusively without touching other clients. Armory
> is designed to be your only wallet (if bitcoind[d/-qt] is running in bkgd).
> I'm sure the other clients are the same.
Pretty sure it means "not running continuously".
> Btw, Armory now has full installers for both Windows and Linux
> (Ubuntu/Debian), with uninstallers and automatic URI registration
Would be awesome if it took after Spesmilo and managed bitcoind itself in the
background...
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 19:43 99% ` Amir Taaki
2012-05-02 19:46 99% ` Gary Rowe
@ 2012-05-02 19:56 99% ` Alan Reiner
1 sibling, 0 replies; 87+ results
From: Alan Reiner @ 2012-05-02 19:56 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 7113 bytes --]
I think it's perfectly reasonable to debate ordering. I personally don't
think Armory should be up front, because it's not intended for beginners.
How's that for honesty? I don't think anyone is trying to game the system
right now, I think we're trying to come up with a reasonable mechanism for
appealing to new users and get the community more connected. And make
sure everyone understands the system.
On the other hand, perhaps it's better to take the acceptable 80% solution,
and revise it over time...
Amir, I don't have access to the page. I've never been able to view it.
Changing my hosts file doesn't seem to do anything. Can you just forward
me the text? I'll send you an approval email.
On Wed, May 2, 2012 at 3:43 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
> This discussion about ordering is absolutely retarded. Once the list fills
> up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt
> first and the others ordered however. That was nobody can try to game the
> system (it remains unexploitable).
>
> If there are no objections, then I am going to merge this branch. The
> forum thread is divulging into a mess all over the place, and this
> conversation can go on forever discussing the silly fine details:
>
> http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem:
> You suggest creating something new for your hackerspace, like a
> bikeshed. But now all anyone will discuss is its colour. No bikeshed
> will be built.
>
> Armory & MultiBit, are you OK with that description? I will check with
> ThomasV about Electrum.
>
>
> ________________________________
> From: Gary Rowe <g.rowe@froot•co.uk>
> To: "bitcoin-development@lists•sourceforge.net" <
> bitcoin-development@lists•sourceforge.net>
> Sent: Wednesday, May 2, 2012 8:34 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
>
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote:
>
> This is like the most annoying thing about email. Often with group emails,
> we'll be having a conversation then someone will click reply instead of
> group reply and the convo will go on for a while. Eventually I'll realise
> the persons are missing and add them back in.
> >
> >On Yahoo mail (which I use for spam/mailing lists), to do reply all
> involves clicking a tab, scrolling down and clicking Reply All. Normally I
> instead go through the steps of reply, delete To, re-enter bitco... select
> drop down, click send.
> >
> >Anyone know how to make reply all the default in mutt? And how can I
> exclude it from re-including my own email when I do a group reply so I
> don't get the same email again.
> >
> >
> >
> >
> >----- Original Message -----
> >From: Jeff Garzik <jgarzik@exmulti•com>
> >To: grarpamp <grarpamp@gmail•com>
> >Cc: bitcoin-development@lists•sourceforge.net
> >Sent: Wednesday, May 2, 2012 7:29 PM
> >Subject: Re: [Bitcoin-development] new bitcoin.org clients page
> >
> >
> >On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
> >>> Try "Reply to All"
> >>
> >> That puts the sender in 'to' and list in 'cc',
> >> which dupes to the sender and eventually
> >> blows out the to and cc lines as everyone
> >> chimes in and doesn't trim. 'reply to' solves
> >> most of that. assuming the list sw can do it.
> >
> >"Reply-To" Munging Considered Harmful
> >http://www.unicom.com/pw/reply-to-harmful.html
> >
> >
> >
> >--
> >Jeff Garzik
> >exMULTI, Inc.
> >jgarzik@exmulti•com
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development@lists•sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development@lists•sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 10309 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 19:43 99% ` Amir Taaki
@ 2012-05-02 19:46 99% ` Gary Rowe
2012-05-02 19:56 99% ` Alan Reiner
1 sibling, 0 replies; 87+ results
From: Gary Rowe @ 2012-05-02 19:46 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 6500 bytes --]
Alan, apologies about the installer - I was just using your website info to
infer how it all fitted together.
On 2 May 2012 20:43, Amir Taaki <zgenjix@yahoo•com> wrote:
> This discussion about ordering is absolutely retarded. Once the list fills
> up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt
> first and the others ordered however. That was nobody can try to game the
> system (it remains unexploitable).
>
> If there are no objections, then I am going to merge this branch. The
> forum thread is divulging into a mess all over the place, and this
> conversation can go on forever discussing the silly fine details:
>
> http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem:
> You suggest creating something new for your hackerspace, like a
> bikeshed. But now all anyone will discuss is its colour. No bikeshed
> will be built.
>
> Armory & MultiBit, are you OK with that description? I will check with
> ThomasV about Electrum.
>
>
> ________________________________
> From: Gary Rowe <g.rowe@froot•co.uk>
> To: "bitcoin-development@lists•sourceforge.net" <
> bitcoin-development@lists•sourceforge.net>
> Sent: Wednesday, May 2, 2012 8:34 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
>
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote:
>
> This is like the most annoying thing about email. Often with group emails,
> we'll be having a conversation then someone will click reply instead of
> group reply and the convo will go on for a while. Eventually I'll realise
> the persons are missing and add them back in.
> >
> >On Yahoo mail (which I use for spam/mailing lists), to do reply all
> involves clicking a tab, scrolling down and clicking Reply All. Normally I
> instead go through the steps of reply, delete To, re-enter bitco... select
> drop down, click send.
> >
> >Anyone know how to make reply all the default in mutt? And how can I
> exclude it from re-including my own email when I do a group reply so I
> don't get the same email again.
> >
> >
> >
> >
> >----- Original Message -----
> >From: Jeff Garzik <jgarzik@exmulti•com>
> >To: grarpamp <grarpamp@gmail•com>
> >Cc: bitcoin-development@lists•sourceforge.net
> >Sent: Wednesday, May 2, 2012 7:29 PM
> >Subject: Re: [Bitcoin-development] new bitcoin.org clients page
> >
> >
> >On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
> >>> Try "Reply to All"
> >>
> >> That puts the sender in 'to' and list in 'cc',
> >> which dupes to the sender and eventually
> >> blows out the to and cc lines as everyone
> >> chimes in and doesn't trim. 'reply to' solves
> >> most of that. assuming the list sw can do it.
> >
> >"Reply-To" Munging Considered Harmful
> >http://www.unicom.com/pw/reply-to-harmful.html
> >
> >
> >
> >--
> >Jeff Garzik
> >exMULTI, Inc.
> >jgarzik@exmulti•com
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development@lists•sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development@lists•sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 9563 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 19:34 99% ` Gary Rowe
2012-05-02 19:40 99% ` Raphael NICOLLE
2012-05-02 19:43 99% ` Alan Reiner
@ 2012-05-02 19:43 99% ` Amir Taaki
2012-05-02 19:46 99% ` Gary Rowe
2012-05-02 19:56 99% ` Alan Reiner
2012-05-02 20:25 99% ` Luke-Jr
3 siblings, 2 replies; 87+ results
From: Amir Taaki @ 2012-05-02 19:43 UTC (permalink / raw)
To: bitcoin-development
This discussion about ordering is absolutely retarded. Once the list fills up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt first and the others ordered however. That was nobody can try to game the system (it remains unexploitable).
If there are no objections, then I am going to merge this branch. The forum thread is divulging into a mess all over the place, and this conversation can go on forever discussing the silly fine details:
http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem:
You suggest creating something new for your hackerspace, like a
bikeshed. But now all anyone will discuss is its colour. No bikeshed
will be built.
Armory & MultiBit, are you OK with that description? I will check with ThomasV about Electrum.
________________________________
From: Gary Rowe <g.rowe@froot•co.uk>
To: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
Sent: Wednesday, May 2, 2012 8:34 PM
Subject: Re: [Bitcoin-development] new bitcoin.org clients page
How about keeping it simple?
Bitcoin-Qt
* Requires the entire blockchain
* Standalone client
* Designed for continuous operation
* Available for Windows, Mac, Linux with installer
* Developed in C
* Website: https://bitcoin.org
MultiBit
* Requires a reduced blockchain
* Standalone client
* Designed for occasional use
* Available for Windows, Mac, Linux with installer
* Developed in Java
* Website: http://multibit.org
Armory
* Requires the entire blockchain
* Dependent client of Bitcoin-Qt
* Designed for occasional use
* Available for Windows (64-bit only), Mac, Linux (self-build)
* Developed in Python
* Website: http://bitcoinarmory.com/
Electrum
* Requires no blockchain
* Dependent client of Bitcoin-Qt (on server)
* Designed for occasional use
* Available for Windows, Linux (self-build)
* Developed in Python
* Website: http://ecdsa.org/electrum/
Bitcoin Wallet (Android client)
* Requires a reduced blockchain
* Standalone client
* Designed for occasional use on mobile
* Available for Android only
* Developed in Java
* Website: https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote:
This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in.
>
>On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send.
>
>Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again.
>
>
>
>
>----- Original Message -----
>From: Jeff Garzik <jgarzik@exmulti•com>
>To: grarpamp <grarpamp@gmail•com>
>Cc: bitcoin-development@lists•sourceforge.net
>Sent: Wednesday, May 2, 2012 7:29 PM
>Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
>
>On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
>>> Try "Reply to All"
>>
>> That puts the sender in 'to' and list in 'cc',
>> which dupes to the sender and eventually
>> blows out the to and cc lines as everyone
>> chimes in and doesn't trim. 'reply to' solves
>> most of that. assuming the list sw can do it.
>
>"Reply-To" Munging Considered Harmful
>http://www.unicom.com/pw/reply-to-harmful.html
>
>
>
>--
>Jeff Garzik
>exMULTI, Inc.
>jgarzik@exmulti•com
>
>------------------------------------------------------------------------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>------------------------------------------------------------------------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 19:34 99% ` Gary Rowe
2012-05-02 19:40 99% ` Raphael NICOLLE
@ 2012-05-02 19:43 99% ` Alan Reiner
2012-05-02 19:43 99% ` Amir Taaki
2012-05-02 20:25 99% ` Luke-Jr
3 siblings, 0 replies; 87+ results
From: Alan Reiner @ 2012-05-02 19:43 UTC (permalink / raw)
To: Gary Rowe; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 5266 bytes --]
I'm not sure what "designed for occasional use" means. Many users of
other clients use them exclusively without touching other clients. Armory
is designed to be your only wallet (if bitcoind[d/-qt] is running in bkgd).
I'm sure the other clients are the same.
Instead, I think that line would be replaced by a blurb about the target
audience. "Designed for Advanced Users". "Designed for Quick Setup and
Instant usability".
Btw, Armory now has full installers for both Windows and Linux
(Ubuntu/Debian), with uninstallers and automatic URI registration
On Wed, May 2, 2012 at 3:34 PM, Gary Rowe <g.rowe@froot•co.uk> wrote:
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote:
>
>> This is like the most annoying thing about email. Often with group
>> emails, we'll be having a conversation then someone will click reply
>> instead of group reply and the convo will go on for a while. Eventually
>> I'll realise the persons are missing and add them back in.
>>
>> On Yahoo mail (which I use for spam/mailing lists), to do reply all
>> involves clicking a tab, scrolling down and clicking Reply All. Normally I
>> instead go through the steps of reply, delete To, re-enter bitco... select
>> drop down, click send.
>>
>> Anyone know how to make reply all the default in mutt? And how can I
>> exclude it from re-including my own email when I do a group reply so I
>> don't get the same email again.
>>
>>
>>
>> ----- Original Message -----
>> From: Jeff Garzik <jgarzik@exmulti•com>
>> To: grarpamp <grarpamp@gmail•com>
>> Cc: bitcoin-development@lists•sourceforge.net
>> Sent: Wednesday, May 2, 2012 7:29 PM
>> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>>
>> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
>> >> Try "Reply to All"
>> >
>> > That puts the sender in 'to' and list in 'cc',
>> > which dupes to the sender and eventually
>> > blows out the to and cc lines as everyone
>> > chimes in and doesn't trim. 'reply to' solves
>> > most of that. assuming the list sw can do it.
>>
>> "Reply-To" Munging Considered Harmful
>> http://www.unicom.com/pw/reply-to-harmful.html
>>
>>
>>
>> --
>> Jeff Garzik
>> exMULTI, Inc.
>> jgarzik@exmulti•com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 8122 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 19:40 99% ` Raphael NICOLLE
@ 2012-05-02 19:42 99% ` Gary Rowe
0 siblings, 0 replies; 87+ results
From: Gary Rowe @ 2012-05-02 19:42 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4997 bytes --]
Or we could just point everyone here:
http://lovebitcoins.org/getStarted.html
:-)
On 2 May 2012 20:40, Raphael NICOLLE <raphbot@gmail•com> wrote:
> Too technical if you ask me. We want a webpage for the dumbest end-user I
> think.
>
> Java? C? What the heck is this? Blockchain? Qt?
>
> Regards,
> Raphael
>
>
> On 05/02/2012 09:34 PM, Gary Rowe wrote:
>
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote:
>
>> This is like the most annoying thing about email. Often with group
>> emails, we'll be having a conversation then someone will click reply
>> instead of group reply and the convo will go on for a while. Eventually
>> I'll realise the persons are missing and add them back in.
>>
>> On Yahoo mail (which I use for spam/mailing lists), to do reply all
>> involves clicking a tab, scrolling down and clicking Reply All. Normally I
>> instead go through the steps of reply, delete To, re-enter bitco... select
>> drop down, click send.
>>
>> Anyone know how to make reply all the default in mutt? And how can I
>> exclude it from re-including my own email when I do a group reply so I
>> don't get the same email again.
>>
>>
>>
>> ----- Original Message -----
>> From: Jeff Garzik <jgarzik@exmulti•com>
>> To: grarpamp <grarpamp@gmail•com>
>> Cc: bitcoin-development@lists•sourceforge.net
>> Sent: Wednesday, May 2, 2012 7:29 PM
>> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>>
>> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
>> >> Try "Reply to All"
>> >
>> > That puts the sender in 'to' and list in 'cc',
>> > which dupes to the sender and eventually
>> > blows out the to and cc lines as everyone
>> > chimes in and doesn't trim. 'reply to' solves
>> > most of that. assuming the list sw can do it.
>>
>> "Reply-To" Munging Considered Harmful
>> http://www.unicom.com/pw/reply-to-harmful.html
>>
>>
>>
>> --
>> Jeff Garzik
>> exMULTI, Inc.
>> jgarzik@exmulti•com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists•sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 9476 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 19:34 99% ` Gary Rowe
@ 2012-05-02 19:40 99% ` Raphael NICOLLE
2012-05-02 19:42 99% ` Gary Rowe
2012-05-02 19:43 99% ` Alan Reiner
` (2 subsequent siblings)
3 siblings, 1 reply; 87+ results
From: Raphael NICOLLE @ 2012-05-02 19:40 UTC (permalink / raw)
To: Gary Rowe; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 5406 bytes --]
Too technical if you ask me. We want a webpage for the dumbest end-user
I think.
Java? C? What the heck is this? Blockchain? Qt?
Regards,
Raphael
On 05/02/2012 09:34 PM, Gary Rowe wrote:
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
> <https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en>
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com
> <mailto:zgenjix@yahoo•com>> wrote:
>
> This is like the most annoying thing about email. Often with group
> emails, we'll be having a conversation then someone will click
> reply instead of group reply and the convo will go on for a while.
> Eventually I'll realise the persons are missing and add them back in.
>
> On Yahoo mail (which I use for spam/mailing lists), to do reply
> all involves clicking a tab, scrolling down and clicking Reply
> All. Normally I instead go through the steps of reply, delete To,
> re-enter bitco... select drop down, click send.
>
> Anyone know how to make reply all the default in mutt? And how can
> I exclude it from re-including my own email when I do a group
> reply so I don't get the same email again.
>
>
>
> ----- Original Message -----
> From: Jeff Garzik <jgarzik@exmulti•com <mailto:jgarzik@exmulti•com>>
> To: grarpamp <grarpamp@gmail•com <mailto:grarpamp@gmail•com>>
> Cc: bitcoin-development@lists•sourceforge.net
> <mailto:bitcoin-development@lists•sourceforge.net>
> Sent: Wednesday, May 2, 2012 7:29 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org
> <http://bitcoin.org> clients page
>
> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com
> <mailto:grarpamp@gmail•com>> wrote:
> >> Try "Reply to All"
> >
> > That puts the sender in 'to' and list in 'cc',
> > which dupes to the sender and eventually
> > blows out the to and cc lines as everyone
> > chimes in and doesn't trim. 'reply to' solves
> > most of that. assuming the list sw can do it.
>
> "Reply-To" Munging Considered Harmful
> http://www.unicom.com/pw/reply-to-harmful.html
>
>
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com <mailto:jgarzik@exmulti•com>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions
> will include endpoint security, mobile security and the latest in
> malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> <mailto:Bitcoin-development@lists•sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions
> will include endpoint security, mobile security and the latest in
> malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> <mailto:Bitcoin-development@lists•sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 9704 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 19:25 99% ` Amir Taaki
2012-05-02 19:34 99% ` Gary Rowe
@ 2012-05-02 19:35 99% ` Alan Reiner
1 sibling, 0 replies; 87+ results
From: Alan Reiner @ 2012-05-02 19:35 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4548 bytes --]
Oh, like I did 3 hours ago? Gah! I replied directly to grarpamp by
accident. Sorry if this seems out of place now...
I'm all for sorting the clients by "ease of use". We want the smoothest
first experience greeting users new to Bitcoin. I have grand plans of
defaulting Armory to a standard user mode that is standalone, easy to use,
etc. But until then, Armory will remain an a power-users thing, and I'd
prefer not to have Bitcoin n00bs emailing me for support before they know
what Bitcoin-Qt is, or, more likely, installing Armory alone and then
walking away when nothing works.
As someone else mentioned previously, the advanced stuff will generally be
found by advanced users. I think it should still receive exposure through
these means, but not on the top/first row.
I personally think the page should say something like "New to Bitcoin?
Start experiencing Bitcoin with My Phone <menu of phone options>, or My
Desktop <menu of desktop options>" Put the top 3 on each and either a
button for "More Options", or a short list of other options without
screenshots, and just descriptions with links. Ideally, it would be sorted
by popularity, because that's probably the most important metric that ties
together all features into a single number, but we don't have good stats on
that. For now, we settle this by putting Bitcoin-Qt up front, and sort
everything else by how easy it is for users to get started and perceived
popularity and disagreements can be settled by semi-regular rotation.
For now, I don't think ordering is super important. No one here is
threatening lawsuits for improper placement, and the rotation will be good
to keep the main Bitcoin page looking less stagnant, and slowly exposing
repeat visitors to the variety of options available.
--Alan
On Wed, May 2, 2012 at 3:25 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
> This is like the most annoying thing about email. Often with group emails,
> we'll be having a conversation then someone will click reply instead of
> group reply and the convo will go on for a while. Eventually I'll realise
> the persons are missing and add them back in.
>
> On Yahoo mail (which I use for spam/mailing lists), to do reply all
> involves clicking a tab, scrolling down and clicking Reply All. Normally I
> instead go through the steps of reply, delete To, re-enter bitco... select
> drop down, click send.
>
> Anyone know how to make reply all the default in mutt? And how can I
> exclude it from re-including my own email when I do a group reply so I
> don't get the same email again.
>
>
>
> ----- Original Message -----
> From: Jeff Garzik <jgarzik@exmulti•com>
> To: grarpamp <grarpamp@gmail•com>
> Cc: bitcoin-development@lists•sourceforge.net
> Sent: Wednesday, May 2, 2012 7:29 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
> >> Try "Reply to All"
> >
> > That puts the sender in 'to' and list in 'cc',
> > which dupes to the sender and eventually
> > blows out the to and cc lines as everyone
> > chimes in and doesn't trim. 'reply to' solves
> > most of that. assuming the list sw can do it.
>
> "Reply-To" Munging Considered Harmful
> http://www.unicom.com/pw/reply-to-harmful.html
>
>
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 6423 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 19:25 99% ` Amir Taaki
@ 2012-05-02 19:34 99% ` Gary Rowe
2012-05-02 19:40 99% ` Raphael NICOLLE
` (3 more replies)
2012-05-02 19:35 99% ` Alan Reiner
1 sibling, 4 replies; 87+ results
From: Gary Rowe @ 2012-05-02 19:34 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 3869 bytes --]
How about keeping it simple?
Bitcoin-Qt
* Requires the entire blockchain
* Standalone client
* Designed for continuous operation
* Available for Windows, Mac, Linux with installer
* Developed in C
* Website: https://bitcoin.org
MultiBit
* Requires a reduced blockchain
* Standalone client
* Designed for occasional use
* Available for Windows, Mac, Linux with installer
* Developed in Java
* Website: http://multibit.org
Armory
* Requires the entire blockchain
* Dependent client of Bitcoin-Qt
* Designed for occasional use
* Available for Windows (64-bit only), Mac, Linux (self-build)
* Developed in Python
* Website: http://bitcoinarmory.com/
Electrum
* Requires no blockchain
* Dependent client of Bitcoin-Qt (on server)
* Designed for occasional use
* Available for Windows, Linux (self-build)
* Developed in Python
* Website: http://ecdsa.org/electrum/
Bitcoin Wallet (Android client)
* Requires a reduced blockchain
* Standalone client
* Designed for occasional use on mobile
* Available for Android only
* Developed in Java
* Website:
https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote:
> This is like the most annoying thing about email. Often with group emails,
> we'll be having a conversation then someone will click reply instead of
> group reply and the convo will go on for a while. Eventually I'll realise
> the persons are missing and add them back in.
>
> On Yahoo mail (which I use for spam/mailing lists), to do reply all
> involves clicking a tab, scrolling down and clicking Reply All. Normally I
> instead go through the steps of reply, delete To, re-enter bitco... select
> drop down, click send.
>
> Anyone know how to make reply all the default in mutt? And how can I
> exclude it from re-including my own email when I do a group reply so I
> don't get the same email again.
>
>
>
> ----- Original Message -----
> From: Jeff Garzik <jgarzik@exmulti•com>
> To: grarpamp <grarpamp@gmail•com>
> Cc: bitcoin-development@lists•sourceforge.net
> Sent: Wednesday, May 2, 2012 7:29 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
> >> Try "Reply to All"
> >
> > That puts the sender in 'to' and list in 'cc',
> > which dupes to the sender and eventually
> > blows out the to and cc lines as everyone
> > chimes in and doesn't trim. 'reply to' solves
> > most of that. assuming the list sw can do it.
>
> "Reply-To" Munging Considered Harmful
> http://www.unicom.com/pw/reply-to-harmful.html
>
>
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 6014 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 18:29 99% ` Jeff Garzik
@ 2012-05-02 19:25 99% ` Amir Taaki
2012-05-02 19:34 99% ` Gary Rowe
2012-05-02 19:35 99% ` Alan Reiner
2012-05-03 9:06 99% ` grarpamp
1 sibling, 2 replies; 87+ results
From: Amir Taaki @ 2012-05-02 19:25 UTC (permalink / raw)
To: bitcoin-development
This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in.
On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send.
Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again.
----- Original Message -----
From: Jeff Garzik <jgarzik@exmulti•com>
To: grarpamp <grarpamp@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Sent: Wednesday, May 2, 2012 7:29 PM
Subject: Re: [Bitcoin-development] new bitcoin.org clients page
On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
>> Try "Reply to All"
>
> That puts the sender in 'to' and list in 'cc',
> which dupes to the sender and eventually
> blows out the to and cc lines as everyone
> chimes in and doesn't trim. 'reply to' solves
> most of that. assuming the list sw can do it.
"Reply-To" Munging Considered Harmful
http://www.unicom.com/pw/reply-to-harmful.html
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 16:58 99% ` grarpamp
@ 2012-05-02 18:29 99% ` Jeff Garzik
2012-05-02 19:25 99% ` Amir Taaki
2012-05-03 9:06 99% ` grarpamp
0 siblings, 2 replies; 87+ results
From: Jeff Garzik @ 2012-05-02 18:29 UTC (permalink / raw)
To: grarpamp; +Cc: bitcoin-development
On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
>> Try "Reply to All"
>
> That puts the sender in 'to' and list in 'cc',
> which dupes to the sender and eventually
> blows out the to and cc lines as everyone
> chimes in and doesn't trim. 'reply to' solves
> most of that. assuming the list sw can do it.
"Reply-To" Munging Considered Harmful
http://www.unicom.com/pw/reply-to-harmful.html
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 16:30 99% ` Luke-Jr
@ 2012-05-02 16:58 99% ` grarpamp
2012-05-02 18:29 99% ` Jeff Garzik
0 siblings, 1 reply; 87+ results
From: grarpamp @ 2012-05-02 16:58 UTC (permalink / raw)
To: bitcoin-development
> Try "Reply to All"
That puts the sender in 'to' and list in 'cc',
which dupes to the sender and eventually
blows out the to and cc lines as everyone
chimes in and doesn't trim. 'reply to' solves
most of that. assuming the list sw can do it.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 13:22 99% ` Mike Hearn
` (2 preceding siblings ...)
2012-05-02 13:38 99% ` Gregory Maxwell
@ 2012-05-02 16:53 99% ` grarpamp
2012-05-03 7:28 99% ` Andreas Schildbach
4 siblings, 0 replies; 87+ results
From: grarpamp @ 2012-05-02 16:53 UTC (permalink / raw)
To: bitcoin-development
> it's unclear how best to run this page. It's clear we need one though.
> the right path is probably the middle one - have some descriptions that try to be neutral
Do it in two parts...
- overview, history, architecture model, 'whys'.
- agnostic table of features, platforms, stats, protocols, etc
Last, resolve whether or not bitcoin.org is independant.
It cannot be if it does not accept all lib/client under it's umbrella
or has a lib/client project of it's own. You will hit up against this,
just saying.
> Bitcoin-Qt
> This application is a peer-to-peer client that builds the backbone of the Bitcoin network.
No, they all do this and build it, subject to their feature set.
> It is suited for enthusiasts, merchants, miners, developers
No, all implementations are suited for whoever, subject to their feature set.
> and people who want to help support the project.
Which project, the given client or the bitcoin meme.
> People who run Bitcoin-Qt are first class network citizens and have the highest levels of security, privacy and stability.
Right, anyone who doesn't is unwashed rebel scum, running default
installs of xp, on systems with bad ram, who post their home address,
transaction logs, and pink bits on facebook.
> leave it running in the background so other computers can connect to yours.
Again, a feature set / usage model thing.
> MultiBit
> fast and easy to use, even for people with no technical knowledge.
Hey, we're fast, easy and for noobs, me too.
> It has a...
But at least the backing specifics to that claim are stated.
> Armory
> Armory was partly funded by a community donation drive which raised over $4000.
Yeah, every lib/client will have a donation thing on their own site,
and the developers own real world wallet.
> Electrum
> the privacy level is lower than for other clients.
Not sure of this claim. It's all in the usage. Run your own remote,
use anonymizers, etc. Right?
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 16:21 99% ` grarpamp
@ 2012-05-02 16:30 99% ` Luke-Jr
2012-05-02 16:58 99% ` grarpamp
0 siblings, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-02 16:30 UTC (permalink / raw)
To: bitcoin-development
On Wednesday, May 02, 2012 12:21:13 PM grarpamp wrote:
> Can someone also please set the reply-to header
> for these lists. It's really annoying to hit reply and
> not have the list address show up. Thanks :)
Try "Reply to All"
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 13:31 99% ` Luke-Jr
@ 2012-05-02 16:21 99% ` grarpamp
2012-05-02 16:30 99% ` Luke-Jr
0 siblings, 1 reply; 87+ results
From: grarpamp @ 2012-05-02 16:21 UTC (permalink / raw)
To: bitcoin-development
> While Bitcoin-Qt is by far the best client
This is purely subjective. One's best is another's worst.
> These are both things which are particular
> suitable to clear objective enumeration.
Yes, so for the purposes of compiling a list of clients
and libraries, please just stick to a table of features.
On the subjective part, I'm finding the library+client
implementations to be nice, and indeed the future.
Afaik, there are two major pairs of these so far that
should be listed. Ymmv.
Can someone also please set the reply-to header
for these lists. It's really annoying to hit reply and
not have the list address show up. Thanks :)
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 13:42 99% ` Mike Hearn
@ 2012-05-02 15:01 99% ` Alan Reiner
0 siblings, 0 replies; 87+ results
From: Alan Reiner @ 2012-05-02 15:01 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
Btw, I sent updated text to Genjix Armory. I hope that gets included or
reviewed.
And I agree about the $4k donations thing. That's complete immaterial for
this page. Though the rest of the description there is reasonable, and
might even be better than what I sent Genjix.
-Alan
On Wed, May 2, 2012 at 9:42 AM, Mike Hearn <mike@plan99•net> wrote:
> Bitcoin-qt is translated into a pretty broad set of languages (now— I
>> cant tell you how many of them are _good_). Listing language just
>> under multibit makes it sound like a distinguishing characteristic.
>>
>
> Fair enough then, let's take that out.
>
[-- Attachment #2: Type: text/html, Size: 1120 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 13:38 99% ` Gregory Maxwell
@ 2012-05-02 13:42 99% ` Mike Hearn
2012-05-02 15:01 99% ` Alan Reiner
0 siblings, 1 reply; 87+ results
From: Mike Hearn @ 2012-05-02 13:42 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
>
> Bitcoin-qt is translated into a pretty broad set of languages (now— I
> cant tell you how many of them are _good_). Listing language just
> under multibit makes it sound like a distinguishing characteristic.
>
Fair enough then, let's take that out.
[-- Attachment #2: Type: text/html, Size: 435 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 13:22 99% ` Mike Hearn
2012-05-02 13:30 99% ` Gregory Maxwell
2012-05-02 13:31 99% ` Luke-Jr
@ 2012-05-02 13:38 99% ` Gregory Maxwell
2012-05-02 13:42 99% ` Mike Hearn
2012-05-02 16:53 99% ` grarpamp
2012-05-03 7:28 99% ` Andreas Schildbach
4 siblings, 1 reply; 87+ results
From: Gregory Maxwell @ 2012-05-02 13:38 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
> MultiBit supports many languages such as German, Spanish and Greek.
Bitcoin-qt is translated into a pretty broad set of languages (now— I
cant tell you how many of them are _good_). Listing language just
under multibit makes it sound like a distinguishing characteristic.
Might it be useful to add two info lines to each entry: One with the
language codes it supports (ISO 639 please, not flags), and another
line with operating system support? (perhaps not, they're all
win/mac/linux, enh?) These are both things which are particular
suitable to clear objective enumeration.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 13:30 99% ` Gregory Maxwell
@ 2012-05-02 13:32 99% ` Mike Hearn
0 siblings, 0 replies; 87+ results
From: Mike Hearn @ 2012-05-02 13:32 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 247 bytes --]
>
> What computer is the initial start time 24-hours+ now? On normal
> systems initial sync-up now takes a couple hours.
>
OK, I haven't tried a full block chain sync for a while. If it's only a
couple of hours that's great. Let's change that.
[-- Attachment #2: Type: text/html, Size: 439 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 13:22 99% ` Mike Hearn
2012-05-02 13:30 99% ` Gregory Maxwell
@ 2012-05-02 13:31 99% ` Luke-Jr
2012-05-02 16:21 99% ` grarpamp
2012-05-02 13:38 99% ` Gregory Maxwell
` (2 subsequent siblings)
4 siblings, 1 reply; 87+ results
From: Luke-Jr @ 2012-05-02 13:31 UTC (permalink / raw)
To: bitcoin-development
On Wednesday, May 02, 2012 9:22:42 AM Mike Hearn wrote:
> The original software written by Satoshi Nakamoto, the project's founder.
This is just wrong. While Bitcoin-Qt is by far the best client, it is
Wladimir's, not Satoshi's.
> If your computer is low powered or you aren't willing to tolerate a 24-hour+
> initial start time, you should consider other clients.
Isn't this down to only a few hours now?
> Armory was partly funded by a community donation drive which raised over
> $4000.
I don't see this as relevant. Every client has been partly funded by
donations, anyway.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
2012-05-02 13:22 99% ` Mike Hearn
@ 2012-05-02 13:30 99% ` Gregory Maxwell
2012-05-02 13:32 99% ` Mike Hearn
2012-05-02 13:31 99% ` Luke-Jr
` (3 subsequent siblings)
4 siblings, 1 reply; 87+ results
From: Gregory Maxwell @ 2012-05-02 13:30 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
> If your computer is low powered or you aren't willing to tolerate a 24-hour+ initial start time,
What computer is the initial start time 24-hours+ now? On normal
systems initial sync-up now takes a couple hours. It could be slower,
of course, if you have the bad luck to end up with unresponsive peers—
but that will also make the SPV nodes slow.
Better to be conservative I agree, but calling it a dozen times longer
than I'd expect is perhaps a bit much.
Refine refine refine.
^ permalink raw reply [relevance 99%]
* Re: [Bitcoin-development] new bitcoin.org clients page
@ 2012-05-02 13:22 99% ` Mike Hearn
2012-05-02 13:30 99% ` Gregory Maxwell
` (4 more replies)
0 siblings, 5 replies; 87+ results
From: Mike Hearn @ 2012-05-02 13:22 UTC (permalink / raw)
To: Alan Reiner; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4040 bytes --]
We're debating the descriptions on the thread. I provided rewritten
descriptions that try and keep with the "theme per client" goal, whilst
being less technical.
I think it's unclear how best to run this page. It's clear we need one
though. If everyone can just submit whatever they like then we'll end up
with 4 or 5 "pick me! pick me!" type descriptions, which avoids a lot of
arguing but doesn't really help our users make a decision. If we have a
Benign Dictator model we might end up with descriptions that are wrong or
don't highlight the strengths / weaknesses of each client properly.
So although it's messy I think the right path is probably the middle one -
have some descriptions that try to be neutral, then improve them based on
feedback from users and developers. They need to be flexible and evolve
over time as the clients evolve too. At some point every client will
support deterministic wallets so "easy backups" won't be worth mentioning
any more, but there'll be new distinguishing features. And we all need to
try and be honest about our own work.
Here is the current content. Like I said, the descriptions are *not* set in
stone at all.
Bitcoin-Qt <http://bitcoin.org/>
The original software written by Satoshi Nakamoto, the project's founder.
If you aren't sure which program to pick, this is a good bet. This
application is a peer-to-peer client that builds the backbone of the
Bitcoin network. It is suited for enthusiasts, merchants, miners,
developers and people who want to help support the project. People who run
Bitcoin-Qt are first class network citizens and have the highest levels of
security, privacy and stability. However, it can be very resource intensive
and you should be willing to leave it running in the background so other
computers can connect to yours. If your computer is low powered or you
aren't willing to tolerate a 24-hour+ initial start time, you should
consider other clients. Cutting edge features tend to be implemented in
other clients first.
Website: bitcoin.org
Platforms:
MultiBit <http://multibit.org/>
MultiBit's primary focus is being fast and easy to use, even for people
with no technical knowledge. It has a YouTube channel to help you learn the
software, and includes helpful features such as an exchange rate ticker.
MultiBit supports many languages such as German, Spanish and Greek.
MultiBit synchronizes with the network much faster than Bitcoin-Qt and
should be ready for you to use within a few minutes. This is a good choice
for non technical users who want an easy to use experience, especially if
you use a Mac.
Website: multibit.org
Platforms:
Armory <http://bitcoinarmory.com/>
Armory focuses on advanced wallet management features, such as the ability
to construct transactions whilst disconnected from the internet. It
operates in conjunction with a Bitcoin-Qt install. It requires a large
amount of RAM to operate and if you use Windows, it requires a 64 bit
version. It is a good choice for tech-savvy enthusiasts or merchants who
want to try out cutting edge ideas in the Bitcoin world. Armory was partly
funded by a community donation drive which raised over $4000.
Website: bitcoinarmory.com
Platforms:
Electrum <http://ecdsa.org/electrum>
Electrum's focus is speed, with low resource usage and making wallet
backups easy. It operates in conjunction with remote servers that handle
the most complicated parts of the Bitcoin system, which is why it's fast.
However, by running this client you don't contribute your computer's
resources to the core network, and the remote servers that help give it
good performance have the ability to see all your transactions and tie them
together. Whilst you need provide no personal information to use Electrum
(as is true for all Bitcoin clients), this means the privacy level is lower
than for other clients. Merchants are recommended to use other p2p clients.
Electrum is not quite user friendly yet - currently it is more suited for
tech-saavy individuals.
Website: ecdsa.org/electrum
Platforms:
[-- Attachment #2: Type: text/html, Size: 10611 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-87 of 87 | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2012-04-30 17:50 [Bitcoin-development] new bitcoin.org clients page Amir Taaki
2012-04-30 18:23 ` Alan Reiner
2012-04-30 18:31 ` Amir Taaki
2012-04-30 19:51 ` Alan Reiner
2012-05-02 13:22 99% ` Mike Hearn
2012-05-02 13:30 99% ` Gregory Maxwell
2012-05-02 13:32 99% ` Mike Hearn
2012-05-02 13:31 99% ` Luke-Jr
2012-05-02 16:21 99% ` grarpamp
2012-05-02 16:30 99% ` Luke-Jr
2012-05-02 16:58 99% ` grarpamp
2012-05-02 18:29 99% ` Jeff Garzik
2012-05-02 19:25 99% ` Amir Taaki
2012-05-02 19:34 99% ` Gary Rowe
2012-05-02 19:40 99% ` Raphael NICOLLE
2012-05-02 19:42 99% ` Gary Rowe
2012-05-02 19:43 99% ` Alan Reiner
2012-05-02 19:43 99% ` Amir Taaki
2012-05-02 19:46 99% ` Gary Rowe
2012-05-02 19:56 99% ` Alan Reiner
2012-05-02 20:25 99% ` Luke-Jr
2012-05-02 20:39 99% ` Gary Rowe
2012-05-02 19:35 99% ` Alan Reiner
2012-05-03 9:06 99% ` grarpamp
2012-05-02 13:38 99% ` Gregory Maxwell
2012-05-02 13:42 99% ` Mike Hearn
2012-05-02 15:01 99% ` Alan Reiner
2012-05-02 16:53 99% ` grarpamp
2012-05-03 7:28 99% ` Andreas Schildbach
2012-05-03 9:24 99% ` Jorge Timón
2012-05-03 9:53 99% ` Andreas Schildbach
2012-05-03 10:25 99% ` Jorge Timón
2012-05-02 23:04 99% ` Jeff Garzik
2012-05-02 20:41 99% Jim
2012-05-03 4:28 99% [Bitcoin-development] URI Handling in Bitcoin-Qt Alan Reiner
2012-05-03 5:46 99% ` Wladimir
2012-05-04 0:54 99% ` Alan Reiner
2012-05-03 7:16 99% ` Andreas Schildbach
[not found] <CAFBxzADBoEU9ncCxsHg7_tMz_WmAnhDrh_m8kWw4Nb5FykjfEg@mail.gmail.com>
2012-05-05 8:31 99% ` [Bitcoin-development] Potential network split when individual tx used as coinbase? Rebroad (sourceforge)
2012-05-05 11:40 99% ` Pieter Wuille
2012-05-05 8:37 99% [Bitcoin-development] free tx rate limiter potentially causes more traffic not less? Rebroad (sourceforge)
2012-05-08 12:24 99% [Bitcoin-development] Bitcoin intro and talks in Berlin (11th May at 20:00) Amir Taaki
2012-05-08 14:02 99% [Bitcoin-development] block difficulty - inherently stable or inherently unstable? Rebroad (sourceforge)
2012-05-11 15:33 99% [Bitcoin-development] Please review: getmemorypool (BIP 22) revision Luke-Jr
2012-05-12 1:42 99% [Bitcoin-development] IPv6 bitcoin support now live Jeff Garzik
[not found] ` <CAPg+sBgf0uS9ua9kGcLraq_vQ+vx7o7XHfEdVRAEbYSG_6ibdQ@mail.gmail.com>
2012-05-26 13:14 99% ` Pieter Wuille
2012-05-27 17:02 99% ` Peter Todd
2012-05-12 7:00 99% [Bitcoin-development] Stackoverflow with latest git head Peter Todd
2012-05-16 16:34 99% [Bitcoin-development] BIP 33 - Stratized Nodes Amir Taaki
2012-05-16 16:46 99% ` Mike Hearn
2012-05-16 17:32 99% ` Amir Taaki
2012-05-16 18:22 99% ` Jeff Garzik
2012-05-16 16:49 99% ` Peter Vessenes
2012-05-16 17:37 99% ` Amir Taaki
2012-05-16 18:18 99% [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes) Jeff Garzik
2012-05-16 18:29 99% ` Luke-Jr
2012-05-16 18:38 99% ` Jeff Garzik
2012-05-16 18:46 99% ` Luke-Jr
2012-05-24 16:33 99% [Bitcoin-development] Punishing empty blocks? Jeff Garzik
2012-05-24 17:05 99% ` Arthur Britto
2012-05-24 17:13 99% ` Joel Joonatan Kaartinen
2012-05-24 17:23 99% ` Jeff Garzik
2012-05-24 17:27 99% ` Robert McKay
2012-05-24 18:16 99% ` Jeff Garzik
2012-05-24 20:31 99% ` Luke-Jr
2012-05-24 21:00 99% ` Jeff Garzik
2012-05-25 0:45 99% ` Luke-Jr
2012-05-25 0:51 99% ` Jeff Garzik
2012-05-25 0:57 99% ` Luke-Jr
2012-05-25 1:17 99% ` Jeff Garzik
2012-05-25 7:47 99% ` Christian Decker
2012-05-25 13:44 99% ` Alan Reiner
2012-05-25 14:00 99% ` Peter Vessenes
2012-05-25 1:00 99% ` Gregory Maxwell
2012-05-26 5:03 99% ` Zooko Wilcox-O'Hearn
2012-05-26 11:52 99% ` Stefan Thomas
2012-05-28 14:54 99% ` Peter Vessenes
[not found] ` <1338222334.48856.YahooMailNeo@web121001.mail.ne1.yahoo.com>
2012-05-28 16:25 99% ` [Bitcoin-development] Fw: " Amir Taaki
2012-05-29 8:52 99% ` [Bitcoin-development] " Michael Grønager
2012-05-29 14:47 99% ` Luke-Jr
2012-05-29 15:05 99% ` Peter Vessenes
2012-05-29 15:18 99% ` Luke-Jr
2012-05-29 15:28 99% ` Peter Vessenes
2012-05-29 15:34 99% ` Luke-Jr
2012-05-29 15:36 99% ` Peter Vessenes
2012-05-29 15:39 99% ` Luke-Jr
2012-05-29 15:45 99% ` Peter Vessenes
2012-05-29 16:30 99% ` Rebroad (sourceforge)
2012-05-29 15:33 99% ` Gregory Maxwell
2012-05-29 14:54 99% [Bitcoin-development] Testnet reset for the 0.7 release Gavin Andresen
2012-05-30 15:58 99% [Bitcoin-development] [ANNOUNCE] BitCoinJ 0.5 released Mike Hearn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox