I had to hit the sack last night as it was 2am CET, but I'd like to
sum up the discussion we had on IRC about scalability and SatoshiDice
in particular.
I think we all agreed on the following:
- Having senders/buyers pay no fees is psychologically desirable even
though we all understand that
Need to specify the format of how these arrive. It means that when a
new block is found instead of inv-getdata-block we'd see something
like inv-getdata-merkleblock where a merkleblock structure is a
header + list of transactions + list of merkle branches linking them
to the root.
Thinking
On Thu, 2012-06-14 at 13:52 +0200, Mike Hearn wrote:
filterinit(false positive rate, number of elements): initialize
filterload(data): input a serialized bloom filter table metadata and data.
Why not combine these two?
I believe its because it allows the node which will have to use the
Yes, the format is something that must be hashed out (no pun
intended). Need input from potential users about what information
they might need.
Matts point that a branch-per-transaction may duplicate data is well
made, that said, I suspect a format that tries to fix this would be
much more
On Fri, 2012-06-15 at 15:23 +0200, Mike Hearn wrote:
Why not combine these two?
I believe its because it allows the node which will have to use the
bloom filter to scan transactions to chose how much effort it wants to
put into each transaction on behalf of the SPV client.
If that's
On Fri, 2012-06-15 at 15:43 +0200, Mike Hearn wrote:
Yes, the format is something that must be hashed out (no pun
intended). Need input from potential users about what information
they might need.
Matts point that a branch-per-transaction may duplicate data is well
made, that said, I
On Fri, Jun 15, 2012 at 9:43 AM, Mike Hearn m...@plan99.net wrote:
How about see this project as a three part change?
First step - add the mempool command and make nodes sync up their
mempools on startup.
Here's the mempool implementation:
https://github.com/bitcoin/bitcoin/pull/1470
SPV
On Fri, Jun 15, 2012 at 4:59 PM, Peter Vessenes pe...@coinlab.com wrote:
Hi all,
I've been wondering about whether it would be possible to wipe out the GUI
completely from the satoshi client, and reimplement any necessary data
requests as RPC calls, allowing us to fork -QT and other GUIs
On Fri, 2012-06-15 at 15:34 +0200, Mike Hearn wrote:
The idea can be more generalized in that there are many cases where the
generator of a transaction doesn't care about confirmation times, and
would really be willing to make their transaction lower priority than
other 0-fee transactions.
On Fri, 2012-06-15 at 11:32 -0400, Jeff Garzik wrote:
As for full nodes... I like the organic growth and random nature of
the mempools. On the fence, WRT full node mempool sync at startup.
I dont particularly care either way, but I have a feeling miners will
really want that so that they can
[I originally sent an earlier version of this message to Mike off
list, but I figure it's worth adding to the public discussion]
On Fri, Jun 15, 2012 at 7:29 AM, Mike Hearn m...@plan99.net wrote:
(4) Making the block size limit float is better than picking a new
arbitrary threshold.
On the
Thanks Mike for the writeup - I'm very sad to have missed the discussion
on IRC since fee economics are probably my favorite topic, but I'll try
to contribute to the email discussion instead.
(4) Making the block size limit float is better than picking a new
arbitrary threshold.
Fees are a
On Fri, Jun 15, 2012 at 12:56 PM, Stefan Thomas m...@justmoon.de wrote:
The artificial limits like the block size limit are essentially putting
[...]
Changing the block size is an item for the hard-fork list. The chance
of the block size limit changing in the short term seems rather low...
it
I do agree that changing/lifting the block size limit is a hard fork
measure, but Mike raised the point and I do believe that whatever we
decide to do now will be informed by our long term plan as well. So I
think it is relevant to the discussion.
Can someone please help quantify the situation?
Grouping mempool transactions based on fees of the group seems
an unnecessary complexity; it makes it harder to predict if an isolated
transaction has enough juice to be included in the next Block.
Given your point about economic actors adapting to conditions, would it not
be simpler to use a
Why though? The bottleneck is not network traffic but disk space
usage/blockchain validation time.
- Original Message -
From: Mike Hearn m...@plan99.net
To: Jeff Garzik jgar...@exmulti.com
Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net
Sent: Friday, June 15, 2012
less expensive. This is no more real or less artificial then an
imposed licensing fee or the like and it is not subject to market
forces.
Sure, the market is not always efficient nor desirable. This seems more like a
social question though about choice and information. I do strongly feel that
On Fri, Jun 15, 2012 at 2:50 PM, Amir Taaki zgen...@yahoo.com wrote:
Part of the problem is that Satoshi didn't totally anticipate the growth of
the network. The block reward (the subsidy) is too high, which is why
transactions can afford to be so cheap. What would happen if blocks required
(1) Change the mining code to group transactions together with their
mempool dependencies and then calculate all fees as a group.
I think there is general consensus this is a good idea.
(2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to
avoid paying excessive fees and
On Fri, Jun 15, 2012 at 04:58:55PM -0400, grarpamp wrote:
When bitcoind exits cleanly, it does not seem safe for the blockchain
to clean up the following hierarchy with rm -r ?
Use -detachdb if you want to detach the blockchain database files from the
database environment at exit. This was
Outside of major features advertised network-wide in nService bits,
P2P protocol lacks a good method of enumerating minor features or
extensions. The version number increment is coarse-grained, and is
not self-documenting. A simple extension which lists supported
commands is added, as
Introspection/command discovery is nice, but I would prefer it to be
immediately done in the first version exchange so no assumptions as to how a
network is operating need to be made.
I like the idea of a flat list of commands. It might make sense to have
meta-commands that alias to groups of
Yes, I measure mainnet confirmation times on a regular basis.
http://bitcoinstats.org/post/tx-confirmation-times-June2012.png
Before fairly recently, fee-paying transactions never took anywhere close to
this long to be confirmed.
Jonathan Warren
(Bitcointalk: Atheros)
-Original
Did anyone try sending them an email asking them to stop or offering help to
fix their site? What did they say? I'm sure they would try to be accomodating.
- Original Message -
From: Jonathan Warren jonat...@bitcoinstats.org
To: bitcoin-development@lists.sourceforge.net
Cc:
Sent:
24 matches
Mail list logo
