steve [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-07-23 to 2013-04-09
💬 Posted a total of 17 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 11:45:14

- reply

📅 Original date posted:2013-04-09
📝 Original message:On 09/04/2013 15:39, Caleb James DeLisle wrote:
> Agreed on the legality aspect but another case which is worth considering is
> what anti-virus software might do when certain streams of bytes are sent across
> the tcp socket or persisted to disk.
Do you mean firewalls or something like snort or other deep packet
inspection for the tcp sockets statement? I dont see much of an issue
with either.
set up your own private testnet and have a play with this
http://www.eicar.org/83-0-Anti-Malware-Testfile.html
The eicar test virus.
> Perhaps worth contacting an AV company and
> asking what is the smallest data they have a signature on.
I have tried a few ways of getting the eicar string into the blockchain
(on a private testnet) and getting it flagged by AV, however it is a bit
tricky (the getting it flagged bit). and tbh you would exclude the
bitcoin directory and runtime from antivirus scans so i stopped bothering.
I am making vague assumptions about using windows with antivirus. (and
linux for deep packet inspection, but the idea is the same whatever.)
I found no greater attack surface area (in the blockchain) than
cookies... thinking about it a bit more, there is a bit more potential
as a bounce pad/egg drop location but not much - no heap spraying as
such, or d/c tors, or heap header structs, etc. Im sure someone is sure
to come up with something very clever tho. just not me.
cheers,
steve
>
> Thanks,
> Caleb
>
>
> On 04/09/2013 06:42 AM, Mike Hearn wrote:
>> OK, as the start of that conversation is now on the list, I might as well post the other thoughts we had. Or at least that I had :)
>>
>> It's tempting to see this kind of abuse through the lens of fees, because we only have a few hammers and so everything looks like a kind of nail. The problem is the moment you try to define "abuse" economically you end up excluding legitimate and beneficial uses as well. Maybe Peters patch for uneconomical outputs is different because of how it works. But mostly it's true. In this case, fees would never work - Peter said the guy who uploaded Wikileaks paid something like $500 to do it. I guess
>> by now it's more like $600-$700. It's hard for regular end users to compete with that kind of wild-eyed dedication to "the cause".
>>
>> The root problem here is people believe the block chain is a data structure that will live forever and be served by everyone for free, in perpetuity, and is thus the perfect place for "uncensorable" stuff. That's a reasonable assumption given how Bitcoin works today. But there's no reason it will be true in the long run (I know this can be an unpopular viewpoint).
>>
>> Firstly, legal issues - I think it's very unlikely any sane court would care about illegal stuff in the block chain given you need special tools to extract it (mens rea). Besides, I guess most end users will end up on SPV clients as they mature. So these users already don't have a copy of the entire block chain. I don't worry too much about this.
>>
>> Secondly, the need to host blocks forever. In future, many (most?) full nodes will be pruning, and won't actually store old blocks at all. They'll just have the utxo database, some undo blocks and some number of old blocks for serving, probably whatever fits in the amount of disk space the user is willing to allocate. But very old blocks will have been deleted.
>>
>> This leads to the question of what incentives people have to not prune. The obvious incentive is money - charge for access to older parts of the chain. The fewer people that host it, the more you can charge. In the worst case scenario where, you know, only 10 different organizations store a copy of the chain, it might mean that bootstrapping a new node in a trust-less manner is expensive. But I really doubt it'd ever get so few. Serving large static datasets just isn't that expensive. Also, you
>> don't actually need to replay from the genesis block to bring up a new code, you can copy the UTXO database from somewhere else. By comparing the databases of lots of different nodes together, the chances of you being in a matrix-like sybil world can be reduced to "beyond reasonable doubt". Maybe nodes would charge for copies of their database too, but ideally there are lots of nodes and so the charge for that should be so close to zero as makes no odds - you can trivially undercut someone by
>> buying access to the dataset and then reselling it for a bit less, so the price should converge on the actual cost of providing the service. Which will be very cheap.
>>
>> There was one last thought I had, which is that if there's a shorter team need to discourage this kind of thing we can use a network/bandwith related hack by changing the protocol. Nodes can serve up blocks encrypted under a random key. You only get the key when you finish the download. A blacklist can apply to Bloom filtering such that transactions which are known to be "abusive" require you to fully download the block rather than select the transactions with a filter. This means that people
>> can still access the data in the chain, but the older it gets the slower and more bandwidth intensive it becomes. Stuffing Wikileaks into the chain sounds good when a 20 line Python script can extract it "instantly". If someone who wants the files has to download gigabytes of padding around it first, suddenly hosting it on a Tor hidden service becomes more attractive.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 10:35:51

- reply

📅 Original date posted:2012-10-11
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On 11/10/2012 16:46, Gavin Andresen wrote:
> Any progress on a release candidate QA sanity testing plan?
essentially yes - in all seriousness, I have come around to your way
of thinking, it is not worth arguing about. we end up in the same place.
:) nothing is final though. I will be opening it up to Arklan in a bit
(I have a pool match tonight so after that depending on how drunk i
get.) and to another couple of people who have emailed me off list who
would like to be involved in testing.
I have not created any new tests for the new stuff. this is still the
noddy stuff.
It covers everything that needs to be covered for a newbe or someone
upgrading clients.
and it is in many formats the moment (from wiki to test runner) none
particularly useful (about to import into mantis, just fiddling with
the fields so it does testcases)
I have been trying to separate the tests into what can be automated,
recorded and checked by watching the video and have sanity checks
along the way (published sha and sha256 of the binaries match) -
(obviously the test is flagged to be run manually if there is any doubt)
I did take myself outside and had a little sit down and talk to
myself. Lets not run before we can walk. I will still keep the grand
ideas, but they are on the back burner. (I got called a blue skies
thinker today, wtf is one of them? I said smiled and said thanks)
the main things we make sure we get tested right are all the GAT tests
in bettermeans.They are more protocol based and should be run against
all releases. Lets nail that process, peer review it, retest it, then
use that as a basis for The Process. I will temper my zealousness. I
realise that I can come across as bullish or even aggressive in my
emails. I never mean too.(unless I say I am. That is not an excuse
for my poor english language skills.)
But I still think that the people running the tests should have the
greatest say in what software is used. So once you have access to the
server and the cases feel free to install your favourite software and
see what other people think.
but we have a vague structure and workflow so it will be interesting
to see how it works out.
the git integration will be trivial.
please email me if you would like access. I am off out in 15 mins but
I promise to have all access sorted by tomorrow. I am only using 3
vps to show example testing and test platforms. I would like it if we
could get a technet license with the donations so far, I use mine (and
my msdn) for work.
also check out bettermeans for the formats that I will be using.
bollocks. bollocks. bollocks
https://secure.bettermeans.com/projects/4180
bye bye bettermeans. how we never knew ye.
Gavin, can we get a bitcoin-test mailing list please. it would be
used for discussion of testing, tools, ideas, chatter, etc. it would
not be a place reporting bugs... This list seems very focused and I
always feel like I am disrupting things with my emails about test. I
dont mind admining the list. I would rather be vocal and inclusive, I
dont think the dev list is the place for that.
>
>
> Bitcoin version 0.7.1 release candidate 1 is now available from:
> http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/test/
>
> This is a bug-fix minor release.
>
> New features ------------
>
> * Added a boolean argument to the RPC 'stop' command, if true sets
> -detachdb to create standalone database .dat files before shutting
> down.
>
> * -salvagewallet command-line option, which moves any existing
> wallet.dat to wallet.{timestamp}.dat and then attempts to salvage
> public/private keys and master encryption keys (if the wallet is
> encrypted) into a new wallet.dat. This should only be used if your
> wallet becomes corrupted, and is not intended to replace regular
> wallet backups.
>
> * Import $DataDir/bootstrap.dat automatically, if it exists.
>
> Dependency changes ------------------
>
> * Qt 4.8.2 for Windows builds
>
> * openssl 1.0.1c
>
> Bug fixes ---------
>
> * When running -testnet, use RPC port 18332 by default.
>
> * Better detection and handling of corrupt wallet.dat and
> blkindex.dat files. Previous versions would crash with a
> DB_RUNRECOVERY exception, this version detects most problems and
> tells you how to recover if it cannot recover itself.
>
> * Fixed an uninitialized variable bug that could cause transactions
> to be reported out of order.
>
> * Fixed a bug that could cause occasional crashes on exit.
>
> * Warn the user that they need to create fresh wallet backups after
> they encrypt their wallet.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQdwWxAAoJEFvEB9dQFvtQiuMIAJpdu23biq56apMO/KfqmSB0
kQPflDD2XMxTknfqzRs35/EFgL0mJ/cYfY3qTW9JOWL/cit4ieq2EA4P3uQeFFDC
NCxIuDxOzOIaZ+SzRZENXdpVWKRNP1RgUCANm3YfrJBlavr9a/om36nP1IK0W4MB
QcPXrrZvipt1xhx1G/V6NvYbZA3lTAJBFzuz2oRJNwlYoExJFw8EHBypa67BUNOj
NDg1Wu5Ppyq7dZbgfhw4HxIIvgwn/vaSm/tX6HJxyKN7HUJIbIyQrSbPGUvWCsBW
KI6e88DPdG0x0ltqVXja+51n3F9G4H/zTIbB0GyiRDn0GcGwi/GolF5PAgz0tR8=
=zniH
-----END PGP SIGNATURE-----

2023-06-07 10:34:05

- reply

📅 Original date posted:2012-10-03
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think he had a typo in the CC. here is a forward of the email.
You will have to work out the indentations yourselves :)
- -------- Original Message --------
Subject: Re: [Bitcoin-development] Bitcoin Testing Project
Date: Tue, 2 Oct 2012 22:01:19 -0700
From: Peter Vessenes <peter at coinlab.com>
To: steve <steve at mistfpga.net>
On Tue, Oct 2, 2012 at 6:15 PM, steve <steve at mistfpga.net> wrote:
> On 01/10/2012 17:52, Peter Vessenes wrote:
>> I'm a big proponent of a testing project.
>
> I am very happy to hear this, however, your actual words are
> slightly evasive. I do not expect you to be up to speed on this.
> Gavin started a project called 'the bitcoin testing project' This
> project solicited donations, about 80 coins last time I checked.
> However these 80 odd coins were donated to 'the bitcoin testing
> project' This would seem to be an official bitcoin (both protocol
> and client) testing project. I signed up to work on this, and
> organise as much as i could of this. for various reasons I did not
> manage to do the testing I wanted to on 0.7 i over committed
> myself.
>
> Are the donations solicited for the 'bitcoin testing project)
> funds going to be given to 'the foundation'?
>
>
> Not as far as I know; sounds like they should go toward testing.
>
>
> Does the foundation support 'the bitcoin testing project'? does
> the foundation have any involvement with 'the bitcoin testing
> project'?
>
> I personally support the idea of a testing project. I would like
> the Foundation to fund it if it can't crowdsource funding from the
> forums; sounds like so far the support hasn't been enough to get
> all the work done. The Foundation has no formal role with the
> bitcoin testing project that I'm aware of.
>
>
>
>
>> I think if one could self organize that Gavin and team wanted to
>> bless we could put up some BTC as bounties or funding. We won't
>> have our heads around the foundation budget for a few more
>> weeks, but self-organization is often slower than budgeting. :)
>
> Im ready to go, more or less. Please check out the links in my
> previous emails. I have over 400 testcases (8 platforms * 50
> release tests) - Also I am not sure what you mean by bless, I take
> it that is a euphemism for pay?
>
> Wow, that's awesome! I use bless to mean "Gavin saying that it
> sounds good."
>
>
> I have tried my hardest to get bettermeans to work, but it doesnt.
> It does show quite a lot of work that I have done though. If you
> were to say to me, 'steve, by monday we need end to end,
> requirements based testing' It would be done. (I have already spent
> over 4 months on this) Leaderless leadership is something I am
> having a hard time with, bettermeans is excellent at this. But I
> have found very little in regards to voting and polling that
> integrates with the project in an effortless way like bettermeans.
>
> I understand that the budget from the foundation is something that
> needs to be worked on and organised. I offer my services in this
> area (qa only). I would be happy to submit my cv and refs for
> this, if required.
>
> I am now feeling frustrated and useless. has my last 4 months of
> work been for nothing? it feels like it. I know I bang on about
> processes but they are sorted, you can only attract talent like
> Arklan if he has a process to follow. i feel like a broken record.
>
> I'm a little late to this conversation, so I don't know what to say
> in response. I will answer your questions below, though.
>
>
> tl;dr version 1 - Will donations to the 'bitcoin testing project'
> as started by gavin going to be given to the foundation?
>
>
> I don't expect so, although we'd take them if whoever is in charge
> of the testing project wants to do so. I'd expect that if the
> testing project is good and community approved and supported by the
> dev team the funding flow would go the other way, but we'll need to
> wait for budgets to get finished.
>
>
> 2 - Is the work bill hees and myself going to be binned?
>
>
> I have no idea whatsoever, I would guess that's up to you and bill
> hees and the dev team.
>
>
> 3 - I feel like I have the knowledge and drive to push this, but I
> cant do it on my own.
>
>
> Totally understand the feeling!
>
>
> 4 - Is bill or I entitled to any of the cash raised for 'the
> bitcoin testing project'
>
>
> I have no idea what the bitcoin testing project finance situation
> is.
>
>
> 5 - Do I have to join the foundation to have a say in how the
> project (testing) is done?
>
>
> Nope
>
>
> 6 - sorry for being so mercenary, but am I going to receive any
> coin for work I have done?
>
>
> Ditto to above
>
>
> 7 - It really probably is the time for a bitcoin-test list to
> appear. Is there anything I can do to make this happen?
>
> I don't have much to do with this.
>
>
>> This is just my opinion, but I would like very, very much to
>> move the current specification into unit tests so that anyone
>> could validate their alternate bitcoin implementation. This is a
>> lot of work, some of which has been done, much of which hasn't.
>
> have a look at the stuff in bettermeans. I personally think we can
> go a step further and publish guidelines (similar to RFC's and all
> the tests that we would do against a ref client)
>
>
> Cool, I will check it out. I agree with the RFC oriented approach,
> or perhaps a canonical test suite for validation and verification.
>
>
> But I dont want to waste any more time on stuff that is going to
> be ignored, life is short.
>
>
>> So, my two cents, plus an offer to bring it up at our next
>> budgeting meeting.
>
> I accept that offer. and I really appreciate it. I have some more
> questions I would like you to ask in regards to QA. (Gavin and I
> skyped about this a while ago and we didnt really come to a
> resolution, weworked out the problems though ;) )
>
> I have an exceptionally detailed qa process (based off the game
> certification process) - but I have gone on about this at length
> in previous messages.
>
> I thank you for your email and your involvement with this, but do
> you think we are closer to getting stuff tested? call my bluff...
> Not one person has asked for login details to my proposals - and i
> even have a bugzilla version now.
>
> I need to sleep. sorry if i rambled.
>
> nite nite,
>
> steve
>
>
> Thanks for all the details. I'm trying to go into extra detail in
> my response to you because people are still figuring out the
> Foundation's situation with all things Bitcoin. I can't offer you
> any promises for your future, but I'm personally really psyched to
> hear about these tests. I'll let other more knowledgeable folks
> jump in on the technology side of things.
>
>
>
>> Peter
>
>
>> On Mon, Oct 1, 2012 at 7:28 AM, steve <steve at mistfpga.net>
>> wrote:
>
>> On 01/10/2012 14:52, Arklan Uth Oslin wrote:
>>>>> Hi guys.
>>>>>
>>>>> So, as I mentioned on the bitcointalk.org forums thread
>>>>> about the foundation, I want to get involved in the QA side
>>>>> of bitcoin development. I've done functional testing in
>>>>> the video game industry for years.
>
>> Nice one, I worked in games for quite a few years. (before
>> getting into finance then pentesting) there are about 6 keen
>> testers now. maybe we should get a bitcoin-test mailing list,
>> where we can discuss stuff without disturbing the dev team.
>
>>>>> I've read all the messages in this thread, but I'm left
>>>>> unclear how I can most effectively and quickly being
>>>>> helping out. Could I get a bit of a directional nudge?
>
>> Great question... for me I feel structure is the most important
>> thing to sort out first. However we desperately need detailed
>> testcases for the release of a new version. - Not too much on
>> the change log stuff, more on the noddy stuff (as gavin points
>> out below), downloading and making sure it works on a non dev
>> machine, make sure the wallet isnt overwritten, etc.) doing games
>> qa I imagine this would be an ideal place for you to start. I
>> have a MSDN and TechNet licence so if you need some reference ms
>> virtual machines I can help you out.
>
>> However we need some testcase software. Please check out what
>> was done on bettermeans for the stuff I was planning out...
>
>> It details everything from recompense and testcases. bettermeans
>> kinda died a death though...
>
>> check out:
>
>> Bitcoin over all-
>> https://secure.bettermeans.com/projects/4180/wiki/Page_index
>> discussion https://secure.bettermeans.com/projects/4180/boards
>
>> 0.7 https://secure.bettermeans.com/projects/4256/boards and
>> https://secure.bettermeans.com/projects/4256/wiki
>
>> I still have the testcases, but until we get some proper
>> testcase software I am loathed to publish them in a half arsed
>> format. (they worked well on bettermeans, then just vanished one
>> day...) what testcase software are you familiar with?
>
>> apart from that, what do you feel you can do for the project?
>> how long have you been involved in bitcoin? It may well be
>> worth reading up all the dev stuff on the wiki so you can get you
>> head around how the bitcoin protocol is different from the daemon
>> and qt client. What do you think you can and will enjoy doing?
>> What is your skill set in regard to networking, crypto and
>> operating systems. (not that you need any, in any we still want
>> and need you. :)
>
>> there really is room for you to do whatever role you want, and
>> as little or as much as you want - however funding is now a very
>> tricky issue. so much so that I am not sure I want anything to
>> do with it(distribution of coin based on work.). - I just paid
>> for some logo spec work out of my own pocket (for example). I
>> have some testers i know irl who are willing to work for coin.
>
>> NOTE: This response has nothing to do with the bitcoin
>> foundation. I am not a member of the foundation. I do not speak
>> for them or even probably with them. I am still trying to work
>> out how much qa the foundation should be responsible for, and/how
>> it is supposed to work. I think the games cert process would be
>> ideal for this. This however this a discussion that probably
>> wont have my involvement. (personally I believe that the
>> foundation should publish requirements with example code and
>> testcases for each aspect of the reference client. (on reference
>> platforms - I do not expect many to agree with this though)
>
>> As a side note, what happens to the donations to the bitcoin
>> testing project? do they get moved over to the foundation? this
>> question is bigger than this email. as far as I know they are
>> all on an address Gavin holds. Actually I would like to be
>> involved in any discussions that would impact QA, does this mean
>> I need to join the foundation or just go lone wolf?
>
>> tbh I dont really understand foundations. I always thought they
>> were just a tax dodge.
>
>> Sorry for the long message. :)
>
>>>>>
>>>>> Arklan
>>>>>
>>>>> ---------- As long as there is light, the darkness holds
>>>>> no fear. And yet, even in the deepest black, there is life.
>>>>> - Arklan Uth Oslin
>>>>>
>>>>> I want to leave this world the same way I came into it:
>>>>> backwards and on fire. - Arklan Uth Oslin
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Sep 29, 2012 at 12:26 PM, steve
>>>>> <steve at mistfpga.net> wrote:
>>>>>
>>>>> Hi Gavin,
>>>>>
>>>>> Sorry for the delayed response, I wanted to take a couple
>>>>> of days to reflect on your email.
>>>>>
>>>>> On 26/09/2012 19:09, Gavin Andresen wrote:
>>>>>
>>>>>
>>>>> And their are other methods too.
>>>>>
>>>>>
>>>>>
>>>>> The GUI::Test package for perl will allow this to be
>>>>> greatly automated. (I have done this before on the
>>>>> localisation of photoshop.)
>>>>>
>>>>>
>>>>>
>>>>> this why we need detailed testscripts and plans. so we
>>>>> know what has and hasnt been done. The more boring the task
>>>>> the more work that needs to go into testcase development.
>>>>> This is the area I see as my greatest failing last time. I
>>>>> have a large number of virtual machines and should have at
>>>>> least this work. But we need very detailed testcases.
>>>>> with decent testplans just downloading the software,
>>>>> syncing the block chain, syncing an existing wallet,
>>>>> rescanning the blockchain and verifying the balance would
>>>>> cover a large number of tests. The idea behind having lots
>>>>> of very specific testcases is you get to see what tests
>>>>> have not been run.
>>>>>
>>>>>
>>>>>
>>>>> I understand your concern, however I have taken a couple
>>>>> of days to reflect on this and I still strongly feel that
>>>>> in order to make sure that this sticks, and is still useful
>>>>> in 1 years time we need to lay proper foundations. Those
>>>>> foundations are not word documents, spreadsheets, etc.
>>>>> they are selecting the right tools for the job.
>>>>>
>>>>> We can gain so much benefit from using 3rd party software.
>>>>> (bettermeans would rock if it wasnt rotting)
>>>>>
>>>>> I am sure you could do your coding work just using vi, but
>>>>> an sdk makes it much easier and allows you to work in a
>>>>> more productive manner.
>>>>>
>>>>> I have had a couple of off list emails with some testers
>>>>> and they also feel that it is very important to make sure
>>>>> we have a sound foundation (mantis is so much more than
>>>>> just a bug reporting tool, I see the bug reporting
>>>>> functionality as secondary to the main test run
>>>>> functionality - but it doesnt have to be mantis based, we
>>>>> do need workflow and testcase software though - and proper
>>>>> software for this is much better than just a massive google
>>>>> doc.) however I am checking out some other software that
>>>>> has been recommended. It will be very hard to change 'the
>>>>> process' once we have something we are used too (just look
>>>>> at the current resistance) I promise nothing will change
>>>>> for the dev team. But test does need other tools, and
>>>>> processes.
>>>>>
>>>>> If you feel that strongly that I am going about this the
>>>>> wrong way, I am happy to step back and let someone else
>>>>> sort it out (I will still do all the testing I possibly
>>>>> can). I would feel that this would be a real shame and we
>>>>> have the chance to setup requirements to functionality to
>>>>> tests all with traceability. why not do it right from the
>>>>> start?
>>>>>
>>>>> I will open up my vps' somepoint over the next few days
>>>>> and you can see what I mean. I will setup a fake git
>>>>> project, and sort out the interactions.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>
> ------------------------------------------------------------------------------
>>>>>>
>>>>>>
>
>
>
> How fast is your code?
>>>>>> 3 out of 4 devs don\\\'t know how their code performs in
>>>>>> production. Find out how slow your code is with
>>>>>> AppDynamics Lite.
>>>>>> http://ad.doubleclick.net/clk;262219672;13503038;z?
>>>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>>>>
>>>>>>
>
>>>>>>
_______________________________________________
>>>>>> Bitcoin-development mailing list
>>>>>> Bitcoin-development at lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>
>>>>>>
>>>>>>
> -
>
> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>
>
Got visibility?
>>>>> Most devs has no idea what their production app looks
>>>>> like. Find out how fast your code is with AppDynamics
>>>>> Lite. http://ad.doubleclick.net/clk;262219671;13503038;y?
>>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
_______________________________________________
>>>>> Bitcoin-development mailing list
>>>>> Bitcoin-development at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>
>
>>>>>
>>>>>
>>>
>>>
>>>
> ------------------------------------------------------------------------------
>>>
>>>
>
>
Got visibility?
>>> Most devs has no idea what their production app looks like.
>>> Find out how fast your code is with AppDynamics Lite.
>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>
>>>
>
>
>
>
- --
- ------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQbGSIAAoJEFvEB9dQFvtQw1YH+wW3QDMHHV7kf7ZQXvAswv5T
S2htfdgp1DBYBatoJB9fUU3hgHTEz1UhENH509SjS1/dxHuIxguJkbgmuSdoeB/4
rDuuYzQVcmym/G1YXvmAkCDk5/fUY4RKlCDGLg9MVMpVFhLIr6Jiwxd0NiIqWm9K
aE2bXijiTIRp1sNFxJh5SZTh9/rz1zF8TU3LBWyCegISwyBH2XeIIbVgORoMDBlm
n8yKGwPSg5PaH/eWhXR17OUMPbX6xGlMqTmBo7BZDCwPpZU470rkDsPywsn55mAf
W6EQhFjxpSCnmZwRhrkdM/Le/0ySSUvM4spPu7MlQ6ekGP2gBzzUPbKnTGHzNgQ=
=r57G
-----END PGP SIGNATURE-----

2023-06-07 10:33:31

- reply

📅 Original date posted:2012-10-03
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Peter,
Thank you for your in depth, forthright and professional response. You
have answered my questions. And you have cleared up a lot of
confusion I had in my mind. (and I read ditto as i dont know) I
appreciate the extra information. :)
This is a top post and there is nothing inline so i snipped it.
cheers,
steve
On 03/10/2012 06:03, Peter Vessenes wrote:
> Oops, I accidentally didn't reply-all to Steve. I am ccing my
> detailed response to steve to the list since I think people are
> wondering about how the Foundation fits in; trash the e-mail if you
> don't really care. :)
>
> On Tue, Oct 2, 2012 at 10:01 PM, Peter Vessenes <peter at coinlab.com>
> wrote:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQbGKXAAoJEFvEB9dQFvtQ5QcIAJR0RlkjUb5Xm09eo7wjV2QV
IYXbyOBx6bZWox0wxmbygpPL23grEKxlehavf18Q1S6VjdtFs75K5GV83FZb9KPk
YeB0hz5ht48Ig7uQ3zu7MBCaNerTst+6fQ/k5Uu6l2WKCVwk18WykGrnXMnSTbpM
qONQCc4HQhOm7sgEsJD9KNp73eGZt/BG0hQAa8zLh2rHA0to8TER9nRUUx+mH0uf
Cj58EXKVz5WI5+G31M/4v4UgRRv3Z7efaVbczrvhvv6DZfVkCpuD6t0kt2ZlcFCn
oO1sKD05/VtC7DZxQvPEvvkikOp8onmue0xCJBvDpG269Xr55qNqGM039Yjy80c=
=1NTS
-----END PGP SIGNATURE-----

2023-06-07 10:33:25

- reply

📅 Original date posted:2012-10-03
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/10/2012 03:02, Gregory Maxwell wrote:
> On Tue, Oct 2, 2012 at 9:15 PM, steve <steve at mistfpga.net> wrote:
>> Im ready to go, more or less. Please check out the links in my
>> previous emails. I have over 400 testcases (8 platforms * 50
>> release tests) - Also I am not sure what you mean by bless, I
>> take it that is a euphemism for pay?
>
> Perhaps a bit bluntly here— but since you seem to be rather boldly
> insisting on getting paid:
that is not what i was getting at, nor what i meant at all.I am sorry
it came across this way. Im a bit drunk. (yeah that old excuse) I was
only trying to make an example of the quandary that exists, in what
happens to the current donations. There are far more deserving people
who have a claim on that coin rather than I.
I have stated on more than on occasion (written in public and verbal
with gavin) that I would be willing to work for free. But I would love
to be able to ditch the day job. (however i see that more as services
than mining/testing)
rereading what i wrote yeah, fair play i can see how you read my mail
like that. it wasnt meant to :/ i feel a bit of a turnip. the tone is
not what i meant. it does read pretty mercenary.
>
> With all of this testing where can I find the issues you've
> uncovered? Searching on your name/email in the issue tracker
> reports nothing, likewise I can't find anything in my email (beyond
> abstract discussion of testing).
>
This is a different issue. But I see why you have raised it and I
would like to address it. I personally believe you should earn
bitcoins for writing testcases, executing testcases, passing or
failing test cases. in that order (failing a testcase normally
generates a new one therefore encouraging indepth and recorded
testing.). QA should not be judged based solely on bug reports - this
is unfair and will result in race to report bugs. I have worked on a
few projects that have tried it.
This is one reason we need workflow and testcase software, so we can
measure and compensate people for their work.
As I have stated in previous emails I should have, but for various
excuses did not manage to run a single testcase for 0.7. but I did
setup a frame work, and I know some people did do some good work on
0.7 I believe these people should be compensated from the (limited)
funds the project received... something needs to happen with those coins.
I am sorry you find my emails abstract (and therefore meaningless?)
this is a really confusing time. i dont know if i am doing right from
wrong. I am trying to lead, without leading... i have always preferred
benevolent dictator. I know a number of bitcoin businesses that are
really keen to work with the project, but I have no authority, noone
seems to. Someone should be able to say, nice one, thanks for the
vm's. maybe use $200 worth of coin to get a technet licence, that
gives 10 installs of each ms OS. slipstreaming in the service packs
means you can have whatever era pc you want (and the vps providers
will allow various configuration of vm's...) then even if you do it by
hand you can still do 6 or 7 at once...
as for bug reports, give me 1 week from now (168hrs), lets see what i
can do. (priority, protocol, daemon, qt ref?) but still process is
more important...
I still think that writing and doing testcases should get more coin
than bug reports. but from what I have read, the big bounties will be
paid by the foundation. im not sure if that is true or where i read
it. (protocol level bugs)
it feels like I am wasting peoples time,and I should get back in my
box. so I will.
contact me off list if you want to have a look at the various workflow
stuff i have done.
cheers,
steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQa6pAAAoJEFvEB9dQFvtQ0H8H/jUjvzmsp61w1bmDnHR+KmF4
LNu7WwVLrTvrT8AHSNh3mClWvMM3muJJA7NMb2WthAgVe3jtrGimfreAlstDsObL
XNEcGvU6WN1YosH0MkN7hyDl8jnrDFoiH1P5qsMecuZIxwq7Z0vCOHEJ9DPmZilW
R+G8OmoGcpaeWs9VqXR6zR7Uyz69KaDAQpMRE1GTu3zQP9HSSolciy3ESeJRR9Sd
yO7EcCGdQot80rOG/VIZ0wkOmzGGm1thzYzayD6Zn2eW4Hw+ME1en9ksIbXJFpSv
IdgThEm7p5UuBo0jFkbX4Awrf9hfusZSEGWfhZqdASqqkSBnYqLmWF1sLprDRF8=
=Iv87
-----END PGP SIGNATURE-----

2023-06-07 10:33:18

- reply

📅 Original date posted:2012-10-02
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/10/2012 17:52, Peter Vessenes wrote:
> I'm a big proponent of a testing project.
I am very happy to hear this, however, your actual words are slightly
evasive. I do not expect you to be up to speed on this. Gavin started
a project called 'the bitcoin testing project' This project solicited
donations, about 80 coins last time I checked. However these 80 odd
coins were donated to 'the bitcoin testing project' This would seem to
be an official bitcoin (both protocol and client) testing project. I
signed up to work on this, and organise as much as i could of this.
for various reasons I did not manage to do the testing I wanted to on
0.7 i over committed myself.
Are the donations solicited for the 'bitcoin testing project) funds
going to be given to 'the foundation'?
Does the foundation support 'the bitcoin testing project'? does the
foundation have any involvement with 'the bitcoin testing project'?
>
> I think if one could self organize that Gavin and team wanted to
> bless we could put up some BTC as bounties or funding. We won't
> have our heads around the foundation budget for a few more weeks,
> but self-organization is often slower than budgeting. :)
Im ready to go, more or less. Please check out the links in my
previous emails. I have over 400 testcases (8 platforms * 50 release
tests) - Also I am not sure what you mean by bless, I take it that is
a euphemism for pay?
I have tried my hardest to get bettermeans to work, but it doesnt. It
does show quite a lot of work that I have done though. If you were to
say to me, 'steve, by monday we need end to end, requirements based
testing' It would be done. (I have already spent over 4 months on
this) Leaderless leadership is something I am having a hard time
with, bettermeans is excellent at this. But I have found very little
in regards to voting and polling that integrates with the project in
an effortless way like bettermeans.
I understand that the budget from the foundation is something that
needs to be worked on and organised. I offer my services in this area
(qa only). I would be happy to submit my cv and refs for this, if
required.
I am now feeling frustrated and useless. has my last 4 months of work
been for nothing? it feels like it. I know I bang on about processes
but they are sorted, you can only attract talent like Arklan if he has
a process to follow. i feel like a broken record.
tl;dr version
1 - Will donations to the 'bitcoin testing project' as started by
gavin going to be given to the foundation?
2 - Is the work bill hees and myself going to be binned?
3 - I feel like I have the knowledge and drive to push this, but I
cant do it on my own.
4 - Is bill or I entitled to any of the cash raised for 'the bitcoin
testing project'
5 - Do I have to join the foundation to have a say in how the project
(testing) is done?
6 - sorry for being so mercenary, but am I going to receive any coin
for work I have done?
7 - It really probably is the time for a bitcoin-test list to appear.
Is there anything I can do to make this happen?
>
> This is just my opinion, but I would like very, very much to move
> the current specification into unit tests so that anyone could
> validate their alternate bitcoin implementation. This is a lot of
> work, some of which has been done, much of which hasn't.
have a look at the stuff in bettermeans. I personally think we can go
a step further and publish guidelines (similar to RFC's and all the
tests that we would do against a ref client)
But I dont want to waste any more time on stuff that is going to be
ignored, life is short.
>
> So, my two cents, plus an offer to bring it up at our next
> budgeting meeting.
I accept that offer. and I really appreciate it. I have some more
questions I would like you to ask in regards to QA. (Gavin and I
skyped about this a while ago and we didnt really come to a
resolution, weworked out the problems though ;) )
I have an exceptionally detailed qa process (based off the game
certification process) - but I have gone on about this at length in
previous messages.
I thank you for your email and your involvement with this, but do you
think we are closer to getting stuff tested? call my bluff... Not one
person has asked for login details to my proposals - and i even have a
bugzilla version now.
I need to sleep. sorry if i rambled.
nite nite,
steve
>
> Peter
>
>
> On Mon, Oct 1, 2012 at 7:28 AM, steve <steve at mistfpga.net> wrote:
>
> On 01/10/2012 14:52, Arklan Uth Oslin wrote:
>>>> Hi guys.
>>>>
>>>> So, as I mentioned on the bitcointalk.org forums thread about
>>>> the foundation, I want to get involved in the QA side of
>>>> bitcoin development. I've done functional testing in the
>>>> video game industry for years.
>
> Nice one, I worked in games for quite a few years. (before getting
> into finance then pentesting) there are about 6 keen testers now.
> maybe we should get a bitcoin-test mailing list, where we can
> discuss stuff without disturbing the dev team.
>
>>>> I've read all the messages in this thread, but I'm left
>>>> unclear how I can most effectively and quickly being helping
>>>> out. Could I get a bit of a directional nudge?
>
> Great question... for me I feel structure is the most important
> thing to sort out first. However we desperately need detailed
> testcases for the release of a new version. - Not too much on the
> change log stuff, more on the noddy stuff (as gavin points out
> below), downloading and making sure it works on a non dev machine,
> make sure the wallet isnt overwritten, etc.) doing games qa I
> imagine this would be an ideal place for you to start. I have a
> MSDN and TechNet licence so if you need some reference ms virtual
> machines I can help you out.
>
> However we need some testcase software. Please check out what was
> done on bettermeans for the stuff I was planning out...
>
> It details everything from recompense and testcases. bettermeans
> kinda died a death though...
>
> check out:
>
> Bitcoin over all-
> https://secure.bettermeans.com/projects/4180/wiki/Page_index
> discussion https://secure.bettermeans.com/projects/4180/boards
>
> 0.7 https://secure.bettermeans.com/projects/4256/boards and
> https://secure.bettermeans.com/projects/4256/wiki
>
> I still have the testcases, but until we get some proper testcase
> software I am loathed to publish them in a half arsed format.
> (they worked well on bettermeans, then just vanished one day...)
> what testcase software are you familiar with?
>
> apart from that, what do you feel you can do for the project? how
> long have you been involved in bitcoin? It may well be worth
> reading up all the dev stuff on the wiki so you can get you head
> around how the bitcoin protocol is different from the daemon and qt
> client. What do you think you can and will enjoy doing? What is
> your skill set in regard to networking, crypto and operating
> systems. (not that you need any, in any we still want and need you.
> :)
>
> there really is room for you to do whatever role you want, and as
> little or as much as you want - however funding is now a very
> tricky issue. so much so that I am not sure I want anything to do
> with it(distribution of coin based on work.). - I just paid for
> some logo spec work out of my own pocket (for example). I have
> some testers i know irl who are willing to work for coin.
>
> NOTE: This response has nothing to do with the bitcoin foundation.
> I am not a member of the foundation. I do not speak for them or
> even probably with them. I am still trying to work out how much qa
> the foundation should be responsible for, and/how it is supposed to
> work. I think the games cert process would be ideal for this. This
> however this a discussion that probably wont have my involvement.
> (personally I believe that the foundation should publish
> requirements with example code and testcases for each aspect of the
> reference client. (on reference platforms - I do not expect many to
> agree with this though)
>
> As a side note, what happens to the donations to the bitcoin
> testing project? do they get moved over to the foundation? this
> question is bigger than this email. as far as I know they are all
> on an address Gavin holds. Actually I would like to be involved in
> any discussions that would impact QA, does this mean I need to join
> the foundation or just go lone wolf?
>
> tbh I dont really understand foundations. I always thought they
> were just a tax dodge.
>
> Sorry for the long message. :)
>
>>>>
>>>> Arklan
>>>>
>>>> ---------- As long as there is light, the darkness holds no
>>>> fear. And yet, even in the deepest black, there is life. -
>>>> Arklan Uth Oslin
>>>>
>>>> I want to leave this world the same way I came into it:
>>>> backwards and on fire. - Arklan Uth Oslin
>>>>
>>>>
>>>>
>>>> On Sat, Sep 29, 2012 at 12:26 PM, steve <steve at mistfpga.net>
>>>> wrote:
>>>>
>>>> Hi Gavin,
>>>>
>>>> Sorry for the delayed response, I wanted to take a couple of
>>>> days to reflect on your email.
>>>>
>>>> On 26/09/2012 19:09, Gavin Andresen wrote:
>>>>
>>>>
>>>> And their are other methods too.
>>>>
>>>>
>>>>
>>>> The GUI::Test package for perl will allow this to be greatly
>>>> automated. (I have done this before on the localisation of
>>>> photoshop.)
>>>>
>>>>
>>>>
>>>> this why we need detailed testscripts and plans. so we know
>>>> what has and hasnt been done. The more boring the task the
>>>> more work that needs to go into testcase development. This
>>>> is the area I see as my greatest failing last time. I have a
>>>> large number of virtual machines and should have at least
>>>> this work. But we need very detailed testcases. with decent
>>>> testplans just downloading the software, syncing the block
>>>> chain, syncing an existing wallet, rescanning the blockchain
>>>> and verifying the balance would cover a large number of
>>>> tests. The idea behind having lots of very specific
>>>> testcases is you get to see what tests have not been run.
>>>>
>>>>
>>>>
>>>> I understand your concern, however I have taken a couple of
>>>> days to reflect on this and I still strongly feel that in
>>>> order to make sure that this sticks, and is still useful in 1
>>>> years time we need to lay proper foundations. Those
>>>> foundations are not word documents, spreadsheets, etc. they
>>>> are selecting the right tools for the job.
>>>>
>>>> We can gain so much benefit from using 3rd party software.
>>>> (bettermeans would rock if it wasnt rotting)
>>>>
>>>> I am sure you could do your coding work just using vi, but an
>>>> sdk makes it much easier and allows you to work in a more
>>>> productive manner.
>>>>
>>>> I have had a couple of off list emails with some testers and
>>>> they also feel that it is very important to make sure we have
>>>> a sound foundation (mantis is so much more than just a bug
>>>> reporting tool, I see the bug reporting functionality as
>>>> secondary to the main test run functionality - but it doesnt
>>>> have to be mantis based, we do need workflow and testcase
>>>> software though - and proper software for this is much better
>>>> than just a massive google doc.) however I am checking out
>>>> some other software that has been recommended. It will be
>>>> very hard to change 'the process' once we have something we
>>>> are used too (just look at the current resistance) I promise
>>>> nothing will change for the dev team. But test does need
>>>> other tools, and processes.
>>>>
>>>> If you feel that strongly that I am going about this the
>>>> wrong way, I am happy to step back and let someone else sort
>>>> it out (I will still do all the testing I possibly can). I
>>>> would feel that this would be a real shame and we have the
>>>> chance to setup requirements to functionality to tests all
>>>> with traceability. why not do it right from the start?
>>>>
>>>> I will open up my vps' somepoint over the next few days and
>>>> you can see what I mean. I will setup a fake git project, and
>>>> sort out the interactions.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
> ------------------------------------------------------------------------------
>>>>>
>>>>>
>
>
How fast is your code?
>>>>> 3 out of 4 devs don\\\'t know how their code performs in
>>>>> production. Find out how slow your code is with
>>>>> AppDynamics Lite.
>>>>> http://ad.doubleclick.net/clk;262219672;13503038;z?
>>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>>>
>>>>>
_______________________________________________
>>>>> Bitcoin-development mailing list
>>>>> Bitcoin-development at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>
>>>>
>>>>
>>>>
>>>>
>
>>>>>
-
------------------------------------------------------------------------------
>>>>
>>>>
> Got visibility?
>>>> Most devs has no idea what their production app looks like.
>>>> Find out how fast your code is with AppDynamics Lite.
>>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>
>>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
Got visibility?
>> Most devs has no idea what their production app looks like. Find
>> out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQa5GXAAoJEFvEB9dQFvtQUR4H/3o0aOyvF6u4Wi5UUxMtGWXD
Bduuag9jNY/GACFshYs365wWqJcK96GXc/svOx0l/TTv10tw9BboaMpKY2x9gWri
7DJ+mym1AorgHBlZUgZJy3kQrb5yUCR7MiYU0O28QAqK5aVoklBa6cGQJqQVRa2j
vm9UrKCOeMbHiNMjagLP3s1tcQxYJUwm8hEuALWjyqsDQ+Rk7j2ndBnfonJLTCDc
rIy6HhmfAGSCaXFzhH35Ydfl2hV6ASaUHtBSKke3bB/oJ/bA5XspmPPhCkjum4Lo
4b28i4/O8BTisAsr8N3FYQ17dmD2fu8/gmQt1Rl9MBfWBHPJ9YVIIittk+WhcI0=
=nER6
-----END PGP SIGNATURE-----

2023-06-07 10:33:11

- reply

📅 Original date posted:2012-10-01
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/10/2012 14:52, Arklan Uth Oslin wrote:
> Hi guys.
>
> So, as I mentioned on the bitcointalk.org forums thread about the
> foundation, I want to get involved in the QA side of bitcoin
> development. I've done functional testing in the video game
> industry for years.
Nice one, I worked in games for quite a few years. (before getting
into finance then pentesting) there are about 6 keen testers now.
maybe we should get a bitcoin-test mailing list, where we can discuss
stuff without disturbing the dev team.
> I've read all the messages in this thread, but I'm left unclear
> how I can most effectively and quickly being helping out. Could I
> get a bit of a directional nudge?
Great question... for me I feel structure is the most important thing
to sort out first. However we desperately need detailed testcases for
the release of a new version. - Not too much on the change log stuff,
more on the noddy stuff (as gavin points out below), downloading and
making sure it works on a non dev machine, make sure the wallet isnt
overwritten, etc.) doing games qa I imagine this would be an ideal
place for you to start. I have a MSDN and TechNet licence so if you
need some reference ms virtual machines I can help you out.
However we need some testcase software. Please check out what was
done on bettermeans for the stuff I was planning out...
It details everything from recompense and testcases. bettermeans kinda
died a death though...
check out:
Bitcoin over all-
https://secure.bettermeans.com/projects/4180/wiki/Page_index
discussion
https://secure.bettermeans.com/projects/4180/boards
0.7
https://secure.bettermeans.com/projects/4256/boards
and
https://secure.bettermeans.com/projects/4256/wiki
I still have the testcases, but until we get some proper testcase
software I am loathed to publish them in a half arsed format. (they
worked well on bettermeans, then just vanished one day...) what
testcase software are you familiar with?
apart from that, what do you feel you can do for the project? how long
have you been involved in bitcoin? It may well be worth reading up
all the dev stuff on the wiki so you can get you head around how the
bitcoin protocol is different from the daemon and qt client. What do
you think you can and will enjoy doing? What is your skill set in
regard to networking, crypto and operating systems. (not that you need
any, in any we still want and need you. :)
there really is room for you to do whatever role you want, and as
little or as much as you want - however funding is now a very tricky
issue. so much so that I am not sure I want anything to do with
it(distribution of coin based on work.). - I just paid for some logo
spec work out of my own pocket (for example). I have some testers i
know irl who are willing to work for coin.
NOTE: This response has nothing to do with the bitcoin foundation. I
am not a member of the foundation. I do not speak for them or even
probably with them. I am still trying to work out how much qa the
foundation should be responsible for, and/how it is supposed to work.
I think the games cert process would be ideal for this. This however
this a discussion that probably wont have my involvement. (personally
I believe that the foundation should publish requirements with example
code and testcases for each aspect of the reference client. (on
reference platforms - I do not expect many to agree with this though)
As a side note, what happens to the donations to the bitcoin testing
project? do they get moved over to the foundation? this question is
bigger than this email. as far as I know they are all on an address
Gavin holds. Actually I would like to be involved in any discussions
that would impact QA, does this mean I need to join the foundation or
just go lone wolf?
tbh I dont really understand foundations. I always thought they were
just a tax dodge.
Sorry for the long message. :)
>
> Arklan
>
> ---------- As long as there is light, the darkness holds no fear.
> And yet, even in the deepest black, there is life. - Arklan Uth
> Oslin
>
> I want to leave this world the same way I came into it: backwards
> and on fire. - Arklan Uth Oslin
>
>
>
> On Sat, Sep 29, 2012 at 12:26 PM, steve <steve at mistfpga.net>
> wrote:
>
> Hi Gavin,
>
> Sorry for the delayed response, I wanted to take a couple of days
> to reflect on your email.
>
> On 26/09/2012 19:09, Gavin Andresen wrote:
>
>
> And their are other methods too.
>
>
>
> The GUI::Test package for perl will allow this to be greatly
> automated. (I have done this before on the localisation of
> photoshop.)
>
>
>
> this why we need detailed testscripts and plans. so we know what
> has and hasnt been done. The more boring the task the more work
> that needs to go into testcase development. This is the area I see
> as my greatest failing last time. I have a large number of virtual
> machines and should have at least this work. But we need very
> detailed testcases. with decent testplans just downloading the
> software, syncing the block chain, syncing an existing wallet,
> rescanning the blockchain and verifying the balance would cover a
> large number of tests. The idea behind having lots of very
> specific testcases is you get to see what tests have not been run.
>
>
>
> I understand your concern, however I have taken a couple of days
> to reflect on this and I still strongly feel that in order to make
> sure that this sticks, and is still useful in 1 years time we need
> to lay proper foundations. Those foundations are not word
> documents, spreadsheets, etc. they are selecting the right tools
> for the job.
>
> We can gain so much benefit from using 3rd party software.
> (bettermeans would rock if it wasnt rotting)
>
> I am sure you could do your coding work just using vi, but an sdk
> makes it much easier and allows you to work in a more productive
> manner.
>
> I have had a couple of off list emails with some testers and they
> also feel that it is very important to make sure we have a sound
> foundation (mantis is so much more than just a bug reporting tool,
> I see the bug reporting functionality as secondary to the main test
> run functionality - but it doesnt have to be mantis based, we do
> need workflow and testcase software though - and proper software
> for this is much better than just a massive google doc.) however I
> am checking out some other software that has been recommended. It
> will be very hard to change 'the process' once we have something we
> are used too (just look at the current resistance) I promise
> nothing will change for the dev team. But test does need other
> tools, and processes.
>
> If you feel that strongly that I am going about this the wrong way,
> I am happy to step back and let someone else sort it out (I will
> still do all the testing I possibly can). I would feel that this
> would be a real shame and we have the chance to setup requirements
> to functionality to tests all with traceability. why not do it
> right from the start?
>
> I will open up my vps' somepoint over the next few days and you
> can see what I mean. I will setup a fake git project, and sort out
> the interactions.
>
>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
How fast is your code?
>> 3 out of 4 devs don\\\'t know how their code performs in
>> production. Find out how slow your code is with AppDynamics
>> Lite. http://ad.doubleclick.net/clk;262219672;13503038;z?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
>
>
Got visibility?
> Most devs has no idea what their production app looks like. Find
> out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQaaieAAoJEFvEB9dQFvtQUi0H/3Eh72DqxwBt6AeNos/hJNqQ
ZowMNFRupJQM301EJ7SPQmcnVuc3RF2Jw//ckpAqdpkqhHCgGO9HX/q+Ic2A9erQ
CfKbUOwQgqKuLQTZ8eT5UMh969Uw8PMazo711d2I23etU0VhSK/MvjB5IiYIq5fB
RJdCEluwvACaiftqfm4RA9HXXJGMnsZtlSWjVQCkg2FyYZKfpctEFdGCg6R8IaP7
ypyglR7TfygcjhUMHeWkQQCP2m2gBOHpx9H99uNBosF+6pLBhCiGUrwVkl8HUiiN
4YfhsvoRQ0BWNgvO9wH1H4EyyZtJsE7S926BNkhd4uewWGV/qe8gML+uJRstPDg=
=L66i
-----END PGP SIGNATURE-----

2023-06-07 10:32:50

- reply

📅 Original date posted:2012-09-29
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Gavin,
Sorry for the delayed response, I wanted to take a couple of days to
reflect on your email.
On 26/09/2012 19:09, Gavin Andresen wrote:
And their are other methods too.
The GUI::Test package for perl will allow this to be greatly
automated. (I have done this before on the localisation of photoshop.)
this why we need detailed testscripts and plans. so we know what has
and hasnt been done. The more boring the task the more work that needs
to go into testcase development. This is the area I see as my
greatest failing last time. I have a large number of virtual machines
and should have at least this work. But we need very detailed
testcases. with decent testplans just downloading the software,
syncing the block chain, syncing an existing wallet, rescanning the
blockchain and verifying the balance would cover a large number of
tests. The idea behind having lots of very specific testcases is you
get to see what tests have not been run.
I understand your concern, however I have taken a couple of days to
reflect on this and I still strongly feel that in order to make sure
that this sticks, and is still useful in 1 years time we need to lay
proper foundations. Those foundations are not word documents,
spreadsheets, etc. they are selecting the right tools for the job.
We can gain so much benefit from using 3rd party software.
(bettermeans would rock if it wasnt rotting)
I am sure you could do your coding work just using vi, but an sdk
makes it much easier and allows you to work in a more productive manner.
I have had a couple of off list emails with some testers and they also
feel that it is very important to make sure we have a sound foundation
(mantis is so much more than just a bug reporting tool, I see the bug
reporting functionality as secondary to the main test run
functionality - but it doesnt have to be mantis based, we do need
workflow and testcase software though - and proper software for this
is much better than just a massive google doc.) however I am checking
out some other software that has been recommended. It will be very
hard to change 'the process' once we have something we are used too
(just look at the current resistance) I promise nothing will change
for the dev team. But test does need other tools, and processes.
If you feel that strongly that I am going about this the wrong way, I
am happy to step back and let someone else sort it out (I will still
do all the testing I possibly can). I would feel that this would be a
real shame and we have the chance to setup requirements to
functionality to tests all with traceability. why not do it right from
the start?
I will open up my vps' somepoint over the next few days and you can
see what I mean. I will setup a fake git project, and sort out the
interactions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQZz1pAAoJEFvEB9dQFvtQRLkIAJtPCkW1R9vmMPY9u4o+ET1t
w4pV/+W2PXo2p86HnljCIPLV/cua/1I/EJp7XR7s145Nj4KZUbzHGhvUUmwDOHW2
TGvJs+HO1bjsJfh4pWEb6PXcW3TguZxZSt5/rBAAI/5BeomSuRcZOdoV87D1xnK8
TSlgaseWrJcpKLO30/FQA3QnH/bjJ4OBmtHp8WaOtSnfww9Zbb5VYca37O15c2U4
2d0RUunDg1w2kRbkKjztxr3YasSOX+07Uvj4d5Lw7zgA0U93krNWVT1Ypo94dNJ7
6SyKi30UuqDdJ9XxZrMB/LBVNGOLlIBNWL++ocu5GFnOn9pnw57ZMBZM5g6YDpo=
=ekQ/
-----END PGP SIGNATURE-----

2023-06-07 10:32:43

- reply

📅 Original date posted:2012-09-26
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 26/09/2012 17:06, Mark Friedenbach wrote:
> Running a concurrent Mantis tracker would be confusing and fragment
> the development pathway. We have an issue tracker; it's on github.
I think you misunderstand what I am proposing.
QA needs more than just an issue tracker. i have yet to find any
opensource software that integrates testcases, nor any method for
generating testplans, nor any method for linking testcases and plans
to requirements, that work with git.
We will need software for this (as well as workflow software) and it
is much easier to integrate this into mantis/bugzilla. They are both
so much more functional than Git.
both mantis and bugzilla have full two way functionality with git.
>
> What's being talked about here are two separate things. Jenkins is
> a continuous integration system. It can be configured to run the
> suite of unit tests, regression tests, and any kind of automated
> functional tests for every commit on github and every pull
> request.
well 3 but okay. Jenkins integrates both with mantis (and therefore a
testsuite, etc) and with git. I do not see why anything should be any
different. again I am not trying to change any current process, just
develop some new ones.
>
> Github is our issue tracker. Github, and only github, is where new
> issues should be reported (unless it's security related, in which
> case an email should be sent to the core devs directly).
You will only ever receive bug reports via git. How they are entered
should not be of concern.
There will be no space in mantis/zilla for bugs that are not related
to testcases.
>
> Certainly developers should be responsible for making sure that
> regression tests for bugs they fix make it either into the unit
> tests or Matt's functional test repository. QA should hold them
> accountable for that (re-opening tickets for bugs that have been
> fixed but without regression tests).
I feel very strongly that developers should not do regression testing
or any signoff testing on their own code. QA should do the testing. I
am 50/50 if they should write the testcases. the QA process should
make things easier for the dev team, not generate more work for them.
>
> The other thing we're talking about is coordinated release
> testing--getting release candidates in the hands of actual users
> and making sure that issues are reported. This is something that
> can't be automated as the point really is to pick up on things that
> the testing suite missed. You sound more qualified than me for
> coming up with a process, but in the end discovered issues should
> be reported to github, the final repository of issues that hold up
> Gavin from doing a release.
All the core development team will still use git. the extra software
is needed by test.
(And the third point was coming up with a suite of tests for 3rd party
developers to test their interoperability - this will having nothing
to do with git, or mantis. But the solution should be compatible with
mantis/zilla)
>
> Just my 0.002BTC Mark
>
> On Wed, Sep 26, 2012 at 6:22 AM, steve <steve at mistfpga.net> wrote:
>>
>> I think you might be misunderstanding a little. I am not trying
>> to replace the current system, I need to make sure that what I do
>> will be compatible with it (seamlessly so for the developer). I
>> do not want this to generate extra work for the development
>> team.
>>
>> However testing is a lot more than just bug reporting, dont get
>> me wrong bug reports are important, but so is running a testcase
>> and that testcase passing, especially if that testcase is linked
>> to the proof of a requirement. I am trying to develop a qa
>> environment that is conducive to testing and will allow the
>> testers to shine in all their glory :) and we need different
>> tools and methodologies.
>>
>> Git is too developer centric to be useful for organising testing.
>> - however there is a large amount of software that is compatible
>> with git, so the core development team only ever need to work
>> with git.
>>
>> The linking between a bug, the requirement, the fix, the retest,
>> and updating of regression testplan is vital. So is the ability
>> to organise testing campaigns and assigning tests, work units and
>> test relevant docs/scripts/ideas, etc.
>>
>> I hope this clears things up a bit?
>>
>> Cheers,
>>
>> steve
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQYz8CAAoJEFvEB9dQFvtQjkMH/Apa95IRh21mfNIuyK8kOSdt
55tLoT9a6DFyF1IPTgjHQlPN/A0JCPy/p2rIEEL7XzWpCMu1zU8BzBNmJsxGAZJG
C0ue1eDEywKNFEMPTgQdebC2MbNSfUBA6lGJ5vijQlcXKoIuiV/LS7IMYh57T4u1
6Tc/SGypGe8kBLuFTihmIGH5uFS6arNGlcGgh+HRn+O4jKiAcw06lIoKh7S9Rj5e
bmkimvOfproCIZeNQfSJH1BfYZaVVsJ1ouVI7ch6ytFpKsZ622zYF0Iq3042kEEp
Fyqh9pDDNTJ/dwbyFpTx0WaxZySdZfZmQOCxFCAeLaCpop/nKeUnW5fy3i0sYno=
=rfHO
-----END PGP SIGNATURE-----

2023-06-07 10:32:33

- reply

📅 Original date posted:2012-09-26
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 26/09/2012 13:49, Wladimir wrote:
> Steve,
Hi Wladimir,
>
>> So, currently there are 4 potential places for bugs to be
>> reported 1 - jenkins (and unit tests) 2 - git 3 - mailing list 4
>> - forum (bitcointalk...) 5? - is there still the ability to add
>> bugs via sourceforge?
>
> Currently github is the authoritative place to report issues. When
> someone reports a bug on the mailing list, IRC or forum, they are
> generally asked to make a github issue (or, someone else makes the
> issue for them). Failed tests are generally also reported on
> github, by the pull tester.
excellent, that makes things much easier.
>
> We currently have 232 issues, mostly classified into categories
> such as "Bug", "Improvement", "GUI", "Wallet", and so on.
>
> Also it's easy to refer to github issues in commits with #123, with
> automatic linking.
>
> I'm not sure it is worth the effort to move to another system
> (especially if you need a another login etc...). But I'm probably
> misunderstanding what you're trying to do.
I think you might be misunderstanding a little. I am not trying to
replace the current system, I need to make sure that what I do will be
compatible with it (seamlessly so for the developer). I do not want this
to generate extra work for the development team.
However testing is a lot more than just bug reporting, dont get me
wrong bug reports are important, but so is running a testcase and that
testcase passing, especially if that testcase is linked to the proof
of a requirement. I am trying to develop a qa environment that is
conducive to testing and will allow the testers to shine in all their
glory :) and we need different tools and methodologies.
Git is too developer centric to be useful for organising testing. -
however there is a large amount of software that is compatible with
git, so the core development team only ever need to work with git.
The linking between a bug, the requirement, the fix, the retest, and
updating of regression testplan is vital. So is the ability to
organise testing campaigns and assigning tests, work units and test
relevant docs/scripts/ideas, etc.
I hope this clears things up a bit?
Cheers,
steve
>
> Wladimir
>
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQYwESAAoJEFvEB9dQFvtQ/GUH/jv2c5L0OcL/kHkX/z0Yqbl/
2IntPLdjXNKLuz0A7BMz7XfUyVmWlZrw44qxmi+Vyk5PKNBjYIidm763xHnTeJLN
ULQBckYexMvan9hAyYZUOt85IpesdNgqTIsqh8f49y4roHOy8GT4M/2fhzXpnsGg
G9d2m8jWGpj/kxl9qE7/WjVQC4APwBi/NiJsCrcHswgweN+zENc/Pot9YBLxAZu/
ACBUX/xFymRdaZN8P2LWBXuKx6E2WEcBdPCCWArX07wPiBlrashx9Gz6tiNzIiNq
x2c4ltLzRa45AmiDtQhwqyTprz/DbyeAYO1sIsfpUxDeu9e3xTb/Zd96jfKIWI0=
=iHI1
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQYwGsAAoJEFvEB9dQFvtQxOsIAKgBBOKHNFtoV2cN+GVqzlip
yy0qiMvMTZKrraOhEw8QNNuOlB3LRchi+RDR/PvQkVfuwi/jHB2gUBzlapLoECBv
EH8pgT/MO281pXzARgRSVkRYqkb3ljhQz3mEQg9RhR9h5t9g2mL3Tvppt7249Bg8
oGXPj6xmMcrbClF5qDbwQUUDGJfOo4eti0jSVD3qp2NE7QpPVQwuN5buchpoKt3P
9aJnjeZdLmuAk2RPoDaLXUFc9unT8AcnW96juD0zoVA9wKvAa6/8IZQf0mzV4iZP
yiWGNOQtBZ+jyu2ixiEnvHqqG2ZmjtUVqWtjHkxYgrCyuuK2jOcTMNEWfn7SfKc=
=yP7N
-----END PGP SIGNATURE-----

2023-06-07 10:32:27

- reply

📅 Original date posted:2012-09-26
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Matt,
Glad to have another ninja onboard :)
On 25/09/2012 21:41, Matt Corallo wrote:
> Although Jenkins may not be the best system, we already have
> jenkins and pull-tester (which is a dumb python script I wrote to
> test all incoming pull requests from github).
I have never heard of jenkins before. I need to do some more digging.
is this the right thing?
https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin
Mantis on the other hand, I know exceptionally well. I hate
duplication of work/data unless absolutely necessary. I will check
jenkins out (just out of interest what is it actually meant to do? the
website implies framework, but not what its for)
So, currently there are 4 potential places for bugs to be reported
1 - jenkins (and unit tests)
2 - git
3 - mailing list
4 - forum (bitcointalk...)
5? - is there still the ability to add bugs via sourceforge?
Adding to this doesnt make sense. Each one of these reporting methods
is for a different thing. I am not seeking to replace these (or even
unify them) I am looking for software that will take testcases and bug
reports against them [and allow for test campaigns]. Mantis is so
flexible and industry standard and if the jenkins plugin works... then
we can keep things as they are until they fit into better places.
The reason I am so behind mantis as the backbone is it works with more
or less anything, and can easily modded to work with whatever people
are most comfortable with - however it is exceptionally powerful and
has had a constant stream of workflow improvements over the past few
years.
>
> They both run the same set of scripts, namely those at
> https://github.com/TheBlueMatt/test-scripts (its pretty basic right
> now, but since it is on github, I was hoping someone would find
> the inspiration to add to it).
I will check it out. I wrote a very basic script that wikified the
changelog, and linked to the changes and created wiki pages for the
testcases. have you seen the stuff I put on bettermeans? bits keep
vanishing then re appearing.
This is the outline of the testing that I setup for 0.7
https://secure.bettermeans.com/projects/4256/wiki
>
> I dont really care if we keep using jenkins, but I figure we might
> as well keep all the tests in one place?
Yes, I would love to unify all build testing and testcases into one
place. I am still on the fence as to including unit tests into this.
However I do see 3 distinct type of testcases
1 - requirements based testcases (requirements based off the current
block chain rules - these are edge cases and known interoperability
issues)
2 - Acceptance based testcases - these are testcases that should be
run for every build. Check out the General Acceptance Tests in the
wiki link for examples and testcases
3 - Testcases for reference implementations of things (like multisig -
i see these working like the /test folder when you install a new perl
module)
These three things alone are a massive task. and they still wont cover
everything. I would like to get the workflow so that people can
sponsor or donate to a specific campaign (eg a new feature is
implemented, people want it tested so can donate just for that
campaign [developing testcases, structure, requirements, etc])
Once this is done, I will get to do some exciting stuff (like writing
fuzzers, automation, etc) unfortunately I do not know python, only perl.
>
> Anyway, I'm all for more testing (I'm always complaining about how
> we need more tests for stuff...).
Nice, I love testing. I think we will get on :)
And I would rather go for interoperability between testing rather than
rewriting it all.
Cheers,
steve
>
> Matt
>
> On Tue, 2012-09-25 at 19:32 +0100, steve wrote:
>> Hi All,
>>
>> After the failure to get any real testing done for the 0.7
>> release (all of which is my fault) I have decided to rejig
>> things.
>>
>> I am heavily into test driven development, and I have a strong
>> background in requirements management, and automation.
>>
>> I want to leave bettermeans behind, maybe we might be able to
>> keep the voting aspect of it, and link it into mantis.
>>
>> So, what I have been doing over the past few weeks is developing
>> a rudimentary requirements set, basic requirement tracking, tests
>> to prove/stress the requirements.
>>
>> The next most important thing is to get release/acceptance tests
>> done - these primarily focus on new stuff doesnt break old (ie
>> lose a wallet, etc) and needs no special requirements.
>>
>> To this end I have installed various opensource applications
>> (mantis, salomeTMF, bugzilla, etc) and am currently evaluating
>> the best workflow process.
>>
>> This was a much longer post, but decided against it. :)
>>
>> So, what I want to know is who wants to be a part helping me out
>> with all this? I am finalising the workflow flow diagrams and
>> they should be ready for inspection soon.
>>
>> Anyone interested in helping out/reviewing processes? even if it
>> is just some encouragement, it is all greatly appreciated.
>>
>> Drop me an email if you want access to the current setup and help
>> me review the different software for the bitcoin workflow
>> process.
>>
>> cheers,
>>
>> steve
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQYvT4AAoJEFvEB9dQFvtQlgkIAJX7JYel5RGmCsbptGdQrCnT
BR42tUwTg1t/NRUJ6RA8/Ou8lzallztQquShpLn4mZdQpoalvETdtAwcPnQKnaZb
M5inZE/IEq8WJM1y4YkHt3BLou4BJbjwncCNy1/jqcm6f2Oonrg7isVbDwY/7JlP
y/epm7XELS7NU4vVubBwQCunwvtsuydXRzuI812LiLXNqpXFMHvG2m8a2RajXE0/
xW4lOMy/hUFzEgYRQWCTAru4Ts2x3Xt26NaEUh/uKvHLwBZJ4xbdu3gpupiPb4sI
bCHnVFOC7zoQKOAnfPkCMyvtyoqpzM9HW2+DWI51FoOz851Y2F36N3Fpk/2lii4=
=W5xI
-----END PGP SIGNATURE-----

2023-06-07 10:32:11

- reply

📅 Original date posted:2012-09-25
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All,
After the failure to get any real testing done for the 0.7 release (all
of which is my fault) I have decided to rejig things.
I am heavily into test driven development, and I have a strong
background in requirements management, and automation.
I want to leave bettermeans behind, maybe we might be able to keep the
voting aspect of it, and link it into mantis.
So, what I have been doing over the past few weeks is developing a
rudimentary requirements set, basic requirement tracking, tests to
prove/stress the requirements.
The next most important thing is to get release/acceptance tests done -
these primarily focus on new stuff doesnt break old (ie lose a wallet,
etc) and needs no special requirements.
To this end I have installed various opensource applications (mantis,
salomeTMF, bugzilla, etc) and am currently evaluating the best workflow
process.
This was a much longer post, but decided against it. :)
So, what I want to know is who wants to be a part helping me out with
all this? I am finalising the workflow flow diagrams and they should be
ready for inspection soon.
Anyone interested in helping out/reviewing processes? even if it is just
some encouragement, it is all greatly appreciated.
Drop me an email if you want access to the current setup and help me
review the different software for the bitcoin workflow process.
cheers,
steve
- --
my PGP public key is at pgp.mit.edu id: 0x5016FB50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQYfjMAAoJEFvEB9dQFvtQSmsH/R/FEdOQRB7ncTnHhaP8woLu
nIiGX2DgLOWLOF9launSuTCrtVm2G56B9Dgl/BqScFxeuJGbzje7+kp7LgjtA3uy
kS9DUZ1zhUfhslGP0UpVJJGX6Yfk8GbQ4nUcuL1VTv6nSZXWP2EvLMDPpRgKwyi5
z1FiyBg2A3Kg3Er+VmHPmpI0zZAGB5ytaenUp4xXGhL7Nk66i5X0twVr51xlEm0L
zKCDXHzWTvNNlT7TzMjIxShJ/EcgCI1r6tVD3T+2e9QeVm0QNw3xeNUkMxKn+ul8
d1v1OxJbHD1CsNqW+XgVvFE2SJReizaHNOFwrqcpVCp7bABnWAB5eyTzB9B9IX8=
=di5x
-----END PGP SIGNATURE-----

2023-06-07 10:27:26

- reply

📅 Original date posted:2012-08-02
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/08/2012 01:07, Gary Rowe wrote:
> Hi Steve,
>
> This looks like a good idea to me. The test suites could act
> similarly to the 100% Pure Java approach that successfully fended
> off a lot of corrupting influences to Java over the years.
>
> Maybe it's worth putting together a small starter suite of tests
> and showing them to the community then providing a suitable
> process, perhaps through BIPs, to allow tests to be created,
> reviewed and updated before getting incorporated into a reference.
> I imagine a BIP would cover an aspect of the blockchain rather than
> a single test or test suite since having that many BIPs would get
> onerous fast.
>
> Kind regards,
>
> Gary
>
Hi Gary,
Thanks for the response. :)
I have started all this in bettermeans, but lost a lot of work (which
I am working on how to redo - but I am on holiday at the moment, and
have restricted access to my test setups)
Here is the discussion thread I had with gavin about acceptance tests.
https://secure.bettermeans.com/boards/4316/topics/7261
Here is the work I have currently done (note, it was losing all the
General Acceptance Tests and getting no response from bettermeans that
has lead me to not want to use it)
also note that the terminology I have been using is a little wrong, I
refer to release 0.7 as testnet release 0.7 - I will tidy it up. - I
did this before and it looks like it got reverted somehow.
here is the main wiki space that I have been using.
https://secure.bettermeans.com/projects/4256/wiki
For the General Accceptance Tests, check
https://secure.bettermeans.com/projects/4256/wiki/Dev_general_acceptance_tests
These are the basic acceptance tests based off the changelog
https://secure.bettermeans.com/projects/4256/wiki/Dev_acceptance_tests
However, notice no tests are in there yet.
There is plenty more stuff on bettermeans so please go have a poke
around. I will try to get at least a wiki setup on a vps I have
control of (in germany, and provided by CINFU and paid for with
bitcoins) and get the stuff moved over and put the tests back up. I
can do a limited amount of testing if the release is to happen in the
next week or two, So I will focus my efforts on the installation tests
and wallet tests. Ideally I would like to get all the GAT's done.
Hopefully this fleshes things out a bit more.
Please feel free to add/edit but remember your stuff might magically
disappear, it might be better to wait for the wiki move. I intend on
doing the wiki move today. but that might not happen.
(I have a feeling that it was me adding stuff from an account that is
not on the BTP that blew things up, just a feeling though)
I would like to keep tests informal if possible, but that kinda goes
against the purpose of the tests. this is a bit tricky to explain if
you have not had a look at bettermeans. bettermeans kinda has its own
BIP and voting mechanism, which is quite nice and it is what I want to
emulate - this should reduce the need for vetting of tests... have a
look at what is there and see what you think.
:)
cheers,
steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJQGxkFAAoJEFvEB9dQFvtQeD0IAJe9BJz/mv+kZjhk7LH1d7HH
c46D7s2Y8a+2Yobve4KtRGMoQZQiqqXGIdZ2nHVO77s0zICixqdtcKlRvBZHybw9
pB8hFYmeBdXvMHj7TR4kMbMKqTJ2z/B6m1qEKFfCRIXQXnyD5qNYhFocyQMwz53A
dkwhpoiWNVqcgnz51XEnphyohu0TPsPbOOyCrT7ORdyAgLJAs5Ig1sKbTAdSxOux
flEYKOVk0gse2b8lO2ly+eLwcQgI7jrzy+qkSKmNajRKFdvHUODXo4RraR08qiaJ
SUpmN/43uQZ4atMdOCZxD5DWKjBO96sj6mkB/po5lzIEEtkhzyp/wmKdHtlvZ/Q=
=Fonn
-----END PGP SIGNATURE-----

2023-06-07 10:27:19

- reply

📅 Original date posted:2012-08-01
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I know most of you have more important things to do, and not enough
time as it is, but I would really like your feedback on the testing
project.
Bettermeans seemed ideal, it allowed for leaderless leadership with
people being able to dip in and out of what they wanted to do.
however it seems that bettermeans is in no way a finished product and
is rotting fast.
I would like to move away from bettermeans - whilst retaining the
voting and sub workstream style of working. I would like to set
something up around MantisBT (Mantis Bug Tracker) - this is an
exceptionally versatile bit of software with plugins and interaction
with other testing products (everything from test setups and plans to
test runs and results) I would go as far as saying it is industry
standard (yeah, i know about bugzilla, etc. mantis beats them all
hands down.) obviously we would need a wiki and other software - this
is not a problem.
I am happpy to pay for the VPS' to host this stuff and set it all up.
I have quite a bit of experience with mantis and other opensource
testing stuff.
I see the testing of bitcoin to be very similar to the testing process
in the games industry. for those that do not know how this works it
is like this:-
A company comes up with a device (xbox/ps),
They then publish a set of dos and donts for this device (TRC for sony
and TCRs for microsoft. - I wrote quite a few of the MS TCR's for the
original xbox.)
They (ms/sony) then test your game against these rules and depending
on how many you pass/fail your game can be released or not.
I see this as mapping to bitcoin very well, the device is the
blockchain, and the TRC/TCR _tests_ are published so third party
developers can see how they fair [look at gavins recent blockchain
edge cases for an example] (ms/sony do not publish their testcases
only the requirements)
I believe that this will allow the bitcoin testing project to be able
to cope with the stable builds, bleeding edge builds and 3rd party
implementations all at the same time.
It doesnt matter what the app is, it is its interaction with the
blockchain, the safe guarding of the blockchain and compatibility with
the previous/future versions that are tested.
[for the bitcoin dev list]
A little about me:-
The below is more or less a cut and paste of some of the stuff I sent
gavin in my initial email about wanting to be in on the project.
I can back all of this up with references. I can go into more detail if
needed.
I was heavily involved with setting up the microsoft xbox european cert
department
I set up qa department for europes largest independant games developer
(although they are no longer)
worked for microsoft secure science designing security automation tools
setup the internal pentest for thales e-security (now TITS [Thales
Information Technology Solutions (or Trotters Independant Traders ;),
on thier datacryptors (fpga, crypto and product) - have done full test
cycles on hsm 8000, payshield 9000, dc2k and thier latest line of
military spec comms equipment.
Setup and pentested Thales and nCiphers credit control software (to
fips level 4 standard - This shit bitcoin exchanges need!! I know bank
is a dirty word in the bitcoin world, but we should be at least as
secure as them)
I currently find exploits in stuff like office, quicktime, ie, ff, etc
and sell them to companies like ZDI (3com) iDefense (verisgn) and some
pentest companies that require zero day exploits.
however I would like to ditch this and get my bitcoin related stuff
off the ground - with the BTP being top of the list.
my spelling is rubbish, and sometimes i forget to spellcheck before i
hit send. sorry about that.
any feedback would be really appreciated. please! I feel that this has
stagnated enough and I want to get my work out there and I want it to
be useful. (I lost 60 or so testcases because Kev left himself logged
into bettermeans and I added them under his account... none appeared
on the wiki, none appeared anywhere...)
There is already lots of stuff on the wiki that outlines how i see
things holding together - but you cant see who posted what because of
a bug that has appeared recently [meta info is just displayed as its
meta tag, {name} on {date} wrote.]
as apposed to Mistfpga on 30/8/2012 wrote...
so the tl;dr
1 - I want to use something other than bettermeans
2 - I can admin opensource software to do the same
3 - I want to take the voting/hiearachy style from bettermeans and
apply it to mantis and test workflow.
4 - I want to get some testing done asap.
5 - I have a full msdn and technet licence
6 - I have a vast array of machines [nearly 100 cores] that I can use
to automate testing and to test different setups.
7 - been mining for 18 months or so.
cheers,
steve
I do not belive this to be related, but I am not ashamed and feel no
stigma. I have posted this on a public forum. I suffer from fast
cycling (withing a day) type two bipolar disorder. This has been and
is being managed very well by my meds (300mg quetiapine fumerate and
30mg mirtrazipine at night) I have been well for over a year now. [and
yes, even with these mental health problems I still hold SCE clearance]
- --
my PGP public key is at pgp.mit.edu id: 0x5016FB50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJQGRU7AAoJEFvEB9dQFvtQY9oH/RiNBeWDs+tz0NQgkgtXmxcs
tDtlLWB91gRtmxvXv+yYHE0WXS/qQ5gwaor8Vek61Cvnhij4AQBf7JVYLj03/7fy
cMAFJ5k7ZQmH9URo8Jx8xzQ2tLgZ5BqLbP6fTzDstpExNGJlkZvsC6hTx9OFCubU
bzWuWmcIRzBiMhdz7DPoskOgie5sQRzzO0zrK7NvS1P2hyEhM3eFYFcYecpS8jq9
SbkH77qnc5pZD2JULq38htVwtI16vxmg/s4GIs3OpEPaMk5xtVc5XHf6gwBZQtYw
fErwZpNDEAmGidRCB4LAqdSx1Xi0ix7GOyvTxBLWTnfB7wIAQNQpBHB9zN8diiA=
=am8B
-----END PGP SIGNATURE-----

2023-06-07 10:25:04

- reply

📅 Original date posted:2012-07-25
📝 Original message:On 25/07/2012 10:45, Michael Grønager wrote:
> Hi Steve,
>
> I see dramatic differences in performance on virtual machines vs
> running directly on the iron. I am not an expert in virtual
> machines,
They can be, it depends on how they are set up. For reference, these
VM's used to test network stacks and file format bugs. They do this
via debug tracing, trace into, not over. They then dump this data in
files and it can keep up with a core2 duo laptop for file io. however
I moved to using an in ram database (4gb chunks, that then get dumped
over the network port to a db on a seperate machine)
I am not sure I have the skills to instrament this into bitcoind
>
> I would like to do a test keeping database log files in memory. It
> should not matter for durability of the wallet, as it flushes at
> each write anyway. As for the blockindex, it will remain
> consistent, but might be lagging some blocks behind at startup,
> which shouldn't really matter (except that the same block could end
> up appearing twice in the block00X files, inelegant, but not really
> a problem).
>
> Otherwise the system you describe (raid0 over 6 disks) should
> perform like crazy wrt disk i/o, at least on par with SSD. It is
> your virtualization I am worried about.
I will test that when I get back :)
>
> Have a safe trip to down under!
will do, thanks for the response. :)
>
> /M
>
> On 24/07/2012, at 21:56, steve wrote:
>
>> Hi Michael,
>>
>> from what I have noticed, bitcoin blockchain
>> download/verfication all happens in 1 thread. (so multicores
>> doesnt really help)
>>
>> That said, I have never tried on an ssd.
>>
>> What I do have is 6 SATA 6gbs configed as RAID0 Drives. 32gb of
>> ram. ubuntu 64 (yeah I know), this runs upto 16 VM's (I have 4
>> of these)
>>
>> However I have not tried to download the blockchain on the
>> master os, just in virtulisation. However, the dedicated
>> machines that I have been using for benchmarking the VM's against
>> is a q6600 8gb ram sata2 hdd - Win 7 (seems faster than
>> slackware...) to me it has always felt like network bandwidth was
>> the issue. I might instrument the bitcoin-qt exe to only pick
>> low ping nodes (has someone already done this?)
>>
>> I guess it is time to start some benchmarking (like the gpu
>> comparison page)
>>
>> hte verification for the 5 past 5 days was negliglable. I am off
>> on a flight to australia tomorrrow, so I will set some
>> breakpoints and do some timings in a debugger.
>>
>> This will all happen on an e-450 (wonderful machine!)
>>
>> Thanks very much for your response. it would seem that I am
>> 'doing it wrong' :/
>>
>> cheers mate,
>>
>> steve
>>
>> (this message isnt signed because I have forgotten my password.)
>>
>> On 24/07/2012 09:25, Michael Grønager wrote:
>>> Hi Steve,
>>>
>>> 45-90 minutes - note that its numbers from March/April, so a
>>> bit longer today, but far, far away from the 12 hours.
>>>
>>> I am using libcoin and the bitcoind build based on this.
>>> Libcoin is based on the Satoshi client, but refactured to use
>>> an async concurrency model. I also did a minor tweeks to the
>>> db parameters. It has earlier been tested up against Satoshi
>>> bitcoin where on some OS'es it performs similarly (at least on
>>> some linuxes) and on some faster (e.g. mac).
>>>
>>> What is your CPU load during a block download ? (both
>>> initially/up to the point where verification sets in and
>>> after). The initial download is typically disk I/O bound, the
>>> verification stage CPU bound, though I lean to believe that
>>> even there it is disk I/O bound (at least on my system ~50% CPU
>>> load). What should be better in libcoin is the concurrency
>>> model. The Satoshi client uses a pure reentrant mutexes model,
>>> that is not generally believed to motivate the best coding
>>> practice nor performance, you might end up without the
>>> concurrency you initially strived for *). As mentioned earlier
>>> libcoin uses a pure async concurrency model (and so does
>>> libbitcoin btw).
>>>
>>> I would like to stress again that these numbers will depend
>>> largely on the system running the test - I would call my laptop
>>> a bit over the average today (MB Pro, 2.66Ghz i7 dual core,
>>> 8GBRAM, 512GB SSD). But again 12 hours - I only reach such
>>> numbers on some of my VPS'es (linode 1024) that are known for
>>> notoriously slow disk I/O. (here I have a few % CPU load during
>>> the verification indicating indeed that the disk i/o is the
>>> culprit).
>>>
>>> Cheers,
>>>
>>> Michael
>>>
>>>
>>> *) I like this Dave Butenhof quote: "The biggest of all the big
>>> problems with recursive mutexes is that they encourage you to
>>> completely lose track of your locking scheme and scope. This
>>> is deadly. Evil. It's the "thread eater". You hold locks for
>>> the absolutely shortest possible time. Period. Always. If
>>> you're calling something with a lock held simply because you
>>> don't know it's held, or because you don't know whether the
>>> callee needs the mutex, then you're holding it too long. You're
>>> aiming a shotgun at your application and pulling the trigger.
>>> You presumably started using threads to get concurrency; but
>>> you've just PREVENTED concurrency."
>>>
>>>
>>>
>>>
>>> On 23/07/2012, at 17:54, steve wrote:
>>>
>>> Hi Michael,
>>>
>>> On 23/07/2012 10:00, Michael Grønager wrote:
>>>>>> I get a full blockchain from scratch in 45 minutes on my
>>>>>> laptop, /M
>>>>>>
>>> Hang on a sec, in 45 minutes you can download the entire chain
>>> from the genesis block?
>>>
>>> I have been doing extensive testing in this area and would
>>> love to know what is special about your setup (I have never had
>>> the entire chain in under 12 hours, infact it is normally
>>> closerto 24.) I have an extensive setup of test machines,
>>> everything from e4300 to phenom2x6 to i5's.
>>>
>>> as an example on an amd e-450 with 4gb ram, and approx 3gb/s
>>> internet connection it took 2 hours to sync the last 5 days.
>>>
>>> Maybe i am missing something important...
>>>
>>> Any additional information that you could provide to help me
>>> with testing would be really appreciated.
>>>
>>> cheers,
>>>
>>> steve
>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>
>>>>
>>>>
Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's
>>>> security and threat landscape has changed and how IT managers
>>>> can respond. Discussions will include endpoint security,
>>>> mobile security and the latest in malware threats.
>>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>>>
>>>>
------------------------------------------------------------------------------
>> Live Security Virtual Conference Exclusive live event will cover
>> all the ways today's security and threat landscape has changed
>> and how IT managers can respond. Discussions will include
>> endpoint security, mobile security and the latest in malware
>> threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 10:24:57

- reply

📅 Original date posted:2012-07-24
📝 Original message:Hi Michael,
from what I have noticed, bitcoin blockchain download/verfication all
happens in 1 thread. (so multicores doesnt really help)
That said, I have never tried on an ssd.
What I do have is 6 SATA 6gbs configed as RAID0 Drives.
32gb of ram. ubuntu 64 (yeah I know), this runs upto 16 VM's
(I have 4 of these)
However I have not tried to download the blockchain on the master os,
just in virtulisation. However, the dedicated machines that I have been
using for benchmarking the VM's against is a q6600 8gb ram sata2 hdd -
Win 7 (seems faster than slackware...) to me it has always felt like
network bandwidth was the issue. I might instrument the bitcoin-qt exe
to only pick low ping nodes (has someone already done this?)
I guess it is time to start some benchmarking (like the gpu comparison page)
hte verification for the 5 past 5 days was negliglable. I am off on a
flight to australia tomorrrow, so I will set some breakpoints and do
some timings in a debugger.
This will all happen on an e-450 (wonderful machine!)
Thanks very much for your response. it would seem that I am 'doing it
wrong' :/
cheers mate,
steve
(this message isnt signed because I have forgotten my password.)
On 24/07/2012 09:25, Michael Grønager wrote:
> Hi Steve,
>
> 45-90 minutes - note that its numbers from March/April, so a bit
> longer today, but far, far away from the 12 hours.
>
> I am using libcoin and the bitcoind build based on this. Libcoin is
> based on the Satoshi client, but refactured to use an async
> concurrency model. I also did a minor tweeks to the db parameters. It
> has earlier been tested up against Satoshi bitcoin where on some
> OS'es it performs similarly (at least on some linuxes) and on some
> faster (e.g. mac).
>
> What is your CPU load during a block download ? (both initially/up to
> the point where verification sets in and after). The initial download
> is typically disk I/O bound, the verification stage CPU bound, though
> I lean to believe that even there it is disk I/O bound (at least on
> my system ~50% CPU load). What should be better in libcoin is the
> concurrency model. The Satoshi client uses a pure reentrant mutexes
> model, that is not generally believed to motivate the best coding
> practice nor performance, you might end up without the concurrency
> you initially strived for *). As mentioned earlier libcoin uses a
> pure async concurrency model (and so does libbitcoin btw).
>
> I would like to stress again that these numbers will depend largely
> on the system running the test - I would call my laptop a bit over
> the average today (MB Pro, 2.66Ghz i7 dual core, 8GBRAM, 512GB SSD).
> But again 12 hours - I only reach such numbers on some of my VPS'es
> (linode 1024) that are known for notoriously slow disk I/O. (here I
> have a few % CPU load during the verification indicating indeed that
> the disk i/o is the culprit).
>
> Cheers,
>
> Michael
>
>
> *) I like this Dave Butenhof quote: "The biggest of all the big
> problems with recursive mutexes is that they encourage you to
> completely lose track of your locking scheme and scope. This is
> deadly. Evil. It's the "thread eater". You hold locks for the
> absolutely shortest possible time. Period. Always. If you're calling
> something with a lock held simply because you don't know it's held,
> or because you don't know whether the callee needs the mutex, then
> you're holding it too long. You're aiming a shotgun at your
> application and pulling the trigger. You presumably started using
> threads to get concurrency; but you've just PREVENTED concurrency."
>
>
>
>
> On 23/07/2012, at 17:54, steve wrote:
>
> Hi Michael,
>
> On 23/07/2012 10:00, Michael Grønager wrote:
>>>> I get a full blockchain from scratch in 45 minutes on my
>>>> laptop, /M
>>>>
> Hang on a sec, in 45 minutes you can download the entire chain from
> the genesis block?
>
> I have been doing extensive testing in this area and would love to
> know what is special about your setup (I have never had the entire
> chain in under 12 hours, infact it is normally closerto 24.) I have
> an extensive setup of test machines, everything from e4300 to
> phenom2x6 to i5's.
>
> as an example on an amd e-450 with 4gb ram, and approx 3gb/s
> internet connection it took 2 hours to sync the last 5 days.
>
> Maybe i am missing something important...
>
> Any additional information that you could provide to help me with
> testing would be really appreciated.
>
> cheers,
>
> steve
>
>>
>> ------------------------------------------------------------------------------
>>
>>
Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions will include endpoint security, mobile security and the
>> latest in malware threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________ Bitcoin-development
>> mailing list Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>

2023-06-07 10:24:48

- reply

📅 Original date posted:2012-07-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Michael,
On 23/07/2012 10:00, Michael Grønager wrote:
> I get a full blockchain from scratch in 45 minutes on my laptop,
> /M
>
Hang on a sec, in 45 minutes you can download the entire chain from
the genesis block?
I have been doing extensive testing in this area and would love to
know what is special about your setup (I have never had the entire
chain in under 12 hours, infact it is normally closerto 24.) I have an
extensive setup of test machines, everything from e4300 to phenom2x6
to i5's.
as an example on an amd e-450 with 4gb ram, and approx 3gb/s internet
connection it took 2 hours to sync the last 5 days.
Maybe i am missing something important...
Any additional information that you could provide to help me with
testing would be really appreciated.
cheers,
steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJQDXO4AAoJEFvEB9dQFvtQxdcH/ieqQkyDCg8mKeOa6CqsWaS6
fhoeny3Ke2b/CsvhYmsThCvntN9volIqR2CTn5tkHiVwG9OmlxyHZcNpN0ZTHhK5
lsfLap/Y0QpiysXpV4Bu7Z4Hwp9jnhOP74TshT305r2pX6EGXPQ0CrlHqlIry/X/
vNcunUclliou+KjL7EHcY50GH5wDpqJAjlNyF97Lj9YiPrAC9vahGwWdxkbCYtG+
KUuWGBKMMdHuMAgcQh7nI9q0WT3k/gzRQtuC2kf+v0wvQhaGlTVkku4uanhpuw4p
99blRF3/SfWimGuQgsm6wT3Y7dk+z8MFHLb6XGPxmgV9+gF+TWNczfU3GRzfcXw=
=CQkI
-----END PGP SIGNATURE-----