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 15: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 15: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 15:02:53

- reply

📅 Original date posted:2013-06-07
📝 Original message:IMO this story falls somewhere between rose colored glasses and outright trolling.
Whereas LR was a (relatively shady) company, bitcoin is an entire branch of technology
and research, I can't think of any real caselaw in the US with regards to banning a
technology, perhaps the cryptography export regulation and we all know how well that
worked. Furthermore, the non-reversibility of LR is mostly because they didn't want
to deal with mediation while the non-reversibility of bitcoin is technological barrier.
It seems AmericanBanker has a record of hosting articles which urge policy decisions:
http://www.americanbanker.com/bankthink/governments-must-co-opt-bitcoin-to-avert-disaster-1058380-1.html
that would obviously be of personal benefit to the article's author:
http://www.clearbit.com/company_management.htm
It is the very job of governments to resist the efforts of lobbyists to line their
pockets at the public expense.
While I don't think significant risk of developed countries actually banning an entire
area of research such as bitcoin, I do suspect that bitcoin's popularity lead to LR's
downfall as it will other companies which allow people to transact anonymously.
The tragedy of bitcoin's irreversibility is that it makes kidnap/ransom schemes
profitable. The relative safety of the first world is largely due to the fact that
until now, there has never been any effective way to steal significant amounts of
money. While this problem is serious I don't think it's intractable. Bitcoin offers
us a modeling tool which like never before allows us to experiment with our
motivations and build something better than even bitcoin is today.
I believe regulators are intelligent people who understand this and would rather
legitimize bitcoin than ban it. If there ever were such a ban, I would be more
concerned for the future of the country imposing it than I would for bitcoin.
Thanks,
Caleb
tl;dr haters gonna hate
On 06/06/2013 06:22 PM, Melvin Carvalho wrote:
>
>
>
> On 6 June 2013 02:19, Peter Vessenes <peter at coinlab.com <mailto:peter at coinlab.com>> wrote:
>
> So, this http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 article got posted today, noting that FinCEN thinks irrevocable payments are money laundering tools.
>
> I will hold my thoughts about the net social good of rent-seeking large corporations taking money from consumers over fraudulent reversals. Actually, I won't, I just said it.
>
> At any rate, it got me thinking, can we layer on revocability somehow without any protocol change, as an opt-in?
>
> My initial scheme is a trusted (hah) escrow service that issues time promises for signing. If it doesn't receive a cancel message, it will sign at the end of the time.
>
> The addresses would be listed by the escrow service, or in an open registry, so you could see if you were going to have a delay period when you saw a transaction go out.
>
> This seems sort of poor to me, it imagines that mythical thing, a trusted escrow service, and is vulnerable to griefing, but I thought I'd see if some of the brighter minds than me can come up with a layer-on approach here.
>
> When I think about it, I can imagine that I would put a good number of my coins in a one day reversible system, because I would have warning if someone wanted to try and spend them, and could do something about it. I'm not sure if it gets me anything over a standard escrow arrangement, though.
>
>
> Also see satoshi's comments on this, though it may be restating what others have said:
>
> https://bitcointalk.org/index.php?topic=750.0
>
> "Here's an outline of the kind of escrow transaction that's possible in software. This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible.
>
> The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.
>
> While this system does not guarantee the parties against loss, it takes the profit out of cheating.
>
> If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.
>
> The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else.
>
> Now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and I'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone."
>
>
>
> Peter
>
> --
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> CoinLab LogoPETER VESSENES
> CEO
>
> *peter at coinlab.com <mailto:peter at coinlab.com> * / 206.486.6856 <tel:206.486.6856> / SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:01:56

- reply

📅 Original date posted:2013-05-16
📝 Original message:Not only does the size of the proof grow endlessly as the coin is
passed around, the size of the UTXO set grows endlessly as more and
more of the already spent coins cannot be proven to have been spent
because the proofs are passed out-of-band. I never said the idea was
good, just interesting :)
Thanks,
Caleb
On 05/15/2013 10:45 PM, Gregory Maxwell wrote:
> On Wed, May 15, 2013 at 7:22 PM, Mike Hearn <mike at plan99.net> wrote:
>> Conceptually it sounds a lot like ZeroCoin (not in implementation)?
>
> Zerocoin conceals the connection from everyone forever, assuming the
> underlying trapdoor problem is computational infeasible, but at great
> cost.
>
> Adamcoin, depending on how its done, at most conceals the transactions
> from people who aren't a party to them... though as time goes on
> eventually everyone becomes a party to a sufficiently old coin, and
> avoiding publication creates quadratic costs in evaluating a private
> clique's claims.... so instead an implementation would make the
> identities public but only once they're burred a bit.
>
> Perhaps an extreme version of the idea is easier to understand. Ignore
> DOS attacks for a moment and pretend there is never any address reuse:
>
> Everyone creates txouts paying a P2SH addresses that have a OP_PUSH
> nonce in them and tell you recipient the nonce out of band.
>
> When the recipients spend those coins they provide the script but not the nonce.
>
> The recipient knows what coins he's spending, but the public does not.
>
> The public can tell there is no double spend though, because they'd
> see the same script twice. The person he's paying may be skeptical
> that he actually has any coin and didn't just mine some gibberish, but
> our spender tells that their receiver the nonce, and that person can
> see the coin available for spending in the chain and also see that
> there are no double spends.
>
> This could actually go on forever with no ambiguity over who owns
> what, but the out of band proofs that you have to give people when you
> spend coins would grow with the history of the coins.
>
> Since there wouldn't be much privacy once a transaction was
> sufficiently split up in any case, you instead just publish the
> unblindings once transactions are sufficiently buried. Thus bounding
> the growth of the proofs. The reason I say I need to internalize
> this more is mostly that I need to think about attacks on the
> publication for 'tained' transactions being more or less isomorphic
> to just refusing to allow spending of the 'tainted' coins in any case.
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:01:53

- reply

📅 Original date posted:2013-05-15
📝 Original message:On 05/15/2013 12:21 PM, Adam Back wrote:
> On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote:
>> If the commitment is opaque at the time of inclusion in the block then
>> I will create multiple commitments and then after revealing the
>> commitment and spend to you I will reveal the earlier commitment which
>> commits the coins to an address I control.
>
> Bit-commitments are based on deterministic one-way functions eg like SHA1(
> SHA256( public key ) ) Obviously it has to be a different one-way function
> to the coin address calculation which is RIPEMD( SHA256( public key ) ) as
> that is already public. Alternatively it can be a different serialization
> using the same hash eg RIPEMD( SHA256( 1 || public key ) ).
Ahh thanks for clearing that up, although it would limit the possibilities
of scripting it is silly of me not to think of it.
>
> There is only one commitment possible per public key - so you can only
> create one commitment that would validate to a receiver, or to the network. The network checks that there are no non-blind double spends of committed
> coins which it can do as spends require disclosure of the public key, which
> allows existing commitments to be verified, and it similarly qchecks that
> there are no blind double-commitments.
>
> Each committed coin would be:
>
> one-spend-commit = Com( spender pub ), Com( transaction )
>
> where Com is implemented as the above hash. The network just places the
> commitments in order as with conventional transactions.
>
> The committed coins are not linkable to your non-blind coin because you did
> not reveal your public key in the (largely passive) act of receiving to a
> coin address.
>
>> On the topic of reversibility, I suspect in the long term the lack of
>> chargebacks will create issues as criminals learn that for the first
>> time in history, kidnap & ransom is effective.
>
> The temporary unlinkability (until commitment reveal) is a necessary side
> effect, not a cryptographic anonymity feature like zerocoin. The
> transactions are identical to bitcoins once revealed. How long the
> committed transaction chains can be between reveals is an implementation
> choice could be 1 hop, or as long as you like. (Actually it appears to be
> up to the individual users how long the maximum chain they accept is - the
> network itself, though ordering the committed spends (if there are multiple
> spends on the same key) cant even tell how long the commitment payment
> chains are).
>
> Obviously the first coins in the network ordered committed coins on the same
> key up to the coin value are spends as verified by the recipient, the rest
> are double-spend and ignored. If someone wants to waste fees by sending
> more spends than there inputs thats up to them.
>
> Probably the typical user doesnt care about long committed chains other
> than their wallet will bloat if the chains are too long, so probably they
> would periodically compact it by revealing the long chains. Committed coins
> are probably a bit less SPV client friendly, though with correct formatting
> in the merkle trees between blocks, probably a committed coin holder can
> provide enough proof to an SPV client to verify even multi-spend committed
> coins directly (without a network feed).
>
> About privacy, up to the entire commitment chain can be opened at any time
> (to other people or to the bitcoin network in general) with the cooperation
> of any user on the chain (up to the point they saw it), so while the blind
> commitment protocol is not vulnerable to a > 50% power quorum unilaterally
> imposed policy (without even needing client updates), it is fully dependent
> on the good will of the recipients for its temporary unlinkability. Thats
> the point: it puts policy control in the users hands not in the > 50% power
> quorum.
That is indeed interesting. If I understand this properly Alice commits coins
to pay to Bob and gives Bob the transaction, Bob then commits to pay to Charlie
and gives him the related transaction. If Charlie wants to collect the bitcoin
he then reveals Alice's transaction and Bob's.
I think what you're trying to do is *almost* possible now (ab)using BIP-0016
In the output of the previous tx you put:
OP_HASH160 [20-byte-hash-value] OP_EQUAL
and in the next tx you use a new type of input which specifies it's value but
not the output which is spent. In the input script you place:
OP_DUP OP_1ADD OP_HASH160 [20-byte-hash-value] OP_EQUALVERIFY
Then a serialized script containing the normal stuff as well as the last
transaction hash and output index would be passed around out of band and the
validating nodes would execute each script with a shared stack, beginning with
the out of band one, then the input one (the OP_EQUALVERIFY) then the output.
When the serialized sigscript reaches the bottom of the stack, having been
verified twice, it will now be evaluated as per the rules of P2SH.
None of this probably works in the real world since I'm not familiar with the
actual implementation of P2SH and it probably has quite a number of things
which will break if used this way but it is interesting to see that in theory
it is possible with little change to the protocol (just a new input format).
Thanks,
Caleb
>
> If you want cryptographic anonymity its better to look to zerocoin. You may
> have noticed zero coin talked about optional fraud tracing. Its usually
> trivial to add tracing to an otherwise privay preserving protocol.
>
> The blind commitment if implemented as described (and its not obvious how to
> get more privacy from it) offers somewhat like community policing. Users on
> the chain can still themselves do fraud tracing, or any policy they choose,
> on any blind committed coins that they receive. If they dont like the
> colour of them they can refund them. The point is to enforce that this is a
> free uncoerced community choice, by individual end users, not a > 50% cpu
> power quorum choice surreptitiously imposed.
>
> Adam
>

2023-06-07 15:01:52

- reply

📅 Original date posted:2013-05-15
📝 Original message:I can't see this working, if 51% of the mining power doesn't like your
coins, when you create the commitment they will reject it.
If the commitment is opaque at the time of inclusion in the block then
I will create multiple commitments and then after revealing the
commitment and spend to you I will reveal the earlier commitment which
commits the coins to an address I control.
On the topic of reversibility, I suspect in the long term the lack of
chargebacks will create issues as criminals learn that for the first
time in history, kidnap & ransom is effective. Suffice to say after the
first >= $10mn kidnapping-for-bitcoin heist, governments will be forced
to decide how they view the system. It will likely fall somewhere between
"arrest/question anyone identified holding tainted coins" to something
nonsensical and reactionary like "blocking" bitcoin as Iran does TOR.
Thanks,
Caleb
On 05/15/2013 07:49 AM, Adam Back wrote:
> On Wed, May 15, 2013 at 07:19:06AM -0400, Peter Todd wrote:
>> Protocols aren't set in stone - any attacker that controls enough
>> hashing power to pose a 51% attack can simply demand that you use a
>> Bitcoin client modified [to facilitate evaluation of his policy]
>
> Protocol voting is a vote per user policy preference, not a CPU vote, which
> is the point. Current bitcoin protocol is vulnerable to hard to prove
> arbitrary policies being imposable by a quorum of > 50% miners. The blind
> commitment proposal fixes that, so even an 99% quorum cant easily impose
> policies, which leaves the weaker protocol vote attack as the remaining
> avenue of attack. That is a significant qualitative improvement.
>
> The feasibility of protocol voting attacks is an open question, but you
> might want to consider the seeming unstoppability of p2p protocols for a
> hint.
>
> Adam
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:01:40

- reply

📅 Original date posted:2013-05-10
📝 Original message:bzzzzzzzzzzzzzzzzzzzzzzt bzzzzzzzzzzzzzzzzzzzzzzzzt bzzzzzzzzzzzzzzzzzzzzzzt
bzzzzzzzzt bzzzzzzzzzzt bzzzzzzzzzzzt
This is a test of the emergency broadcast system, if this had been an actual
emergency, the attention signal you just heard would have been followed by
official information, news or instructions.
bzzzzzzzzt bzzzzzzzzzzt bzzzzzzzzzzzt
I'm sorry, I will shut up now.
Thanks,
Caleb
On 05/10/2013 11:49 AM, bitcoin-list at bluematt.me wrote:
> In order to provide developers with a reasonable way to test their alert-handling code, starting next Thursday, automated weekly alerts will be made on testnet.
> They will contain the message "[TEST] This is a test alert broadcast at $TIMESTAMP" (where $TIMESTAMP is the unix timestamp of initial broadcast), will expire in between 2 and 4 hours and will have varying prioriry. They will be announced at 13:00 UTC (currently 9am EST).
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 11: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 11:41:09

- reply

📅 Original date posted:2013-03-23
📝 Original message:On 03/23/2013 11:24 AM, Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 10:52 AM, Luke-Jr <luke at dashjr.org> wrote:
>> On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:
>>> Introducing super-nodes with thousands of connected peers can greatly help
>>> here.
>>
>> UDP is connectionless.
>> I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/
>
> It depends on the usage. Simply broadcasting a TX or INV to a remote
> peer does not require a connection, clearly... but you probably want
> to signal acceptance of those messages somehow.
>
> But other uses, like subscribing to a broadcast, does require some
> notion of an association.
>
> In the rough draft, a parallel TCP connection with version/verack
> sequence is required, and you may make use of it if a connection is
> needed.
>
> But that is just one approach. A more robust, heavyweight UDP P2P
> might be a hole-punching TCP alternative. It's up to the community
> and results of experimentation.
>
> Bittorrent has evolved a full transfer protocol over UDP, to get
> around firewalls and the like.
>
Bittorrent uses UDP in 2 ways and for different reasons.
The tracker protocol is now UDP because large trackers are under such
enormous strain from short lived HTTP connections (40Gb/s) that there
have been instances of upstream routers becoming overloaded from the
storm of SYN, ACK and FIN messages. UDP helps solve that.
The inter-peer protocol is now UDP because TCP does not play nice in
the context of bufferbloat and Bittorrent needs lots of active TCP
connections to work, exacerbating the problem. In this instance
Bittorrent uses a full userspace TCP stack which just sends w/ UDP.
+1 for experimenting with UDP, we might learn some interesting things.
It's worthwhile to actually speed test UDP v. TCP because the time to
send an INV on an established TCP connection with Nagle disabled may
not be significantly longer than that for sending with UDP.
Also +1 for experimentation with sending a small transaction instead
of an INV, if INVs are not being grouped because we want the fastest
possible network propagation, they are mostly overhead anyway. If
b/w is more important than propagation speed then of course TCP/Nagle
is the way to go.
Thanks,
Caleb

2023-06-07 10:36:34

- reply

📅 Original date posted:2012-10-20
📝 Original message:Another concern is sourceforge being attacked and a backdoored client uploaded.
Most people don't check signatures and I seem to recall sourceforge having some
vulnerabilities stemming from their "your own website on sourceforge" feature.
It looks like Github takes security a little bit more seriously.
Probably the best is to ask for free hosting from a reputable security conscious
bitcoin enthusiast but that basically means Tux and he's already an SPOF in the
coineverse.
Thanks,
Caleb
On 10/20/2012 04:33 AM, Wladimir wrote:
> On Sat, Oct 20, 2012 at 9:43 AM, Mark Lister <mark.lister at yahoo.com> wrote:
>>> The issue is not cryptography, it's "trade with sanctioned countries",
>> period, where making
>>> files available to download is considered trade.
>>
>> Spot on, in 2005 when I lived in (among other places) Sudan, Sourceforge
>> would block certain downloads (but not the project site). That said it
>> was trivial to bypass the restrictions then.
>
> I don't think it's related to these sanctions but to the Great
> Firewall of China, but sourceforge downloads are also blocked in
> China. Also quite easy to bypass though.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02: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 02: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.
>