solar [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 03:00:46

- reply

📅 Original date posted:2012-01-31
📝 Original message:We split IRC among all those channels to handle the load when there were 60k clients.. the ideal thing would be some kind of dynamic sizing, and this applies to the number of outbound connections and transaction relaying logic too.. the same values that work for 1k clients don't work as well for 50k. It is difficult to get this kind of thing tuned correctly, especially with the added complexity of potentially malicious nodes.
I think the observed isolation problems, with or without IRC, are simply due to there not being many bitcoin nodes leaving/joining the network. The ones that are stable are happy with their 8 connections or whatever they're set to, and they're just relaying. There are only about 5k clients on IRC now.. it would probably work to go back to the single channel model as (at least from the IRC point of view) the usage is declining not growing. Maybe people are just turning off IRC though. IRC works well with many channels having a few clients each, not with one channel having many clients. We considered probing bitcoin clients to see if they're listening and favoring those clients in the WHO response, kind of like the DNS booters, but nobody got around to doing it.
Still, I think it's good to have a bunch of different ways to bootstrap in case one or the other is broken/poisoned.
Laszlo
On Jan 31, 2012, at 2:57 AM, Gregory Maxwell wrote:
> On Mon, Jan 30, 2012 at 9:05 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
>> I've also been wondering if it is time to remove the IRC bootstrapping
>> mechanism; it would remove a fair bit of code and we'd stop getting
>> reports that various ISPs tag bitcoin as malware. When testing the
>> list of built-in bootstrapping IP addresses I always connect fairly
>> quickly, and the DNS seeding hosts seems to be working nicely, too.
>
> Sο— would we remove it or leave it deactivated as a fallback users can turn on?
>
> I have two different thoughts about IRC depending on the answer.
>
> I think it's important that we have more mechanisms then just DNS and
> hardcoded seednodes.
>
> This is important because the mechanisms we have are all pretty
> subject to blocking. Now— before you say it— Bitcoin isn't intended to
> be blocking resistant (combine it with Tor and Tor anti-censorship
> tools) but by making blocking a bit harder we discourage people from
> even trying, even if we're not seriously in the anti-blocking
> business— and it gives bitcoin users more confidence because there is
> a bit less FUD "What if your ISP blocks it?? It uses DNS! Someone
> might take away the domains! SOPA PIPI ACTA CIPA Alakazam".
>
> Is the fact that users can addnodes / addr.txt enough of an
> alternative to address this? _If so_, then removing it is a good
> idea. I volunteer to maintain a multi-channel joining node for the
> foreseeable future to avoid letting old clients get partitioned
> (several people need to do this).
>
> An area where I think our mechanisms are inadequate absent IRC is
> announcing new nodes. I had a new listener up for over a week recently
> and was basically getting no inbound until I enabled IRC. I
> volunteer to do some measurement of this (e.g. bring up some nodes
> with no irc and find out how long until sipa hears about them). If
> DNS seeds are slow to learn about new nodes we may need to add a
> simple UDP announcement feature.
>
> In any case, I hadn't been thinking that we would completely remove
> IRC— I was expecting us to keep IRC around but turned off.
>
> In particular I think it may be a little risky to turn off IRC at the
> same time as deploying addrman, because if addrman has unexpected bad
> behavior IRC is what may keep things going. Obviously it should be
> well tested enough to feel confident, but belt-and-suspenders is the
> way to go.
>
>
> If we do keep in the long run I think it's important to _fix_ IRC.
> Right now it has some really stupid behavior which is highly
> pro-partitioning.
>
> */who only returns a few nodes, and because most idlers aren't
> actually working (no port forward) it's usually for there to be only a
> few that work. (I've never seen zero, but I've seen 1).
> *Other than who we only learn about nodes when they join. But the
> stable long lived nodes we need to hear about seldom rejoin. Nonuseful
> windows boxes go up and down a lot.
> *Nodes sit in a single channel forever. There are 100 of them.
> Especially with fewer clients on line nodes may be sitting alone with
> no correctly working nodes with them.
> *Nodes recently seen on IRC are highly promoted in the peer selection.
>
> So, here is an updated irc.cpp which I've been running (in various
> versions) for a while:
> http://people.xiph.org/~greg/irc.cpp
>
> It does the following things:
> * Only stays connected for a half hour
> * If its sure its not listening it uses a random nick so people won't
> try to connect
> * Reconnects if it needs more connections
> * If the node is actually listening (evidence by actual incoming
> connections) it reconnects on its own every 1-2 hours and joins two
> channels at random rather than one.
> (it doesn't change peer selection— It's hard to be confident of the
> impact of that change. I think addrman makes it less of an issue)
>
> I've only not submitted it as a pull request because I haven't had a
> chance to test to my standards, and because I felt unsure about the
> future of IRC.
>
> I feel strongly that if we're going to keep IRC as a backup we should
> fix it. If we're not going to bother then thats fine— but I think we
> need to think carefully if we're doing enough for bootstraping (with
> the points I made) without it.
>
> Certainly getting it off by default would be a good move. The botnet
> allegations are horrible.
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 02:56:50

- reply

📅 Original date posted:2012-01-17
📝 Original message:Dear bitcoin-development,
One of the original reasons for the creation of this mailing list was because the bitcoin.org forum was filled with this type of noise and this list was to provide a medium for discussion of development topics. This entire SOPA thing is off topic for this list. Might as well argue about abortion, because you can pay an abortion doctor with bitcoins.. maybe.
Many of us subscribe because we're interested in the technical discussions.. not internet trolling. Several people have already expressed that they don't care about this, so please discuss it somewhere more appropriate for this topic, like the bitcointalk forums.
Thanks,
Laszlo
On Jan 17, 2012, at 4:16 PM, James Burkle wrote:
> I don't think this is the right mailing list for discussion of this
> Blackout topic. I know this is definitely not the right mailing list
> for proselytizing.
>
> On Tue, Jan 17, 2012 at 11:03 AM, Luke-Jr <luke at dashjr.org> wrote:
>> On Tuesday, January 17, 2012 2:42:51 AM Jorge Timón wrote:
>>> It may be a political issue, but I don't think wikipedia becomes a
>>> political organization for being against censorship.
>>> This is not about left or right. Is about free speech, one of the
>>> basic principles not only of freedom but also of democracy.
>>
>> Censorship is, in principle, good. Free speech and democracy are, in princple,
>> evil. Idolizing Liberty is also evil. Your backward morals are worse than a
>> political issue.
>>
>> How about taking a few minutes to read this article by Bishop Sanborn? ;)
>> http://www.traditionalmass.org/articles/article.php?id=13&catname=7
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 02:44:33

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: Using commercial CAs for trust is a site policy, but not necessary. Self-signed or CA certs can be used. DNSSEC and HTTPS can also establish trust.
📝 Original message:Using commercial CAs to establish trust is a site local administrative policy..
Bitcoin and operating systems have no technical need to concern themselves with this. It is a shame that the system has been abused by CAs paying off operating system and web browser vendors but this is not the only way to use it.. my policy may be (as an example) to require each party I deal with to generate their own self signed cert or their own CA cert (same thing really) and then I can trust that and only that. Obviously, commercial CAs will sell a certificate to anyone which means you trust anyone that is their customer. This is a valid site policy but not for everyone.
Rick Wesson's suggestion about DNSSEC and such is interesting since it would provide a system for that 'first contact' exchange where you can more reliably retrieve the certificate, if the site supports it. Some policies may not require this however - you can always get the trust established another way like downloading a cert file from a website or whatever else you consider adequately secure for your organization.
I think 3rd party CA lists and the DNSSEC/DANE idea are both useful ways to automatically establish trust out of band, but this is independent of the actual implementation of alias resolution, which happens after a trusted connection is made. Automatically establishing trust with the alias resolver is perhaps a useful feature, but not a requirement for either side to support alias resolution.
In any case, it sounds like using HTTPS and x.509 certs would allow many of these automatic trust establishment systems to be implemented on top, allowing flexible policy configuration, which seems to be important to several people in this thread of discussion.
I think using JSON would be ok but like it's been said, you either have to serialize your binary data into some text format like base64/UUencode or represent it as an integer array, both of which are inefficient.. probably cancelling out any benefit of using JSON in the first place :)
Maybe there is no need for binary data for alias resolution though.. I imagine it would be as simple as submitting a name to resolve, and giving back a base58 address string, perhaps along with a textual comment or other extra, information data.
Being strict or lax or anything else is not really a concern for alias resolution - establishing trust is an administrative issue with a lot of different solutions and not every site or application requires trust. HTTPS and mutual authentication may be desirable for general cases, however HTTP should work just as well if trust is established another way and thus SSL/TLS is not a requirement for the HTTP exchange to work. As an example use case, I may be using IPsec or any number of other systems external to bitcoin and alias resolution itself.
Laszlo
On Dec 19, 2011, at 4:35 PM, Luke-Jr wrote:
> On Monday, December 19, 2011 6:44:59 AM Andy Parkins wrote:
>> Perhaps we should be more strict about which CA certificates are trusted by
>> the bitcoin client: say restrict it to those who have demonstrably good
>> practices for verifying identity; rather than the ridiculous amount of
>> trust that comes pre-installed for me in my browser.
>
> Accepted CAs is/should be a property of your *operating system*, not any
> particular software. Anyhow, restricting this further just makes it even more
> unusable. Already there is only 1 or 2 CAs that will provide a gratis
> certificate for personal/small users. If you only allow high-class CAs, I
> imagine that will restrict "no key in the URI" aliases to those who will fork
> over a lot of money.
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 02:44:23

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: Trusting third-party entities for alias resolution in Bitcoin is a flawed concept, and pre-trusting the resolver may be an acceptable solution for different policies.
📝 Original message:I think HTTPS, and more specifically x.509 PKI certs and CAs are generally a good idea and (historical implementation bugs aside) the concept is technically sound and secure. What is a bad idea (in my opinion) is to trust a software vendor to decide who you should trust.. thus it is a bad idea for bitcoin software to promise any trust.
The part where the concept becomes flawed is trusting 3rd parties who have no relationship with you, to serve your interests. Now I'm just generalizing here and this is not universally true.. but internet CAs just want to sell certificates - they generally don't care beyond that, and they abuse the certificate validity dates to charge more money. All this is done under the guise of wanting to provide a secure experience to users without a prior relationship to the entity being identified. I propose that trying to follow this paradigm in bitcoin alias resolution is a bad idea because it tries to solve 2 problems at once, one of which does not have any 'good' solution, and forces a specific policy.
First, we need to resolve an alias to a bitcoin address somehow.. but secondly we need to establish trust with the entity doing the alias resolution - to make sure that we can trust the response.
When resolving an alias you will have to query an untrusted server, possibly being proxied by an 'attacker'. Presumably, an x.509 certificate will be presented, possibly self signed or chained off a self generated CA or whatever else.. but if it's your first contact then there is no possible way to know if it's correct or not. You would have to retrieve the correct public key of the CA to compare to first, possibly out of band. Get it from my website, compare it to my business card, send me an email and I'll send it to you, or get it from some other source using some other pre existing trust (a centralized and possibly private directory perhaps). The point is, the reason there is so much disagreement is because there is no good way to trust the resolver if you don't create that trust relationship prior to resolving an alias from it.
I think that having to pre-trust the resolver would be an acceptable solution to all.. Those whose policy requires a simpler process can get a 3rd party CA list, much like the ones provided with web browsers and operating systems. Those with strict verification policies can choose to pre verify every public key.. and these processes are familiar to many organizations using PKI for other things already. In a client, presenting the usual certificate detail dialog, showing the public key, subject, issuer, and thumbprint would be sufficient to allow users to implement their own policies without forcing it one way or another.
Please consider that while some organizations or users might require strong anonymity and pre existing trust, there are others who may want to do the opposite and that is just as valid, even if you or 'everyone else' disagrees with that. In the case of bitcoin, it will be used as part of a larger system, and whatever concerns are created by 'insecure' alias resolution may well be addressed in another part of the system. The most successful standards and implementations are the ones which provide the most flexibility - primarily because that allows users to extend them in ways the original designers didn't necessarily plan for.
Thanks,
Laszlo
On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:
> On 2011 December 19 Monday, Jorge Timón wrote:
>> Ok, so HTTP is not an option unless it shows a huge warning. I don't
>> know the HTTPS possible attack, but maybe it needs a warning message
>> too, from what you people are saying. Although using namecoin to
>
> The problems with HTTPS have been social rather than technical. Multiple CAs
> have been strong-armed by governments or tricked into issuing fake
> certificates by scammers. There is no technical measure around that. By
> using the CA certificate we are saying to the system "here is someone I trust
> to issue a certificate". So far, with a large number of CAs, that trust is
> misplaced.
>
> I'm of the opinion though that this problem is outside the remit of bitcoin to
> solve.
>
> Perhaps we should be more strict about which CA certificates are trusted by
> the bitcoin client: say restrict it to those who have demonstrably good
> practices for verifying identity; rather than the ridiculous amount of trust
> that comes pre-installed for me in my browser.
>
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins at gmail.com
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 02:30:14

- reply

📅 Original date posted:2011-09-29
🗒️ Summary of this message: The original CPU miner for Bitcoin didn't use any libraries like OpenSSL, and it's possible to implement SHA2 without it.
📝 Original message:It's just simple SHA2, you can implement the whole thing easily without dragging in a huge lib like OpenSSL. I guess I haven't looked at it recently but the original CPU miner was just implemented locally in bitcoin and didn't use any libs.
It's just that because it's block based, there is no need to ever recalculate the first half since the brute forcing value is in the second half of the block..
This was the original prototype for the OpenCL miner without eliminating redundant calculations and it shows the block1 and block2 calculations clearly.
http://heliacal.net/~solar/bitcoin/sha256.cl
Laszlo
On Sep 29, 2011, at 11:48 AM, Stefan Thomas wrote:
> BitcoinJS uses OpenSSL to calculate midstate:
>
> https://github.com/bitcoinjs/node-bitcoin-p2p/blob/master/native.cc#L380
>
>
> On 9/29/2011 1:40 PM, Nils Schneider wrote:
>> Yes, that's possible and what
>> https://github.com/bitcoin/bitcoin/pull/535 does. However, deprecating
>> midstate (and hash1) would allow for much cleaner code.
>>
>> A pull request for marking midstate (and hash1) as deprecated can be
>> found at https://github.com/bitcoin/bitcoin/pull/538
>>
>> On 29.09.2011 12:23, John Smith wrote:
>>> Nils,
>>>
>>> Sounds good. I'm also doubtful of depending on two crypto libraries when
>>> OpenSSL does perfectly well.
>>>
>>> However, losing compatibility with miners is not very nice. Is there
>>> really not a way to compute midstate with OpenSSL?
>>>
>>> JS
>>>
>>> On Mon, Sep 26, 2011 at 7:42 PM, Nils Schneider<nils at nilsschneider.net
>>> <mailto:nils at nilsschneider.net>> wrote:
>>>
>>> Hey,
>>>
>>> I'd like to simplify the internal reference miner and remove all
>>> dependencies on cryptopp (it's the only place we use cryptopp instead of
>>> OpenSSL).
>>>
>>> Unfortunately, cryptopp is also used to calculate getwork "midstate".
>>> This field is redundant and the miner could easily calculate it from the
>>> blockheader so I'd like to remove it.
>>>
>>> Any thoughts? Where should such a change should be announced so all
>>> miners can be upgraded?
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 02:26:26

- reply

📅 Original date posted:2011-09-15
🗒️ Summary of this message: Peer disconnection and built-in filtering in the reference client implementation may limit future innovation and cause service problems. Filtering should be implemented in a separate bitcoin proxy.
📝 Original message:I don't think that any kind of peer disconnection should be present in the reference client implementation. This is a lot like using packet filters and stateful firewalls - they are implemented based on local policy and they require constant tweaking because they always cause problems when some change in usage dictates allowing things that weren't allowed before. Essentially every new service, protocol (or creative use of an existing protocol) needs to be 'opened up' so it's a hassle to change it each time.
Perhaps there is a use for this in helping implement local policy but even something that's considered a 'liberal' filtering rule today will eventually be in the way of something legitimate and will need to be adjusted. It is not possible to just adjust this network wide when and adjustment needs to be created, so any type of built-in filtering is limiting to future innovation.
Maybe this type of thing would be better implemented in a separate bitcoin proxy - much like how a firewall can be placed between a router and network. All traffic is legitimate to a router (bitcoind) if it's formatted correctly and can be forwarded, but the firewall can implement local policy. The problem with providing this out-of-the-box is that even in the case of internet traffic, they are often misused and configured too restrictively so they end up causing service problems for the users behind them.
I think the idea is good, in that we need a way to filter out things we consider bad, but I don't think it is the job of the bitcoin client. There are tons of tunable things and people will want to tweak them - what is 'a lot' to me might be nothing to someone else. People's policies will differ greatly as you can see with everything else on the internet.
Laszlo Hanyecz
solar at heliacal.net
On Sep 15, 2011, at 4:04 PM, kjj wrote:
> Luke-Jr wrote:
>> On Thursday, September 15, 2011 8:56:24 AM kjj wrote:
>>> Luke-Jr wrote:
>>>> On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
>>>>> I'm looking for review of this pull request:
>>>>> https://github.com/bitcoin/bitcoin/pull/517
>>>> "Non-standard" transactions, or those with "insufficient" fees should not
>>>> be penalised. These are properly relay/miner policy decisions, not
>>>> protocol violations, and should be made more easily configurable, not
>>>> punished for configuration.
>>> A few non-standard transactions are probably legitimate. A whole bunch
>>> of them are probably not. I would think that assigning a point or two
>>> of badness to a peer sending one is pretty reasonable, with the
>>> understanding that we would need to adjust that as the network evolves.
>> No. There is no such thing as "non-standard transactions" really; it is simply
>> "transactions outside of the bounds that I as a user/miner will relay/accept".
>> It is perfectly legitimate for other users/miners to relay/accept transactions
>> more liberally. By penalising for transactions falling outside of your
>> *personal policies*, you would end up banning many legitimate nodes.
> It is certainly true that standardness is an artificial construct that
> only has meaning to this particular implementation of the software, but
> no meaning in the context of the protocol or the system as a whole.
>
> On the other hand, the vast, vast majority of all transactions follow a
> particular pattern. If someone gives you one that doesn't match the
> standard pattern, you might be a little suspicious, but it is no big
> deal. But, if they emit dozens or hundreds, it is hardly unreasonable
> to disconnect them until you figure out what's going on.
>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops? How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development