Caleb James DeLisle [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-07-28 to 2013-07-09
💬 Posted a total of 12 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:04:21

- reply

📅 Original date posted:2013-07-08
📝 Original message:Java (Applet) security is indeed abysmal but lets compare apples to apples.
With an applet some random guy with a website makes up some Java code and
your browser automatically executes it.
With Multibit you're only executing highly trusted code (so trusted that it
handles your money).
There has almost never been a Java exploit against secure trusted code.
The idea of discouraging use of java apps just because people would be
tricked into activating the browser plugin when installing the JVM is
probably valid but Multibit is the only reasonably complete client outside
of bitcoinqt and I think client diversity is more important than stamping
out java.
Thanks,
Caleb
On 07/08/2013 08:22 PM, Robert Backhaus wrote:
> But... Multibit is Java. Java's security problems has made it an instant uninstall item on windows PCs for about a year now. Java exploits are a dime a dozen.
>
> Yes, you can reduce some of the problems by manually disabling the browser plugin, but how many users will do that?
>
> Recommending a fast SPV client as a first wallet - yes, of course. Recommending users open such a huge attack interface on their computers by installing Java - No go. Until Multibit is provided as a compiled binary without a Java dependency, it is DOA.
>
>
> On 1 July 2013 02:39, Gary Rowe <g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>> wrote:
>
> I've beefed up the supporting documentation for the website to make it more accessible for developers who wish to contribute. It's a Java application serving HTML.
>
> It can be found here: https://github.com/jim618/multibit-website
>
>
> On 30 June 2013 16:19, Jim <jim618 at fastmail.co.uk <mailto:jim618 at fastmail.co.uk>> wrote:
>
> Yeah "email jim' was never going to work so I have
> bumped up MultiBit support (a bit) by:
>
> + having a dedicated Support page on the website
> https://multibit.org/support.html
> It has fixes and support notes for the most common gotchas.
> + the in-app help also now has a 'Support' section with
> "Troubleshooting' and the commonest gotchas.
> I've also written more help to cover as much as possible.
> + Failing that people are directed first to bitcoin.stackchange.com <http://bitcoin.stackchange.com>
> (I have a notification set up for the 'multibit' keyword.
> + Then finally users are directed to the github issues to search
> existing or raise a new issue. Gary and Tim often chip in on there to
> close
> issues down as well as me.
>
>
>
> On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote:
> > Sounds like we have consensus, Saivann, shall we do it?
> >
> > I'm also going to ask Theymos again to relax the newbie restrictions
> > for the alt client forums. It's probably too hard to get support at
> > the moment and "email jim" doesn't scale at all.
> >
> > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen <gavinandresen at gmail.com <mailto:gavinandresen at gmail.com>>
> > wrote:
> > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended
> > > desktop wallet app. I think most users will be happier with it.
> > >
> > > If I'm wrong, it is easy to change back.
> > >
> > > ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by Windows:
> > >
> > > Build for Windows Store.
> > >
> > > http://p.sf.net/sfu/windows-dev2dev
> > > _______________________________________________
> > > 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
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > _______________________________________________
> > 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
>
>
> --
> https://multibit.org Money, reinvented
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> 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
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:04:05

- reply

📅 Original date posted:2013-06-27
📝 Original message:On 06/27/2013 01:56 PM, Gregory Maxwell wrote:
> On Thu, Jun 27, 2013 at 10:10 AM, Jim <jim618 at fastmail.co.uk> wrote:
>> Let me know if you think this is a good idea (or not!)
>> and if you have any questions.
>
> Being able to promote a fast SPV desktop wallet would be great!
>
> I went through an cycle of testing on multibit after I saw some
> complaints when it went up on the page before without at lot of
> discussion. There were a number of issues with it at the time, in
> particular the frequent deadlocks— though Mike was saying that those
> should be fixed.
>
> I see some of the the other things that were concerning for me at the
> time are still uncorrected though, e.g. no proxy support (so users
> can't follow our recommended best practices of using it with Tor),
If I were a Bitcoin dev, I would not want to talk about anonymity or
TOR because that's likely to attract people with paranoid dilutions
and they're really terrible users to support :)
Also yay for promoting fast, easy to use clients for casual users!
Thanks,
Caleb
> that it reuses addresses (esp for change), that it doesn't clearly
> distinguish confirmation level. It also make repeated https
> connections to 141.101.113.245? (I'm not seeing the IP in the source,
> and it doesn't have a useful reverse dns entry, so I can't tell what
> its for). Is there any timeframe for changing any of this stuff?
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 13:45:10

- reply

📅 Original date posted:2013-04-09
📝 Original message:An approach which I see as workable in the long term is to keep the block
header and an array of bitfields representing each transaction's spent
and unspent outputs. When someone wants to spend money you ask them for the
transaction and ideally you ask them for the transaction and the merkle branch
from that transaction to the header. If they want to spend the money they have
to carry around the data.
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. Perhaps worth contacting an AV company and
asking what is the smallest data they have a signature on.
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
>

2023-06-07 04:10:44

- reply

📅 Original date posted:2011-08-03
🗒️ Summary of this message: Discussion on Bitcoin DNS seeds and the need for a custom DNS server that watches the network to find long-lived peers.
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/03/2011 07:38 AM, Matt Corallo wrote:
> On Wed, 2011-08-03 at 12:04 +0200, Mike Hearn wrote:
>> This is expected to happen from time to time of course as it's
>> inherently racy, but there are a lot of bad nodes appearing in the DNS
>> seeds.
>
>> $ nmap -oG /tmp/x -p 8333 `dig +short bitseed.bitcoin.org.uk
>> dnsseed.bluematt.me bitseed.xf2.org`
>> ...
>> Nmap done: 48 IP addresses (25 hosts up) scanned in 9.80 seconds
>
>> $ grep -c 'closed' /tmp/x
>> 6
>
>> So of 48 IPs returned only 19 are actually usable. This is slowing
>> down peer bringup for the Android apps, which don't currently save the
>> addresses of last-used peers (yes, I know we should fix this).
> Its actually much, much less. You forgot to grep for filtered, which
> are also worthless and you didn't make an actual connection to the node,
> meaning there is no way to tell if the node has its connection slots
> full (a node which has the maximum connection count will ack a syn, but
> will drop the connection after the first message, so nmap thinks the
> port is open).
> I just tested and I show 0 accepting from bitseed.xf2.org and 0 from
> bitcoin.bitcoin.co.uk. dnsseed.bluematt.me rotates every 2 minutes to
> the most recently checked so it tends to be pretty good if you get it
> right after a rotate, if you wait to long, those slots fill up quick.
Someone I know who runs a moderately large website told me that some ISPs cache DNS for as long as a week without regard to TTL.
If your DNS seeds are not pointing to your own dedicated boxen then you might want to do a lookup on a random cookie as a subdomain.
Caleb
>>
>> I was talking to a friend a few days ago about Bitcoin, he seemed
>> interested. I'm hoping he might take on DNS seeding as a project. A
>> custom DNS server that watches the network to find long-lived peers
>> that run the latest version would be helpful for resolving this kind
>> of thing.
> Point him to https://github.com/TheBlueMatt/dnsseed it could use a bit
> of cleanup, but it works.
> If a different DNS Server were used to could pull directly from the
> database in a more dynamic way it would probably work better too (it was
> originally set up on MySQL and PowerDNS, but that is quite a resource
> hog compared to SQLite and BIND, but the original backend is still there
> and could work if you have a beefy enough server).
>
> Matt
>
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBAgAGBQJOOT64AAoJECYAmptlsgnWNNYP/3pk/61AOaTo8577XF2E3RWU
hqPclOYMveBZveo7Hz0k/Vf3TMf5p7CFGtFllApVmmR5ck4hXwow+tXwaYvBuf9b
4QwDlNtBelZ+7DqOdDTxRjaRzBo7PlsuiEp+6B3+oggfjKWnkWlIighfM/6LOtMO
kv+MsC9xulqCrX96FrQBERVknkvza8NWfVblAFCM0uxECC5Hd52W1Okx1cDqUsIj
MAp6T6IDwy1u0WtYIZBbD3KR802tqTpx/gzElo2AAz4ZR8P9yATBbAjmd9vZDscB
SRF5yg+BIAzTQzz84c0cno8Q6hFyieRLTu9x0AWUqAZPTL3OgYV7hyl9WXMzcQGY
LgnG9hP5N9qn2S+rYJuNJwvTJhzaLgUwOdRgyisI8v86R5vEjOpAAPVStAgCtvw2
6BJJvit3iZ74fK37kPb4iEljd11ibb8rOoiZzKSuS6LMJXkCplQQ06Uhy9MFd/Wn
UZbSwbXqizJmQUPnHfCvvJc9fmoPFbj4SpYagxXFbUXtQsuB84h1e/jKAf5cvRed
n0fLfKBZJuAfK1B/lV8+R6+oJj6F2OSGdCpdGzMlrxKX3JPcDJGK56/JmFzaqXyA
ScaYja4yps83l80zt7H9Fadl642tNWXsdETniyDt2ADnqr1u/nWr9m+aT7oskbZA
SfO+U22w9JC0CW8u5fAa
=7WNK
-----END PGP SIGNATURE-----

2023-06-07 04:09:04

- reply

📅 Original date posted:2011-07-28
🗒️ Summary of this message: Bitcoin developers are split between early adopters, ambitious people, and hobby developers, making it hard to justify volunteering work. Sponsorship and grants for active developers could help. Separating Bitcoin the program from the blockchain and accepting patches for merged mining and alt chain stuff could also decrease the feeling of "people making money off my back."
📝 Original message:Bitcoin seems to have a relatively unique problem, there is a perception that there are early adopters who still have large stashes of btc.
Not that this is wrong, they knew a good thing early, the problem is that it is hard for someone (me) to justify volunteering work on a codebase which will directly benefit other people even if they do nothing.
>From my brief observation it appears that the developers now are split between early adopters who are working on their investment, ambitious people who are working on alt clients to satisfy certain requirements for their own projects and hobby developers donating code to alt chain clients because chains which have not taken off don't benefit anyone yet.
As far as trying to bring these people together, I don't have any silver bullet answers but I think there needs to be some kind of sponsorship of developers. I2P uses bounties but they are indeed a small community, I can see bounties going very wrong but I suppose it doesn't hurt to experiment. I think grants for active developers make more sense, then we only need someone to decide who is active enough.
Also moving in the direction of seperating bitcoin the program from Bitcoin the blockchain and accepting patches for merged mining and alt chain stuff which doesn't directly benefit Bitcoin would help decrease the "people are making money off of my back" feeling that (IMO) stands in the way of new developers.
Caleb
On 07/27/2011 08:15 PM, Jeff Garzik wrote:
> Linux kernel has not solved this problem; developers simply want to
> work on interesting stuff, rather than debug, I think.
>
> The best Linus has done so far it making certain periods of time
> bugfix-only, refusing to take new feature pushes during the stability
> period. If there are critical bugs, refusing to release the kernel
> until a developer fixes the regressions they added.
>
> Linux is large enough, though, that the ecosystem has grown a support
> network, where companies pay for support (one big way my employer
> stays in business), which includes bug fixes. So the paid support
> orgs, like Red Hat, wind up going a lot of grunt work fixing because
> they are the closest contact to actual users in the field encountering
> problems with the Wonderful New Features bestowed upon them by
> developers.
>
> "drop and run" coding is a term for developers who appear, commit a
> new feature, and then disappear without addressing bug reports or
> other feedback regarding their contribution.
>