As replied on the github issue:
Personally I still think it's better to have a clear standardized "protocol
version", that implies what capabilities are supported, instead of a
capability-based system that explicitly lists them.
Capability-based systems (just look at OpenGL) tend to become horren
Did anyone try sending them an email asking them to stop or offering help to
fix their site? What did they say? I'm sure they would try to be accomodating.
- Original Message -
From: Jonathan Warren
To: bitcoin-development@lists.sourceforge.net
Cc:
Sent: Saturday, June 16, 2012 4:35 A
Yes, I measure mainnet confirmation times on a regular basis.
http://bitcoinstats.org/post/tx-confirmation-times-June2012.png
Before fairly recently, fee-paying transactions never took anywhere close to
this long to be confirmed.
Jonathan Warren
(Bitcointalk: Atheros)
-Original Message-
Introspection/command discovery is nice, but I would prefer it to be
immediately done in the first version exchange so no assumptions as to how a
network is operating need to be made.
I like the idea of a flat list of commands. It might make sense to have
"meta"-commands that alias to groups of
Outside of major features advertised network-wide in nService bits,
P2P protocol lacks a good method of enumerating minor features or
extensions. The version number increment is coarse-grained, and is
not self-documenting. A simple extension which lists supported
commands is added, as demonstrate
On Fri, Jun 15, 2012 at 04:58:55PM -0400, grarpamp wrote:
> When bitcoind exits cleanly, it does not seem safe for the blockchain
> to clean up the following hierarchy with rm -r ?
Use -detachdb if you want to detach the blockchain database files from the
database environment at exit. This was tur
When bitcoind exits cleanly, it does not seem safe for the blockchain
to clean up the following hierarchy with rm -r ?
database/
db.log
.lock
debug.log
addr.dat
wallet.dat
And what about adding to the above list the following files when
bitcoind crashes:
__db.*
Is there an option to make bitcoi
> (1) Change the mining code to group transactions together with their
> mempool dependencies and then calculate all fees as a group.
I think there is general consensus this is a good idea.
> (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to
> avoid paying excessive fees and que
While happily processing these:
received block ...
SetBestChain: new best=... height=... work=...
ProcessBlock: ACCEPTED
bitcoind very often refuses to answer rpc queries such as getinfo/stop,
or signals such as kill/ctrl-c. It even registers:
ThreadRPCServer method=getinfo/stop
in the debug lo
On Fri, Jun 15, 2012 at 2:50 PM, Amir Taaki wrote:
> Part of the problem is that Satoshi didn't totally anticipate the growth of
> the network. The block reward (the subsidy) is too high, which is why
> transactions can afford to be so cheap. What would happen if blocks required
> a cumulative
> less expensive. This is no more "real" or less "artificial" then an
> imposed licensing fee or the like and it is not subject to market
> forces.
Sure, the market is not always efficient nor desirable. This seems more like a
social question though about choice and information. I do strongly fee
Why though? The bottleneck is not network traffic but disk space
usage/blockchain validation time.
- Original Message -
From: Mike Hearn
To: Jeff Garzik
Cc: Bitcoin Development
Sent: Friday, June 15, 2012 3:43 PM
Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SP
Forcing users to switch addresses per received payment to work around a bad fee
system would be a braindead decision. You might love software and playing with
web plugins, but not everyone does. Artists like Rap News can right now simply
throw up an address and begin accepting donations. That's
Grouping mempool transactions based on fees of the group seems
an unnecessary complexity; it makes it harder to predict if an isolated
transaction has enough "juice" to be included in the next Block.
Given your point about economic actors adapting to conditions, would it not
be simpler to use a in
I do agree that changing/lifting the block size limit is a hard fork
measure, but Mike raised the point and I do believe that whatever we
decide to do now will be informed by our long term plan as well. So I
think it is relevant to the discussion.
> Can someone please help quantify the situation?
On Fri, Jun 15, 2012 at 12:56 PM, Stefan Thomas wrote:
> The artificial limits like the block size limit are essentially putting
[...]
Changing the block size is an item for the hard-fork list. The chance
of the block size limit changing in the short term seems rather low...
it is a "nuclear op
Thanks Mike for the writeup - I'm very sad to have missed the discussion
on IRC since fee economics are probably my favorite topic, but I'll try
to contribute to the email discussion instead.
> (4) Making the block size limit float is better than picking a new
> arbitrary threshold.
Fees are a pr
[I originally sent an earlier version of this message to Mike off
list, but I figure it's worth adding to the public discussion]
On Fri, Jun 15, 2012 at 7:29 AM, Mike Hearn wrote:
> (4) Making the block size limit float is better than picking a new
> arbitrary threshold.
> On the forums Matt stat
On Fri, Jun 15, 2012 at 11:43 AM, Simon Barber wrote:
> separate filterinit / filterload - so you can do a new filterload later on
> if your list changes, without the privacy implications of filteradd.
filterload loads a whole new bloom filter from scratch, in one atomic
operation. Params set, t
On Fri, 2012-06-15 at 11:32 -0400, Jeff Garzik wrote:
> As for full nodes... I like the organic growth and random nature of
> the mempools. On the fence, WRT full node mempool sync at startup.
>
I dont particularly care either way, but I have a feeling miners will
really want that so that they c
On Fri, 2012-06-15 at 15:34 +0200, Mike Hearn wrote:
> > The idea can be more generalized in that there are many cases where the
> > generator of a transaction doesn't care about confirmation times, and
> > would really be willing to make their transaction lower priority than
> > other 0-fee transa
On Fri, Jun 15, 2012 at 4:59 PM, Peter Vessenes wrote:
> Hi all,
>
> I've been wondering about whether it would be possible to wipe out the GUI
> completely from the satoshi client, and reimplement any necessary data
> requests as RPC calls, allowing us to fork -QT and other GUIs over and
> (hope
separate filterinit / filterload - so you can do a new filterload later
on if your list changes, without the privacy implications of filteradd.
Simon
On Thu 14 Jun 2012 04:52:29 AM PDT, Mike Hearn wrote:
>> filterinit(false positive rate, number of elements): initialize
>> filterload(data): inp
On Fri, Jun 15, 2012 at 9:43 AM, Mike Hearn wrote:
> How about see this project as a three part change?
>
> First step - add the mempool command and make nodes sync up their
> mempools on startup.
Here's the "mempool" implementation:
https://github.com/bitcoin/bitcoin/pull/1470
SPV nodes would d
Hi all,
I've been wondering about whether it would be possible to wipe out the GUI
completely from the satoshi client, and reimplement any necessary data
requests as RPC calls, allowing us to fork -QT and other GUIs over and
(hopefully) dramatically simplifying the codebase that you all have to wo
On Fri, 2012-06-15 at 15:43 +0200, Mike Hearn wrote:
> > Yes, the format is something that must be hashed out (no pun
> > intended). Need input from potential users about what information
> > they might need.
>
> Matts point that a branch-per-transaction may duplicate data is well
> made, that sa
On Fri, 2012-06-15 at 15:23 +0200, Mike Hearn wrote:
> > > Why not combine these two?
> >
> > I believe its because it allows the node which will have to use the
> > bloom filter to scan transactions to chose how much effort it wants to
> > put into each transaction on behalf of the SPV client.
>
> Yes, the format is something that must be hashed out (no pun
> intended). Need input from potential users about what information
> they might need.
Matts point that a branch-per-transaction may duplicate data is well
made, that said, I suspect a format that tries to fix this would be
much more
> The idea can be more generalized in that there are many cases where the
> generator of a transaction doesn't care about confirmation times, and
> would really be willing to make their transaction lower priority than
> other 0-fee transactions.
Just to be clear, I think this solution is a hack an
On Thu, Jun 14, 2012 at 7:52 AM, Mike Hearn wrote:
>> filterinit(false positive rate, number of elements): initialize
>> filterload(data): input a serialized bloom filter table metadata and data.
>
> Why not combine these two?
This is a fair point that sipa raised.
Consensus concluded that 'filt
On Fri, 2012-06-15 at 13:29 +0200, Mike Hearn wrote:
> I had to hit the sack last night as it was 2am CET, but I'd like to
> sum up the discussion we had on IRC about scalability and SatoshiDice
> in particular.
>
> I think we all agreed on the following:
>
> - Having senders/buyers pay no fees i
On Thu, 2012-06-14 at 13:52 +0200, Mike Hearn wrote:
> > filterinit(false positive rate, number of elements): initialize
> > filterload(data): input a serialized bloom filter table metadata and data.
>
> Why not combine these two?
I believe its because it allows the node which will have to use the
> > Why not combine these two?
>
> I believe its because it allows the node which will have to use the
> bloom filter to scan transactions to chose how much effort it wants to
> put into each transaction on behalf of the SPV client.
If that's the case then the negotiation protocol needs to be spec
> Need to specify the format of how these arrive. It means that when a
> new block is found instead of inv<->getdata<->block we'd see something
> like inv<->getdata<->merkleblock where a "merkleblock" structure is a
> header + list of transactions + list of merkle branches linking them
> to the ro
I had to hit the sack last night as it was 2am CET, but I'd like to
sum up the discussion we had on IRC about scalability and SatoshiDice
in particular.
I think we all agreed on the following:
- Having senders/buyers pay no fees is psychologically desirable even
though we all understand that even
35 matches
Mail list logo
