> 16 million divided by 1085 transactions is almost 15Kb per transaction =
> unlikely, right?
The recent spam was about 15 kB per transaction, so that part sounds right.
The anomalous thing that I saw was that the total bitcoind process usage was
about 50-100x higher than I would have expected
On Oct 13, 2015, at 3:49 PM, odinn wrote:
> Signed PGP part
> It would also help to know what operating system(s) you are
> using for both the oldie and the freshie.
Linux feather 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
x86_64 GNU/Linux
Linux server 3.2.0-4-amd64 #1 SMP
I just noticed that several of my running bitcoind processes were using around
3+ GB of RAM, even though the mempool itself seemed to be under control.
@prime:~/bin$ ./bitcoin-cli getmempoolinfo
{
"size" : 1896,
"bytes" : 37341328
}
[total memory usage not shown -- I restarted bitcoi
On Oct 7, 2015, at 9:02 AM, Eric Lombrozo wrote:
> But a real hashpower supermajority would make such attacks hard to pull off
> in practice.
If you had a 99% hashpower supermajority on the new version, an attacker would
still be able to perform this attack once per day. Since the attacker i
On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev
wrote:
> *But* a soft fork that only forbids transactions that would previously
> not have been mined anyway should be the best of both worlds, as it
> automatically reduces the liklihood of old miners building newly invalid
> blocks to
Making statements about a developer's personal character is also off-topic for
this list.
On Sep 29, 2015, at 3:58 PM, Milly Bitcoin via bitcoin-dev
wrote:
> On 9/29/2015 5:07 PM, Jeff Garzik via bitcoin-dev wrote:
>> This is off-topic for this list.
>
> You like to go around pretending you a
On Tue, Sep 29, 2015 at 9:30 AM, Jonathan Toomim (Toomim Bros) via
> bitcoin-dev wrote:
> As a further benefit to hard forks, anybody who is ideologically opposed to
> the change can continue to use the old version successfully, as long as there
> are enough miners to keep the fork
On Sep 28, 2015, at 7:43 AM, Peter Todd via bitcoin-dev
wrote:
>
> Ok, so again, if that's your security criteria, what's the issue with
> soft-forks? With soft-forks, the result of a SPV wallet following the
> highest work chain is the same: eventually invalid blocks are reorged
> out.
>
> H
On Sep 28, 2015, at 1:30 AM, Kalle Rosenbaum via bitcoin-dev
wrote:
> Suppose that you've solved a block Z (weak or not) and you want to propagate
> it using a previous weak block Y. With "efficient differential transmission",
> I assume that you refer to the transmission of the differences b
As I understand it, the current block propagation algorithm is this:
1. A node mines a block.
2. It notifies its peers that it has a new block with an inv. Typical nodes
have 8 peers.
3. The peers respond that they have not seen it, and request the block with
getdata [hash].
4. The node sends
On Sep 23, 2015, at 2:37 PM, Gavin Andresen via bitcoin-dev
wrote:
> Take care, here-- if a scheme is used where e.g. the full solution had
> to be exactly identical to a prior weak block then the result would be
> making mining not progress free because bigger miners would have
> disproportion
11 matches
Mail list logo
