Aidan Thornton [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-09-14 to 2012-07-23
💬 Posted a total of 5 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 10:25:08

- reply

📅 Original date posted:2012-07-23
📝 Original message:On Sun, Jul 22, 2012 at 11:37 PM, grarpamp <grarpamp at gmail.com> wrote:
> Given a testbed: Pentium 4 1.8GHz single core, 2GB ram, FreeBSD 8,
> disk is geli aes-128 + zfs sha-256, bitcoin 0.6.3, Tor proxy,
> An estimate is made that by the end of the year bitcoin will
> completely overrun the capabilities of this reasonable class of
> machines.
That's actually slower-than-Atom class hardware you're running on
there, with full disk encryption on what's a very CPU and IO-heavy
workload. From the benchmarks I remember, your CPU is literally slower
than the first generation of single-core netbooks - the ones reviewers
recommended against using full disk encryption on because they just
didn't have enough CPU power to manage it. It's not surprising that
Bitcoin isn't usable on that setup.

2023-06-07 03:06:37

- reply

📅 Original date posted:2012-02-07
📝 Original message:On Mon, Feb 6, 2012 at 5:27 PM, Wladimir <laanwj at gmail.com> wrote:
> Change BitcoinAddressValidator::MaxAddressLength to 35
> The addresses are validated with walletmodel->validateAddress which in turn
> calls CBitcoinAddress addressParsed(addr) and then isValid(). Does this work
> for the new addresses?
Should do (unless BIP 16 broke something). In fact both the GUI and
RPC commands use CBitcoinAddress and IsValid to validate addresses in
that way.
> And maybe WalletModel::sendCoins has to be changed.
> Does CScript.SetBitcoinAddress work for the new address type?
Again, should do, and it's used by the RPC commands for sending
Bitcoins as well. Really there's not a lot that needs to be changed.
I'm pretty sure even the change in MaxAddressLength is only necessary
to send coins to multisig addresses on testnet, sending them on
mainnet should just work.

2023-06-07 03:05:53

- reply

📅 Original date posted:2012-02-03
📝 Original message:On Fri, Feb 3, 2012 at 9:22 AM, Michael Grønager <gronager at ceptacle.com> wrote:
> Hi Gavin, others?
>
> I am trying to redo the performance test of the libcoin client against the 0.5.2 Satoshi client, that I have learned also have received quite some improvements in speed since 0.4.0 (e.g. from not verifying signatures on early blocks).
>
> However, I cannot find any tag with v0.5.2 in github:
> https://github.com/bitcoin/bitcoin/tags
I think that tag's in
https://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable
- a certain amount of developer politics seems to be involved, and
v0.5.2 may not have been pushed to the official github repository.

2023-06-07 03:03:47

- reply

📅 Original date posted:2012-02-01
📝 Original message:On Wed, Feb 1, 2012 at 4:15 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Wednesday, February 01, 2012 10:58:28 AM Michael Grønager wrote:
>> Your CMake cannot find boost - use ccmake or cmake-gui to help it with the
>> location.
>
> I didn't see anything useful in ccmake. Boost is in the standard locations
> (/usr/include/boost/ and /usr/lib/libboost*
The error about not finding boost is a red herring and as far as I can
tell bogus. The problem is that it finds Qt and tries to configure
some Qt code that doesn't seem to have actually been released. Try
http://pastebin.ca/2108766
>> Btw what platform are you using ?
>
> Gentoo
Also, you'll probably need to set BDB_INCLUDE_PATH manually or it
won't find db.h
Hope this helps,
Aidan

2023-06-07 03:03:47

- reply

2023-06-07 02:25:37

- reply

📅 Original date posted:2011-09-14
🗒️ Summary of this message: Proposal to modify getwork code to discourage blocks with stale timestamps. Majority adoption would prevent cartels from manipulating difficulty.
📝 Original message:On Wed, Sep 14, 2011 at 3:45 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> Modify the getwork code to build on the second-from-tip block if the
> first-on-tip block is on the discouraged list.
>
> Assuming a majority of pools/miners adopt the "discourage blocks with
> stale timestamps" rule, that should squash any incentive for cartels
> to try to start playing with difficulty-- you would have to have 50+%
> power to start, or you risk producing mostly orphan blocks.
Of course, if only a small percentage of mining power adopts this
scheme, everyone that does so will presumably be harming themselves by
doing so since they're essentially increasing the odds that the next
block they mine will become invalid...

2023-06-07 02:25:37

- reply