<unnamed>

Public Key

npub1ezg54d03a7unwu0fckmlugxulukrg06x7jzx4engngxfg79sfcqsn6r8pt

Profile Code

nprofile1qqsv3y22khc7lwfhw85utdl7yrw07tp58ar0fpr2ue5f5ry50zcyuqgpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46q6whlwy

Publishing to

relay.nostr.net

Last Notes

2023-06-07 10:33:28 UTC

- reply

📅 Original date posted:2012-10-03
📝 Original message:And, finally, when I say "Ditto to above" I mean "I have no idea", not
"nope". Double oops.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121002/72c1d5e1/attachment.html>

2023-06-07 10:33:15 UTC

- reply

📅 Original date posted:2012-10-01
📝 Original message:I'm a big proponent of a 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. :)
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.
So, my two cents, plus an offer to bring it up at our next budgeting
meeting.
Peter
On Mon, Oct 1, 2012 at 7:28 AM, steve <steve at mistfpga.net> wrote:
> -----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-----
>
>
> ------------------------------------------------------------------------------
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121001/bf75a1eb/attachment.html>

2023-06-07 10:09:58 UTC

- reply

📅 Original date posted:2012-05-25
📝 Original message:We just implemented our own mining tool, soup-to-nuts, and I would say that
the likely motivation for what I presume are botnet owners is just economic.
It's a lot more work to make sure your merkleing and keeping up-to-date are
happening than it is to just get an 80 byte header from a central server,
and re-calc a single transaction merkle client-side.
Not to mention the extra work to keep track of what version of
getmemorypool output you're receiving work for in a broadly distributed
pool.
For what it's worth, we did this extra engineering work since we care about
Bitcoin, but if I just wanted to pull value out of the ecosystem, we would
have skipped it.
The only solutions to this are economic solutions -- making such 'cheater'
blocks less valuable, or increasing the value of the transactions.
Also note that botnet operators likely care, in the end, about fiat
currency, so going to 25 btc per block in what I think of as transaction
fee subsidies won't necessarily impact this -- it's a matter of what
happens to exchange rates vs generation rates that will matter.
I think we also have to moderate this consideration against the rights (and
arguable benefits) of someone wanting to build an express-delivery mining
service, one that will provide provably faster certification for those
adding a transaction fee of, say, 1 btc.
My own experience now in the MMO world is that we have to carefully
understand how we deal with griefers who control massive resources (compute
or gold-farmers). It may not be a winning battle to choose a solution which
harms the rest of the network in exchange for harming the griefers.
This is definitely out of the box, but one solution might be to change the
difficulty calculations to just ignore 1tx blocks; that would minimize
impact on others to a great extent, and would let someone set up an express
block service if they chose. I guess we'd have to settle on whether or not
such blocks counted towards the issuance countdown as well. Or, we could
allow only 1/10 generation fees on such blocks.
Peter
On Fri, May 25, 2012 at 9:44 AM, Alan Reiner <etotheipi at gmail.com> wrote:
> I like the concept except that it only works if every node connected to
> the miner enforces the rule (if it works). Once any one of the nodes
> forwards the block, other nodes see it coming from a node that can pass
> the challenge.
>
> I don't think any solution based on node queries will succeed, especially
> if it requires spontaneous super-majority-of-nodes acceptance. I think
> it's gotta be based on the block itself and each nodes' own info.
>
> If you could spontaneously get all miners to agree not to build off of
> anti-social blocks (however that is defined) , it would have a chance of
> making a difference, but individual miners would have an advantage
> building off the antisocial block because they only need to produce one to
> create the longest chain (and collect reward) while the miners following
> the rules need two blocks.
>
> --Sent from my overpriced smartphone
> On May 25, 2012 3:48 AM, "Christian Decker" <decker.christian at gmail.com>
> wrote:
>
>> How about a simple proof of work test? This one though does not ask for
>> CPU work but asks the miner for a random old transaction. If the miner
>> really stores the entire blockchain he will not have any problem answering
>> to that getdata request, whereas a botnet would have to ask someone else
>> for it, which could be detected if the response time deviates too much from
>> what has been previously measured (compare it against getdata for the block
>> they advertise). It's not perfect but it allows an estimate of whether it
>> is a chainless miner.
>>
>> Regards,
>> Chris
>> --
>> Christian Decker
>>
>>
>>
>> On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
>>
>>> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke at dashjr.org> wrote:
>>> > Block times are not accurate enough for that.
>>>
>>> The times in your log are very accurate, assuming your system clock is
>>> remotely accurate.
>>>
>>> --
>>> Jeff Garzik
>>> exMULTI, Inc.
>>> jgarzik at exmulti.com
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>
>>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120525/c9f827d7/attachment.html>