<unnamed>

Public Key

npub156vplpc5zjxk79ttdc320xhwq385tchgryp90hyzna9pju8yhn8s69r5gn

Profile Code

nprofile1qqs2dxqlsu2pfrt0z44kug48nthqgn69ut5pjqjhmjpf7jsewrjtencpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0v08cy0

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:43:16 UTC

- reply

📅 Original date posted:2015-10-13
📝 Original message:On Oct 13, 2015, at 3:49 PM, odinn <odinn.cyberguerrilla at riseup.net> 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 Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
Linux prime 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u2 x86_64 GNU/Linux
This excessive memory consumption was seen on 3 machines, all of which run Debian. All three machines run p2pool as well as bitcoind. Two run XT, one runs Core.
>
> You should compare this to having set up a node on a completely clean
> computer.
I can't afford to do that. All of the servers I have are being used for something. Also, I'm not sure what it is you're trying to test for with that suggestion. The numbers I'm reporting are for bitcoind's resident set, not for the whole server's memory usage. I don't see how other processes running on the same machine are relevant unless you are suggesting that RPC calls (e.g. getblocktemplate) might be somehow responsible.
>
> Also, dump your XT, is poo.
Not relevant. I addressed this message to both the Core and XT lists because the issue appears to affect both forks. Let's keep blocksize and governance debates to their own threads, please.
Repeating request: Has anyone else seen something similar? Can you report your mempool size and total bitcoind resident set size for your running full nodes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/f11fac76/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/f11fac76/attachment-0001.sig>

2023-06-07 17:43:16 UTC

- reply

📅 Original date posted:2015-10-13
📝 Original message:> 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 if the mempool was the main determinant of memory usage scaling. Can you tell me how much memory Task Manager is reporting your bitcoin process as using both today and tomorrow?
On Oct 13, 2015, at 4:52 PM, Dave Scotese via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> {
> "size" : 1085,
> "bytes" : 16151768
> }
> It has been running about a day. I'll report tomorrow too. This is a Windows 8.1 box.
> 16 million divided by 1085 transactions is almost 15Kb per transaction = unlikely, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/b314b4b7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/b314b4b7/attachment.sig>

2023-06-07 17:43:15 UTC

- reply

📅 Original date posted:2015-10-13
📝 Original message: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.
XXXX at prime:~/bin$ ./bitcoin-cli getmempoolinfo
{
"size" : 1896,
"bytes" : 37341328
}
[total memory usage not shown -- I restarted bitcoind as soon as I noticed, and didn't copy it down from top]
37 MB mempool, >3 GB RAM usage. Normally, when there aren't a lot of unconfirmed txns floating around the network, memory usage is around 600 MB, so this is quite unusual.
After restarting the process and letting it run for a few minutes, I get:
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
[###] [XXXX] 20 0 1402M 317M 49836 S 1.0 8.2 0:41.71 ./bitcoind -daemon
XXXX at prime:~/bin$ ./bitcoin-cli getmempoolinfo
{
"size" : 1072,
"bytes" : 670000
}
0.67 MB mempool, 317 MB RAM usage. Much more reasonable.
Here's another node I'm running that has been online longer, before restarting:
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
[###] [XXXX] 20 0 4961M 3540M 11080 S 2.8 45.3 8h20:11 bin/bitcoind -daemon
XXXX at feather:~$ bin/bitcoin-cli getmempoolinfo
{
"size" : 3045,
"bytes" : 39656126
}
39 MB mempool, 3540 MB total memory usage. After restarting bitcoind, I see:
[XXXX]@feather:~$ bin/bitcoin-cli stop
Bitcoin server stopping
[XXXX]@feather:~$ bin/bitcoind -daemon
Bitcoin server starting
[XXXX]@feather:~$ sleep 10; bin/bitcoin-cli getmempoolinfo
{
"size" : 39,
"bytes" : 47037
}
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
[###] [XXXX] 20 0 1640M 247M 67960 S 0.0 3.2 0:05.17 bin/bitcoind -daemon
Does anybody have any guesses where we might be leaking memory, or what is using the additional 2.4 GB? I've been using minrelaytxfee=0.00003 or similar on my nodes. Maybe there's a leak in the minrelaytxfee code path? Has anyone else seen something similar?
This issue appears to happen both with Bitcoin Core 0.10.1 and with Bitcoin XT 0.11B.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/dc82ee16/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/dc82ee16/attachment.sig>

2023-06-07 17:42:03 UTC

- reply

📅 Original date posted:2015-10-07
📝 Original message:On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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 a vanishingly small probability; which means that upgraded
> bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all*
> continuing to work fine during the upgrade.
I agree with pretty much everything you wrote except the above paragraph.
An attacker can create a transaction that would be valid if it were an OP_NOP, but not valid if it were any more restrictive transaction. For example, an attacker might send 1 BTC to an address with . An old node would consider that OP_CLTV to be OP_NOP, so no signature is necessary for old nodes. Then the attacker buys something from a merchant running old node code or an SPV client, and spends the 1 BTC in that address in a way that is invalid according to OP_CLTV but valid according to OP_NOP, and includes a hefty fee. A miner on the old version includes this transaction into a block, thereby making the block invalid according to the new rules, and rejected by new-client miners. The merchant sees the 1-conf, and maybe even 2-conf, rejoices, and ships. The attacker then has until the OP_CLTV matures to double-spend the coin with new nodes using a valid signature.
Basically, it's trivial to create transactions that exploit the difference in validation rules as long as miners are still on the old version to mine them. Transactions can be created that are guaranteed to be orphaned and trivially double-spendable. Attackers never have to risk actual losses. This can be done as long as miners continue to mine old-version blocks, regardless of their frequency.
Those of you who know Script better than me: would this be an example of a transaction that would be spendable with a valid sig XOR with (far future date OR old code)?
OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_PUSHDATA <locktime far in the future> OP_CLTV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151007/c701783e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151007/c701783e/attachment.sig>

2023-06-07 17:41:46 UTC

- reply

📅 Original date posted:2015-09-29
📝 Original message:At the 95% threshold, I don't think it would happen unless there was a very strong motivating factor, like a small group believing that CLTV was a conspiracy run by the NSA agent John Titor to contaminate our precious bodily fluids with time-traveling traveler's cheques.
At the 75% threshold, I think it could happen with mostly rational users, but even then it's not very likely with most forks. With the blocksize issue, there are some people who get very religious about things like decentralization or fee markets and think that even 1 MB is too large; I could see them making financial sacrifices in order to try to make a small-block parallel fork a reality, one that is true to their vision of what's needed to make Bitcoin true and pure, or whatever.
On Sep 29, 2015, at 7:04 AM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> I keep seeing statements like this:
>
> On Tue, Sep 29, 2015 at 9:30 AM, Jonathan Toomim (Toomim Bros) via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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 alive.
>
> ... but I can't see how that would work.
>
> Lets say there is a hard fork, and 5% of miners stubbornly refuse to go along with the 95% majority (for this thought experiment, it doesn't matter if the old rules or new rules 'win').
>
> Lets further imagine that some exchange decides to support that 5% and lets people trade coins from that fork (one of the small altcoin exchanges would definitely do this if they think they can make a profit).
>
> Now, lets say I've got a lot of pre-fork bitcoin; they're valid on both sides of the fork. I support the 95% chain (because I'm not insane), but I'm happy to take people's money if they're stupid enough to give it to me.
>
> So, I do the following:
>
> 1) Create a send-to-self transaction on the 95% fork that is ONLY valid on the 95% fork (maybe I CoinJoin with a post-fork coinbase transaction, or just move my coins into then out of an exchange's very active hot wallet so I get coins with a long transaction history on the 95% side of the fork).
>
> 2) Transfer those same coins to the 5% exchange and sell them for whatever price I can get (I don't care how low, it is free money to me-- I will still own the coins on the 95% fork).
>
> I have to do step (1) to prevent the exchange from taking the transfer-to-exchange transaction and replaying it on the 95% chain.
>
> I don't see any way of preventing EVERYBODY who has coins on the 95% side of the fork from doing that. The result would be a huge free-fall in price as I, and everybody else, rushes to get some free money from anybody willing to pay us to remain idealogically pure.
>
> Does anybody think something else would happen, and do you think that ANYBODY would stick to the 5% fork in the face of enormously long transaction confirmation times (~3 hours), a huge transaction backlog as lots of the 95%'ers try to sell their coins before the price drops, and a massive price drop for coins on the 5% fork.
>
> --
> --
> Gavin Andresen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/4dde6117/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/4dde6117/attachment.sig>

2023-06-07 17:41:36 UTC

- reply

📅 Original date posted:2015-09-29
📝 Original message:On Sep 28, 2015, at 7:43 AM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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.
>
> However, because soft-forks make it less likely that a long invalid
> chain will be generated, an attacker sybil attacking your SPV wallet has
> a much harder time tricking it into accepting a transaction. (they might
> get one or two confirmations, rather than dozens)
>
> What's the scenario where soft-forks are worse than hard-forks from a
> SPV wallet's perspective?
I don't think this was addressed clearly, so here's my attempt.
With a soft fork, miners who have not upgraded append their blocks to the longest block chain. To SPV clients and to old fully-validating clients, it appears to be a valid block that inevitably gets orphaned. SPV clients will be tricked to follow these blocks every time they appear, since every time they appear they will have a PoW advantage for a few minutes. SPV clients will appear to behave normally, and will continue to show new transactions and get confirmations in a timely fashion. However, they will be systematically susceptible to attack from double-spends that attempt to spend funds in a way that the upgraded nodes will reject. These transactions will appear to get 1 confirmation, then regress to zero conf, every single time. These attacks can be performed for as long as someone mines with the old version. If an attacker thinks he could get more than 25 BTC of double-spends per block, he might even choose to mine with the obsolete version in order to get predictable orphans and to trick SPV clients and fully verifying wallets on the old version.
With a hard fork, miners who have not upgraded will append their blocks on the shorter fork. SPV clients will ignore this fork unless Sybil attacked. If an SPV node only connects to one full node server, that's equivalent to a Sybil attack. In that case, transactions on the long chain will often not be present on the short chain due to its shortness. Confirmations will be slow, and will be shown to be very different from what's shown on block explorers. Displayed transaction dates and times will be off, when they show up at all. Any transactions that have been contaminated by recent mining revenue will not show up at all. SPV client users will probably notice something is wrong. If the SPV client connects to several full nodes, then this should rarely happen. For example, if 5% of full nodes are still on the old version, and an SPV wallet connects to 2 nodes at a time, there is a 0.05**2 = 0.25% chance. If the SPV client has headers cached on disk from a previous connection to the longer chain, then that chance effectively drops to zero. 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 alive.
In short: soft forks mean frequent predictable and manipulable orphan blocks that SPV clients will always follow, with transactions that get confirmed once and then perma-orphaned. Hard forks mean that SPV clients will almost always work flawlessly, and will occasionally give very strange and noticeably wrong results. For fully-verifying nodes, soft forks make old versions insecure, but hard forks allow new and old versions to operate in parallel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/22615768/attachment.sig>