<unnamed>

Public Key

npub16cadfx8ew8z4qmsmsd9kndvntt4uad7vsdmkjer4jd8wjq4swxrqp2gy5d

Profile Code

nprofile1qqsdvwk5nruhr32sdcdcxjmfkkf4467wklxgxamfv36exnhfq2c8rpspz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqj3z5yf

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 11:45:14 UTC

- 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:33:31 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:27:26 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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-----