Ron [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-05-26 to 2015-06-03
💬 Posted a total of 14 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 15:36:33

- reply

📅 Original date posted:2015-06-03
📝 Original message:Subject: Bitcoin-development Digest, Vol 49, Issue 16
1. Re: Proposed alternatives to the 20MB step (Eric Voskuil)
----------------------------------------------------------------------
Message: 1
Date: Mon, 01 Jun 2015 17:09:10 -0700
From: Eric Voskuil <eric at voskuil.org>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB
step
To: Mike Hearn <mike at plan99.net>, J?r?me Legoupil
<jjlegoupil at gmail.com>
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Message-ID: <556CF426.3030204 at voskuil.org>
Content-Type: text/plain; charset="iso-8859-1"
On 06/01/2015 08:55 AM, Mike Hearn wrote:
>> Decentralization is the core of Bitcoin's security model and thus
that's what gives Bitcoin its value.
> No. Usage is what gives Bitcoin value.
Nonsense.
Visa, Dollar, Euro, Yuan, Peso have usage.
The value in Bitcoin is *despite* it's far lesser usage.
Yes, the price is a function of demand, but demand is a function of
utility. Despite orders of magnitude less usage than state currencies,
Bitcoin has utility. This premium *only* exists due to its lack of
centralized control. I would not work full time, or at all, on Bitcoin
if it was not for decentralization; nor would I hold any of it. I doubt
anyone would show an interest in Bitcoin if it was not decentralized. If
it centralized even you would be forced to find something else to do,
because Bitcoin "usage" would drop to zero.
> It's kind of maddening that I have to point this out. Decentralisation
is a means to an end.
No, it was/is the primary objective.
...
e
________________________________________________________I agree Eric, but I would add that demand is more a function of one's lack of faith in one's government and its fiat currency. The value of Bitcoin is
its independence and constancy. Its value doesn't change, only the worth
or worthlessness of corrupt states and their currencies that it's compared
to / exchanged with. I hesitate to say money since money is supposed to
be a store of value over time.
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150603/f01f9ec6/attachment.html>

2023-06-07 15:35:34

- reply

📅 Original date posted:2015-05-25
📝 Original message:Hello all,
With all the discussion about the Block size limit, I thought it would be interesting to measure, in some sense, the average Tx size. Then given a fixed average block period (Bp) of 10 minutes (i.e 600 seconds), all one needs to do to estimate an average block size is ask the question: what average transaction rate (tps) do you want?
So for tps ~ 10 (Tx/sec) and an average transaction size (avgTxSz) of 612 Bytes (last ten blocks up to block 357998 (2:05pm EDT 5/25/2015) we have a block size of 612 * 10 * 600 = 3,672,000 Bytes
Alternatively, given an avgTxSz ~612 and maxBl = 1,000,000 we have (maxBl / avgBlSz) / Bp is the actual current max tps, which is ~2.72 tps.
The avgBlSz for the 10 blocks up to block # 357999 is ~ 576 Bytes, so the current possible tps is ~2.89 and the maxBL for a tps = 10 is 3,456,000 bytes.
So I think one should state one's assumed tps and a measured or presumed avgTxSz before saying what a maxBl should be. So for a maxBl ~20,000,000 Bytes and a current avgTxSz ~600 Bytes, the tps ~55.5 FWIW
Ron (aka old c coder)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150525/943ed1d9/attachment.html>

2023-06-07 15:23:44

- reply

📅 Original date posted:2014-07-15
📝 Original message:________________________________
Message: 6
Date: Mon, 14 Jul 2014 13:26:19 +0200
From: Mike Hearn <mike at plan99.net>
Subject: Re: [Bitcoin-development] Bitcoin Protocol Specification
To: Krzysztof Okupski <k.okupski at googlemail.com>
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Message-ID:
<CANEZrP21sc9smev5tg07HnLpw-8WWS7EvzzTyEvD6qYEfHvpoA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Nice work, but please don't call it the "Bitcoin protocol spec". Your
document is not a spec. It is an attempt to describe in English the Bitcoin
protocol, but anyone who implemented it based on your description would get
it wrong. For example you didn't mention the SIGHASH_SINGLE bug and many
other important areas like the difficulty transitions are also left
unspecified.
As a loose description of the protocol for newbies it's an invaluable
resource and perhaps we should link to it from the developer guide. As
something that claims to be a specification it is quite possibly dangerous
- the only spec that matters is the C++ original.
...
Hello Mike,
What C++ original might that be? Version 0.1.0? 0.9.x? 0.8.6? And what parts of which version?
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140714/e6af2665/attachment.html>

2023-06-07 15:22:21

- reply

📅 Original date posted:2014-06-04
📝 Original message:________________________________________________________
Message: 2
Date: Wed, 4 Jun 2014 08:15:08 -0400
From: Jeff Garzik <jgarzik at bitpay.com>
Subject: Re: [Bitcoin-development] # error "Bitcoin cannot
be compiled
without assertions." <<<<NOT
To: Mike Hearn <mike at plan99.net>
Cc: "bitcoin-development at lists.sourceforge.net"
<bitcoin-development at lists.sourceforge.net>,
Ron <rdwnj at yahoo.com>
Message-ID:
<CAJHLa0PTTHfvd-1BR5s2k-4UW6V6qLEyAbF2YSRxOOSjtH9+_Q at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Yes, check macros like that can be useful.
I like the kernel's policy, which parallels our direction:
1) Enable and use lightweight assertions for most users.
2) No assertions with side effects
If you want to compile them out, that's fine, but they
should always
be present in production software.
_____________________________________________________
I don't think many of you actually read what I said, and you went off on your own tangents.
I said:
this commit and code with all side effects removed from the assertions.
in Vol 37, Issue 4
I intentionally left the gcc code alone. Only the MSC code is assert "fixed". I would have hoped that someone would have noticed and incorporated these changes into the gcc code. Simply by removing the #ifdef _MSC_VER ... #else ... #endif etc. etc.
Did I say I compiled them out? No! Did anyone bother to look at my code or what I said?
Here is an example from main.cpp CTransaction::UpdateCoins(...
- // add outputs
+ // add outputs sure looks like an assert with side effects here!?
+#ifdef _MSC_VER
+ bool
+ fTest = inputs.SetCoins(txhash, CCoins(*this, nHeight));
+ #ifdef _DEBUG
+ assert(fTest);
+ #else
+ if( !fTest )
+ releaseModeAssertionfailure( __FILE__, __LINE__, __PRETTY_FUNCTION__ );
+ #endif
+#else
assert(inputs.SetCoins(txhash, CCoins(*this, nHeight)));
+#endif
Note that I do the test, and if debugging, I let it abort() the program if it fails. Note that in release mode it calls a new function on failure, that I leave you to discover what it does. I see that this assert has been "fixed" in 0.9.x, but I think my "fix" is better, since it allows release mode code to run better, if not identically.
I changed every assert() in the bitcoind 086 sources to behave this way. Since C++ is perniciously baroque, it is not clear if a side effect can or has occurred in the most innocuous of C++ statements. Is the example above side-effect free?
Here is a piece of what I made my decision on:
http://www.gnu.org/software/libc/manual/html_node/Consistency-Checking.html and the link to the book previously given.
Also, no one answered the question about bitcoin-qt, to whit, can or should it be compiled in RELEASE mode because of this? Should it have always been compiled in DEBUG mode in the past too?
Ron

2023-06-07 15:22:15

- reply

📅 Original date posted:2014-06-03
📝 Original message:Hello
What is the issue with the Bitcoin code for 0.9.x with regard to assertions that isn't in 0.8.6 or previous releases?
on April 18th, I offered
https://github.com/bc4-old-c-coder/bitcoin/commit/f0d221e56a12947b67b9c8f43cc5832b665052c8
this commit and code with all side effects removed from the assertions.
Then on the 28th,
https://github.com/bc4-old-c-coder/bitcoin/tree/0.8.6
this code with unit tests working.
And if that isn't enough, I did a video series on building Bitcoind.exe and the static libraries (on MSVC++) all in NDEBUG (release) mode.
See
https://www.youtube.com/playlist?list=PLFnWb0ttBBMLyUuniLp3PJ5Mn4tVUlliZ
Notice that the NDEBUG release mode is featured, and I even run it!
Lastly what does that say about building Bitcoin-qt in release mode? Should one or not??
There is also a video on building an alternate coin-qt.exe in release mode (gcc version) and running it! See
https://www.youtube.com/watch?v=C8GvHpjbAnM
assert() should have no side effects, that is the problem.
See
http://books.google.com/books?id=L5ZbzVnpkXAC&pg=PA72&lpg=PA72&dq=Gotcha+%2328+Side+Effects&source=bl&ots=Rn15TlPmje&sig=tymHqta0aSANwaM2GaXC-1Di_tk&hl=en&sa=X&ei=uVKNU47fCcvTsAT6goHIBA&ved=0CCAQ6AEwAA#v=onepage&q=Gotcha%20%2328%20Side%20Effects&f=false
a
great book, BTW. Everyone who thinks they know what they are doing
when they write C++ should read this book! They will realize that they
don't know Jack
Why weren't these and all the other examples of amateur, i.e., non-professional, software fixed way back in version 0.3.0 in 2010, before any more releases were done? And why were these and other sub-standard coding practices continued and expanded in later releases, right up until the present?
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140603/194feac4/attachment.html>

2023-06-07 15:18:47

- reply

📅 Original date posted:2014-04-17
📝 Original message:________________________________
...
Message: 4
Date: Wed, 16 Apr 2014 21:43:10 +0200
From: Adam Back <adam at cypherspace.org>
Subject: Re: [Bitcoin-development] Warning message when running wallet
in Windows XP (or drop support?)
To: Wladimir <laanwj at gmail.com>
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Message-ID: <20140416194310.GA11552 at netbook.cypherspace.org>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Not to get snarky or OS elitist but as I understand it windows security,
even during its support period has been measured in low digit number of days
in the year when is NOT an outstanding known remote root compromise or
combination of remote user compromise + priviledge escalation. Add in
phishing, watering holes, malware and the average windows computer is
probably compromised a dozen times over. Apparently for sometime it was not
easily possible to secure it install boot - install OS, connect to network
to download security updates, IP range scanned and compromised faster than
you can patch it.
Adam
...
________________________________________________________________
Right.
The trick was to install off line, add your own (free or commercial s/w firewall) then
connect, behind a router that had no port forwarding, etc. Hell before cheap
routers I ran one Win95B as I remember, using ICS to a hub that feed my LAN and in front
was a dialup and a cable modem. Atguard was the S/W firewall, worked great and
never was penetrated.
And if one used IE for anything, or any form of Outlook one was and still is a fool.
There are still fools who think that their Windows Vista, 7, 8 or 8.1 is safe because
MS updates it days, weeks or longer after an exploit is found/exposed/known... And
they feel that they can install and run anything anyone says is OK? No firewall can protect
against shall we say digital naivety.
Ah what fools these mortals be. Then there are others that have never used IE,
never installed/enabled Outlook, never enabled UPNP &/or, DCOM; never executed
"unknown" s/w, and always had their own s/w firewall on, long before MS even
thought of "Windows Firewall". Does anyone (other than zone alarm) check for
data leaving one's computer "unexpectedely"? Those machines could run Win95B,
Win98SE, NT4, Win2K, XP pro long past MS's "cut off date" and barely notice
anything. The show stopper is usually the browser (FF) or Adobe flash or pdf
demanding more OS functions, usually so that they can perform more functions
more poorly, I'm sorry to say.
Check the live desktop OSs connected to the internet, by version at
Market share for mobile, browsers, operating systems and search engines | NetMarketShare
Market share for mobile, browsers, operating systems and search engines | NetMarketShare
Market share for mobile, browsers, operating systems, search engines and social media. Mobile market share and desktop market share data.
View on www.netmarketshare.com Preview by Yahoo
last I checked, XP was still ~29% and all Windows versions, ~90%
Computer safety, like driver safety, has more to do with the knowledge and skill
of the operator/driver, than the "newness" of the car/computer. A good driver/computer
user, never gets into a situation that he/she can't repair/reverse/prevent/recover from
etc. Drive/run a motorcycle/computer and you will learn defensive driving/computing
really fast or be roadkill on the highway/digital highway.
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140416/64a7443b/attachment.html>

2023-06-07 15:11:01

- reply

📅 Original date posted:2013-12-22
📝 Original message:________________________________
From: "bitcoin-development-request at lists.sourceforge.net" <bitcoin-development-request at lists.sourceforge.net>
To: bitcoin-development at lists.sourceforge.net
Sent: Friday, December 20, 2013 12:33 PM
Subject: Bitcoin-development Digest, Vol 31, Issue 37
Send Bitcoin-development mailing list submissions to
bitcoin-development at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Hello all,
Is the dual elliptic curve algorithm mentioned in
http://www.theguardian.com/world/2013/dec/20/nsa-internet-security-rsa-secret-10m-encryption
from 2 days ago, of any concern to Bitcoin? I only ask, since I don't follow the field closely, but I see
http://en.wikipedia.org/wiki/Elliptic_Curve_DSA
Is this a concern for Bitcoin, or is this all "old news"?
Ron
_____________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
End of Bitcoin-development Digest, Vol 31, Issue 37
***************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131222/c4d3f9a4/attachment.html>

2023-06-07 15:07:51

- reply

📅 Original date posted:2013-10-23
📝 Original message:________________________________
From: "bitcoin-development-request at lists.sourceforge.net" <bitcoin-development-request at lists.sourceforge.net>
To: bitcoin-development at lists.sourceforge.net
Sent: Wednesday, October 23, 2013 3:38 AM
Subject: Bitcoin-development Digest, Vol 29, Issue 20
Send Bitcoin-development mailing list submissions to
bitcoin-development at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
2. Re: Revisiting the BIPS process, a proposal (Peter Todd)
----------------------------------------------------------------------
....
On Tue, Oct 22, 2013 at 09:34:57AM +0200, Martin Sustrik wrote:
> On 22/10/13 09:03, Gregory Maxwell wrote:
> > On Mon, Oct 21, 2013 at 11:59 PM, Jean-Paul Kogelman
> > <jeanpaulkogelman at me.com> wrote:
> >> Have you seen: https://en.bitcoin.it/wiki/Protocol_specification ?
> >
> > Take care, the information in the wiki is woefully incomplete.
>
> Imagine myself, with no prior knowledge of Bitcoin looking at the
> document. It starts with "Hashes". What hashes? No idea what's going on.
> Etc.
>
> Now compare that to a well written RFC. It starts with introduction,
> description of the problem, explains the conceptual model of the
> solution, then dives into the details. There's also Security
> Considerations part in every RFC that is pretty relevant for Bitcoin.
>
> As I said, I am willing to help with writing such document, it would be
> a nice way of learning the stuff, however, help from core devs, such as
> answering question that may arise in the process, or reviewing the
> document would be needed.
Writing such RFCs is dangerous due to the consensus nature of Bitcoin -
it makes people think the standard is the RFC, rather than the code.
I hear one of the better intros to Bitcoin is the Khan academy videos,
but I've never watched them myself. Once you understand how it works,
start reading source code - the Bitcoin codebase is actually really
simple and readable. However remember that the implications of that
codebase are anything but simple; there's lots of reasons to think
Satoshi himself didn't understand Bitcoin all that well, even by the
time he left the project.
--
'peter'[:-1]@petertodd.org
000000000000000f155e7a648e84a83589048ae1cacb0c60bfce2437553b6af4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
------------------------------
I feel that I must respond to the statements that
1.
the Bitcoin codebase is actually really
simple and readable.
2.
However remember that the implications of that
codebase are anything but simple; there's lots of reasons to think
Satoshi himself didn't understand Bitcoin all that well, even by the
time he left the project.
On point one: if it was/is so readable, why hasn't it been documented better, if at all?
Why haven't the obscure names of important items been globally searched and replaced?
Why are there still mixed formatting "styles" still in the code. I think it is the fear that C++
is so brittle, that one change may bring the whole house of cards down.
I feel that it is the language (C++) that is hindering the expression of ideas in the code.
This goes to your point two about Satoshi's understanding. I think just the opposite:
that he knew what he wanted but that C++ hindered him in expressing and implementing it.
I think that if anything, C++ was what Satoshi "didn't understand all that well".
But then who does understand C++, really? See
https://groups.google.com/forum/#!msg/comp.lang.lisp/7xCvdzijzgU/4xCFzLc3d5EJ
and the quote:
Whenever I solve a difficult problem with C++, I feel like I’ve won a bar fight. — Michael Fogus
I don't think readability is attainable easily in C++. It requires intentionally writing so that
others may understand your code. How many programmers have ever done that? And this
is like swimming upstream in C++, where things are designed to be hidden!
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131023/0829f006/attachment.html>

2023-06-07 15:07:13

- reply

📅 Original date posted:2013-10-03
📝 Original message:I only bring this up here since I can't raise https://bitcointalk.org? Perhaps it runs on the silk road servers:)
Upon looking at the 0.8.5 & earlier code for CDB:Rewrite(), in the files db.h and db.cpp, you will notice that in db.h it is declared bool static, but in db.cpp it isn't. Is this a problem? Or a feature? Or nothing at all?
Furthermore, it is called only in wallet.cpp -->CWallet::EncryptWallet() but its return value is ignored? Again, intentional or a bug or a feature or a ...?
Now CWallet::EncryptWallet() is called by AskPassphraseDialog::accept() and WalletModel::setWalletEncrypted()and they seem very interested in what CWallet::EncryptWallet() returns. Could this be involved in some old issue with wallet encryption on bitcoin-qt 0.8.1?
There seems to be plenty of this kind of "suspicious" code to ferret about in, with one's IDE during quiet moments. Amusing is to follow return 0 and return 1 to try and infer their meaning, their intent?
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131002/ad22c996/attachment.html>

2023-06-07 15:07:05

- reply

📅 Original date posted:2013-09-30
📝 Original message:Hello
Is it required, presumed, assumed, coincidence, chance or irrelevant that the three different databases in bitcoin:
1. the network addresses database, reflected in peers.dat
2. the levelDB block chain database (blocks/blknnnnn.dat, blocks/revnnnnn.dat, blocks/index/nnnnn.sst et al, chainstate/nnnnn.sst et al)
3. the Berkeley DB wallet database (db.log, wallet.dat, database/log.nnnnnnnnn1)
are all in the "datadir" directory?
I only ask since it would seem that a more mature (?) bitcoind or bitcoin-qt would optionally, like the three (databases) in separate paths or drives, etc. It would seem easier to transport, backup etc. the pieces one wants. I find the block chain database is the most important (time consuming), because of its size, to duplicate and transport in order to backup. This also attacks the "Criticism" section in
https://en.bitcoin.it/wiki/Bitcoin-Qt
The first question is: can one backup by just looking at the dates, and just back up those files with the equal or newer dates, and the "log, current and manifest" files? An initial then incremental backups, as it were.
I am thinking of the frailties of data on OS's such as Windows in the hands of the "less than adept" shall we say. Also if one takes part in backing up one's data, one may actually have some idea where it is!
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130929/4304e379/attachment.html>

2023-06-07 15:06:54

- reply

📅 Original date posted:2013-09-18
📝 Original message:Hello,
Has everyone seen
http://www.coindesk.com/bitcoin-gaining-market-based-legitimacy-xbt/
Bitcoin has its own ISO currency code.
Ron
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130917/cf29536e/attachment.html>

2023-06-07 15:06:29

- reply

📅 Original date posted:2013-08-23
📝 Original message:________________________________
Message: 6
Date: Thu, 22 Aug 2013 17:30:13 +0200
From: Wladimir <laanwj at gmail.com>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
bitcoind
Message-ID:
<CA+s+GJC4o5V5p+FY+bgWVUt5umebn4_37bTihfX2q1GF05S=VA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Aug 22, 2013 at 3:33 PM, Mike Hearn <mike at plan99.net> wrote:
> That would be annoying for testing. Regtest mode allows you to create a
> new block by just running "setgenerate true" (it switches itself off after
> creating a block). If you had to set up a complicated set of separate
> programs just to do regtest mode that'd be a step backwards, IMO.
>
There is some consensus that when the internal miner is to be removed, a
simple miner should be packaged with the main repository as separate
program (the "reference miner"?). The only change is that it does no longer
need to burden the core code
(see also the discussion here: https://github.com/bitcoin/bitcoin/pull/2917).
Wladimir
__________________________________________________________
I see no burden to the code when it is not mining, if that is what you mean by
burden. The miner code's hashes/sec are a function of how much CPU time it
gets. When I am gcc compiling, I see the hashes/sec drop, but bitcoind keeps
up easily side by side with http://blockchain.info/ latest transactions and
new blocks. And I only have a single core AMD Athlon 1.8GHz cpu.
I would hate to admit how many browser windows and tabs I have open too,
and an IDE (LOL)!I will admit that I have modified the miner code a little,
to use (potentially) every allowable nonce and to check for a new block
in a timed fashion and be less aggressive, 8 bytes of 0 instead of 4, in checking
for a potential solution.
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130823/9f649a6f/attachment.html>

2023-06-07 15:06:24

- reply

📅 Original date posted:2013-08-21
📝 Original message:Message: 1
Date: Mon, 19 Aug 2013 14:07:46 -0700
From: Gregory Maxwell <gmaxwell at gmail.com>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
    bitcoind
To: "Goss, Brian C., M.D." <Goss.Brian at mayo.edu>
Cc: "bitcoin-development at lists.sourceforge.net"
    <bitcoin-development at lists.sourceforge.net>
Message-ID:
    <CAAS2fgQtGg+SxRc7Byw0_L3NpEudPTtBpmnKYt-+7VEVSnKZaQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 19, 2013 at 1:22 PM, Goss, Brian C., M.D.
<Goss.Brian at mayo.edu> wrote:
> What if we have a massive (like many orders of magnitude) drop in network harsh rate? Might such a function be useful to salvage the (non-functioning) network? Same for IRC bootstrapping. How do we pick ourselves up off the ground in case of the equivalent of a great depression in network hash rate (or some jerk spending $100M just to drive the difficulty up and then turning his hardware off?).
[Aside: When replying to the digest, please try to trim it]
It appears that we will soon be at a hashrate where all the desktop
CPUs in the world couldn't really make a dent in it... certainly not
desktop cpus using the slow integrated cpu miner, which is much slower
than external optimized cpu miners.
But this is why I suggest packaging up a modern mining tool that
supports CPU/GPU/FPGA/ASIC mining against a current bitcoind. Doing so
would reduce the difference between testnet and mainnet, and provide
an actually useful tool for contributing directly.
Though again, I note, that Jeff's patch doesn't actually remove the
integrated miner (I think it should?). Just the getwork support for
external miners which don't use getblocktemplate... and if you're
going to download one of those you could go download bfgminer instead.
Message: 5
Date: Tue, 20 Aug 2013 01:02:41 +0200
From: Andreas Schildbach <andreas at schildbach.de>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
    bitcoind
To: bitcoin-development at lists.sourceforge.net
Message-ID: <kuu86a$ii5$1 at ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1
On 08/19/2013 10:34 PM, Jeff Garzik wrote:
>> FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned
>> people that getwork will be removed in the next major version. Pooler's CPU
>> minerd which supports both sha256d and scrypt recently grew stratum support.
>> Perhaps he could be convinced to add GBT support too, which would help this
>> goal of completely removing the internal miner and getwork.
>
> The internal miner is still actively used for testnet, here.
Here, too. If I'm too impatient to wait for the next block that is.
I think it'd be a pity if the easy way to mine blocks would be removed.
__________________________________________________________________
My comments start here.
I agree with Andreas. The mining code in bitcoind & qt is not so hard to improve
and even use, such as it is. I am sorry to say that using bfgminer is one big, complicated install,
on Windows at least, AFAICT from looking at the github code bfgminer-2.10.11.zip.
Seems much more work than I had bringing up bitcoind/qt from the "ground up" on my
Windows machine. And the mining code is only a small part of the end of main.cpp .
I don't see it harming the rest of the code when I run it in the daemon or Qt.
Can't one mine "from a distance" using the RPC interface now anyway, even with the
code still there?
I assume that you all would like to have a "seething horde" of new Windows users
running and using bitcoin? I know that I sure am trying to make that happen. I think
an integrated, wallet, miner, full node on the net (which I presume bitcoind/bitcoin-qt
are) is the first step, and maybe should always exist? Though other variations could
exist too. Could even be a compile Define, like USE_PNP for example, to strip off
this or that?
So for me, if I want to mine, just because my solar powered laptop has some free cpu
cycles, I don't mind having a "snow ball's chance in hell" of solving the "next" block. At
~0.5 MHPS on my CPU it takes me ~2.5 hours to go through all (2^32)-1 nonces for a
tentative new block, with a particular set of transactions. I only can get "deep" into
the nonces when one of those +30 minute blocks comes by! And they do from time to time.
I think forcing users to have two computers to mine, or run two programs, is "pushing it"
so to speak? And do I also see some wallet removal code being conjured up on git hub?
I think the beauty that is Satoshi's original bitcoin idea should be kept, together in one
package. If the code was properly commented, formatted, organized , etc.etc., which I
understand is "postponed" when one is "in the zone" writing code, then I think
separating the wallet code or mining code, ought to be much easier.
I feel that the dirty task of at least "calling things by their right names" (as said in the
Chinese proverb) should be done first. As an example calling the main Berkeley
database environment class instance of the wallet an abbreviated 5 lower case
letter cryptic "bitdb" reminds me of the time when ram and disc storage were
"dear" and compilers couldn't handle "long" names! I would call it something
much grander! Only 46 places to change ! Also the member DbEnv dbenv
is equally underplayed as it is the main actor in the play! Let's not even mention pdb
being used both for a BerkeleyDB CDB.Db* and as an albeit private leveldb DB*.!
Pointers that aren't called pSomething, un-commented/un-documented magic numbers
where commented constants should be, and on and on it goes.
So I just sit back doing the clean up on 0.8.1, then .0.8.2, now 0.8.3 while you
architects march ahead oblivious to the cryptic minefield of code that exists underneath :)
My aim is to first clean up the code enough so that I can understand it. Then eventually,
take it over to a real Windows project/solution where it can be made into an executable
that is palatable for the masses.
Getting off soapbox now and retreating to the back...(bitcointalk.org that is)
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130821/78e10999/attachment.html>

2023-06-07 15:02:05

- reply

📅 Original date posted:2013-05-26
📝 Original message:From: <bitcoingrant at gm...> - 2013-05-16 10:02
One of the primary upcoming priorities for bitcoin’s infrastructure, beyond the bloom filter, will be the continued modularization of the system.
Here at the Bitcoin Grant, we would like to jump start this development with a financial incentive and initiate an ongoing conversation on how we can work together towards developing a smarter, more efficient system of tomorrow, today.
Up for grabs: 500 bitcoins or $500,000; whichever is greater.
Taking on a project of this scope is a highly intensive, technical undertaking and we believe excellent developers should be compensated as such, especially when it comes to open source projects.
One of the main goals will be to separate the wallet from the node, as we have already done with mining. This way, the wallet, which will only hold private keys and create transactions, would pass transactions directly to a relay node, based on the bloom filter. Meanwhile, the block node will maintain the block chain and validate and relay new blocks.
Such developments would significantly strengthen the system. Modularization would make cancer attacks less likely and increase the node count, which, currently, is fairly low.
This is by no means is a feature request, merely ideas as to initiate a discussion. We welcome any feedback or suggestions. And of course, let us know if you would like to contribute to this project by submiting a grant proposal.
http://bitcoingrant.org http://bitcoingrant.org/&lang=en
Hello
I don't know if this is the proper method of replying or even if
I am allowed to reply!
Modularization can have many meanings, depending upon one's past!
The code is somewhat compartmentalized/modularized now. But if one
forces complete separation of the parts, with a 'loose coupling',
etc., I find that the performance tends to suffer and the size
increases.
In the Java world there is the notion of refactoring one's code.
This would be too much, I think, in this case. When I developed
with a team and alone, I would make what used to be called
'step-wise refinements' on existing working code. To me, one of
things this meant was doing a one to one transformation of the
source code, in such a way as to have the identical, byte for
byte, executable file, but a 'better' set of source files. A
similar process would seem appropriate here. Especially since
there is much in the code that I don't understand :)
As to 'separating the wallet from the node', do you mean allowing
the wallet.dat file to be anywhere, and not restricted to the 'OS default'
or 'datadir' directory? If so, I have done that with no change to the
current behavior, and also the wallet.dat now can have any legal
filename too! I haven't tested it yet on bitcoin-qt, but it runs
on bitcoind. I am still 'ramping up' on github to get the code into
view. After testing on bitcoin-qt of course.
What may I ask, is a cancer attack?
If any of this inappropriate, forgive me.
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130526/e04fd700/attachment.html>