<unnamed>

Public Key

npub138d0km3t8jujy9duwng26dh79fwuxqhw0xmxjdw2h2t2dgwzwpxsk9dl95

Profile Code

nprofile1qqsgnkhmdc4newfzzk78f59dxmlz5hwrqth8ndnfxh9t494x58p8qngpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsk3sd9q

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:04:21 UTC

- 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:01:53 UTC

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

- 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 11:45:10 UTC

- 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 02:10:44 UTC

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