<unnamed>

Public Key

npub18yq2ukhtlnkuzzykluyjvxap3vtvdqf0arvtag6rx02klk6gymgqp3txp2

Profile Code

nprofile1qqsrjq9wtt4lemwppzt07zfxrwsck9kxsyh73k975dpn84t0mdyzd5qpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvztsad2

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 02:50:03 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: Adding anonymity to a slow system is impossible, so Stefan Thomas suggests using Tor or Freenet for anonymity instead of complicating the protocol.
📝 Original message:On 12/18/2011 1:19 PM, Stefan Thomas wrote:
> Let those who want anonymity connect through Tor, Freenet, etc. It's
> easy to add anonymity via an extra layer, but it is impossible to add
> performance on top of a slow system.
That's a very good point. This is needless complication at the protocol
level. Alternatives, like Tor, could be used to provide the desired
effect. Developers could even choose to integrate Tor functionality into
the client itself at some point.

2023-06-07 02:49:03 UTC

- reply

📅 Original date posted:2011-12-17
🗒️ Summary of this message: Firstbits is an interesting idea but produces a less desirable solution compared to current alias proposals, according to Matt Corallo. It doesn't scale and provides incentives for people to spam the chain to get a firstbits address.
📝 Original message:While I think firstbits is an interesting idea, I agree with Matt on
this one. Firstbits, while being a clever idea, produces a less
desirable solution in comparison to the current alias proposals.
In addition to Matt's reasons, I would like to add that it is still a
block of random characters, just shorter. It creates the undesirable
effect of having addresses short enough that people may try to type it
in rather than pasting or scanning, which is more error prone.
One obvious scenario for potential exploitation would be if a large
organization adopted a firstbits address for donations. Others could
immediately try to collect similar addresses in hopes of a typo. A
second would be if the organization published the firstbits address on a
poster in a public location. Someone could easily secure a firstbits
address which was one character longer, then stencil that extra
character on to the poster.
On 12/17/2011 8:15 AM, Matt Corallo wrote:
> On Sat, 2011-12-17 at 12:14 +0100, Jorge Timón wrote:
>> Don't know much about QR codes, but I thought they have a length limitation.
>> Why jav wants to use not just addresses but firstbits then?
> Under no circumstances should the use of firstbits ever be supported.
> It doesn't scale, not even close, especially as we (hopefully) move
> towards SPV clients. Also, it provides incentives for people to spam
> the chain to get a firstbits address. Never should that be supported.
>
> Matt
>
>
> ------------------------------------------------------------------------------
> 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:47:09 UTC

- reply

📅 Original date posted:2011-12-15
🗒️ Summary of this message: Publicly available alias system may be vulnerable to DOS attack, as creation of new Bitcoin address requires retention of private key indefinitely.
📝 Original message:I believe it is also worth mentioning the possible susceptibility of a
DOS attack on a publicly available alias system. Assuming that an alias
lookup triggers the creation of a new Bitcoin address, the private key
would need to be retained indefinitely. If gone unnoticed, this could
consume considerable resources over time. Unlike system logs and such,
this is not something that can be so easily pruned.

2023-06-07 02:45:10 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: MIME libraries are buggy and difficult to work with, with weak support. MIME functions still live in e-mail libraries, as it is the most common case.
📝 Original message:I wish that was the case. It would have made my life a lot easier in the
past. A lot of the MIME libraries out there are extremely buggy. MIME is
just difficult to work with, and support is still weak.
Undefined content length + text based boundaries = pain in the ass.
It is in the e-mail module because that's all MIME was originally
intended for. It's now grown beyond that now, but you will find the MIME
functions still live in the e-mail libraries. When dealing with raw MIME
encoded data, e-mail is still the most common case.
On 12/19/2011 11:16 AM, Luke-Jr wrote:
> MIME has been around much longer, and should have sufficient support in every
> language by now. For some reason, Python calls the module 'email'.

2023-06-07 02:45:04 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: The use of binary data is necessary for efficient processing, but JSON-RPC still serves a purpose for high-level language developers. Support should not be dropped entirely.
📝 Original message:I believe I'm missing something here. I was under the interpretation
that alias resolution was going the KISS route, of basically a single
HTTP request and response. How do you see binary data fitting into this?
I'm not going to pretend that I know all the details of the difficulties
that were encountered with JSON-RPC. But in the argument of developer
accessibility, it still serves a purpose. If JSON-RPC support is
removed, you will immediately lose a large pool of high level language
developers. I would hope that support would not be dropped, even if it
only remains as a secondary protocol with limited capability. Most high
level developers are only going to use it for basic functions anyhow.
On 12/19/2011 10:15 AM, Luke-Jr wrote:
> Because computers work with binary. I don't think anyone wants to implement a
> fully functional script assembler just to send funds.
>
> JSON-RPC won't go on forever. In any case, bitcoind's use of JSON-RPC is
> exactly why I (and many other developers) have come to the realization how
> poorly supported JSON really is. Most of the common languages do have a
> library, but almost all of them have one issue or another (particularly around
> the very undefined Number type).

2023-06-07 02:44:58 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: The author suggests that a simple plain text response of an address is sufficient for alias resolution, but worries about future compatibility issues.
📝 Original message:If alias resolution was guaranteed to always be just the address, then
yes, I would opt for no serialization at all. A simple plain text
response of an address is about as simple as it can get.
There are already a lot of good ideas floating around about how the
alias protocol could be extended. Is it really going to stay that simple
for long? I would personally much just have a serialized response
upfront, rather than having to worry about backward compatibility in the
future.
On 12/19/2011 10:17 AM, slush wrote:
> In my opinion, there's not necessary any payload format (json, xml,
> multipart). In keeping stuff KISS, everything we need is just an address
> in response + potentially some stuff like HTTP redirects (for providing
> additional compatibility for proposal of bitcoin URIs with "amount",
> "label" and other parts). I don't see reason why we need some extra
> payload yet.

2023-06-07 02:44:55 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: Protocol buffers may not be easy to implement, but they are still preferred over MIME for data transmission. JSON is not strongly favored.
📝 Original message:I don't think protocol buffers are as simple to implement as some would
like. I would still opt for it over MIME though.
On 12/19/2011 10:50 AM, Jorge Timón wrote:
> I don't have a strong position for or against JSON but...What about
> protocol buffers?
> Would it be too much too? Would it be simple enough for developers?

2023-06-07 02:44:45 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: HTTP multipart response is not simple to parse and lacks library support. JSON is widely adopted, human-readable, and has parsing libraries available for every major language. Using HTTP for data interchange will make things difficult for developers.
📝 Original message:With all due respect, I continue to disagree on the topic of using HTTP
for data interchange.
Yes, an HTTP multipart response will accomplish the need for multiple
named resources. The problem is that parsing of a multipart response
isn't simple, and library support is weak across many languages. The
widely adopted cURL library does not support multipart response parsing
at all.
JSON is widely adopted, human readable, and has parsing libraries
available for every major language. There is a bit of additional bloat,
but I believe it is warranted in this case because of the convenience
and ease it brings to developers.
If the idea is to "KISS", and provide a method that is both quick and
easy to implement for the average developer, then JSON is a stand out
option. Using HTTP for the data interchange will make things difficult
for a lot of developers if multipart responses are used. JSON will be
greeted with open arms.
On 12/19/2011 9:09 AM, slush wrote:
> I agree with Luke that HTTP standard has everything necessary and
> bloating payload with json/xml is not necessary.
>
> Btw that argument "we have json in client already" seems pretty wrong,
> because json in server rpc solves another problem (and solve it in wrong
> way, because of data type issues, but it's another story).

2023-06-07 02:44:39 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: HTTPS should be used for Bitcoin websites dealing with financials. JSON support is common, but it cannot represent binary data. Custom output script needs clarification.
📝 Original message:I still think HTTPS should be used, at the minimum. Using HTTPS is
standard to every website out there that deals with financials, even if
it is not a perfect system. Why should Bitcoin adopt a more lax policy
than everyone else?
I thought that JSON support was fairly common these days. I personally
prefer XML in most cases, but since JSON is already used with the RPC,
it seemed like a natural fit here. Binary data can be base64 encoded,
although I'm not sure why you would need to send back binary in an alias
response.
What exactly do you mean by "custom output script"?
On 12/19/2011 8:30 AM, Luke-Jr wrote:
> I'd prefer we stick to simple standards.
> HTTP alone should really be fine to build on...
>
> JSON in particular has very poor language support, and cannot reasonably
> represent binary data (such as a custom output script). The HTTP
> specification, however, allows binary data in multipart content just fine.

2023-06-07 02:43:55 UTC

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: HTTPS requirement is debatable, but a warning message should be displayed if HTTP is used. JSON is the assumed structure for the answered message format.
📝 Original message:I can't speak for Namecoin. As for the HTTPS requirement, I'm on the
fence. Without it, the resolution is open to a man in the middle attack.
Perhaps HTTPS should be required, and if HTTP is used, a large warning
message is displayed.
As for the answered message format, is JSON the assumed structure that
would be used?
On 12/18/2011 1:05 PM, Jorge Timón wrote:
> If we chose the simple URI proposal namecoin can still be integrated
> to map the IP of the server by those who want to.
> Does it removes the necessity of the certificates?
> If so, we should let people decide between HTTP, HTTPS, namecoin or
> whatever they trust.
>
> Shouldn't we be also discussing the valid format of the answered
> message? I mean fields like "amount", "concept" and such.
>