Jordan Mack [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-11-05 to 2011-12-21
💬 Posted a total of 15 messages
📚 Participated in the following categories: Bitcoin-development, BIP 15
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 04:51:17

- reply

📅 Original date posted:2011-12-17
🗒️ Summary of this message: The scalability of broadcast messages and the resources required to sync and verify the blockchain are two problems that need to be solved. Three distinct groups of clients are miners, full, and lite. To address scalability, there could be three separate modes of operation. Mining nodes would handle the brunt of the barrage of messages, full clients would only need new block data and new transactions that pertain to them, and lite clients would connect to a trusted full client over an encrypted connection.
📝 Original message:theymos' full node and lite node write up got me thinking.
There are two problems here that we are trying to solve:
- The scalability of broadcast messages.
- The resources required to sync and verify the block chain.
I see three distinct groups of clients:
- Miners (dedicated servers & desktops)
- Full (desktops)
- Lite (mobile devices)
To address scalability of broadcasting, there could be three separate
modes of operation (or client types). Mining nodes would retain the
complete block chain, and share all messages between other mining nodes.
Full nodes would retain the complete block chain, receive new block
information from mining nodes, and share block data between each other.
Lite clients would not contain the block chain, or any broadcast
messages, and would query against a full client for all actions.
Mining nodes would handle the brunt of the barrage of messages. All
block and transaction messages would have to be broadcast across all
mining nodes. This would be essentially the same as all clients
currently operate today.
A full client would be one step down from a mining client. They only
need new block data, and new transactions that pertain to them (for
instant notification). All other broadcast data is irrelevant to them.
They would get new block data from connections to mining nodes, or from
other peer nodes. The transaction submission could be sent directly to a
connected mining node, or bounced through other connected full nodes,
with a random number hops. This would disassociate the IP from the
transaction, similarly to Tor.
To address the need for instant transaction notification, without
broadcasting to to everyone, notification messages would be sent
directly from one full client to the other. This is where aliases come
in. When an alias is resolved, it includes both a Bitcoin address, and a
list of IPs to notify of the transaction. This reveals the IP of the
sender and receiver to each other. If the sender or receiver wishes to
remain anonymous, then they could opt out of notification, and wait for
the transaction to appear in the block chain.
A lite client would connect to a "trusted" full client over an encrypted
connection. This would essentially function as a remote control to a
full client, and allow a user to send, receive, and confirm normally,
but without the overhead. A full client could reside on the home
computer or server, which is owned by the user. A hosted wallet could
also be used just as easily.
I don't like the idea of a header only client, unless this is just an
interim action until the full block chain is downloaded in the
background. Development of these types of clients is probably
inevitable, but I believe that this breaks the most fundamental aspects
of Bitcoin's security model. If a client has only headers, it cannot do
full verification, and it is trusting the data from random anonymous peers.

2023-06-07 04:51:11

- reply

📅 Original date posted:2011-12-17
🗒️ Summary of this message: Storing blockchain in DHT is not feasible due to the difficulty in guaranteeing against data loss or manipulation, and verifying transactions. Scalability remains a problem.
📝 Original message:While using DHT for storage of the block chain is an intriguing concept,
I do not see how it is feasible. As Gavin noted, DHT is a system that is
difficult to impossible to guarantee against data loss or manipulation.
Even if we found a way to store the block chain in DHT, how would
transactions be verified? As Gavin noted, you could ask the network, but
cannot necessarily trust the peers you are connected to. Verification of
the full block chain allows the client to trust no one.
I also do not see how DHT would solve the problem of scalability in
regards to broadcast messages, although I am definitely interested in
the concept.

2023-06-07 04:50:58

- reply

📅 Original date posted:2011-12-21
🗒️ Summary of this message: If Bitcoin replaced all credit card transactions, it would require 1.14GB per block and 58.5PB per year, with a distribution of 2MB of block data per second.
📝 Original message:I think it would be a lot more than that. According to the Scalability
page (https://en.bitcoin.it/wiki/Scalability) if Bitcoin took over all
credit card transactions, that would be about 1.14GB per block. I
believe that is 58.5PB per year. (6*24*365*1.14/1024) This would also
mean the distribution of 2MB of block data per second, which doesn't
include broadcast overhead.
On 12/21/2011 12:50 AM, Michael Grønager wrote:
> when bitcoin takes over all credit card transactions (!), and even before that,
> we will meet a scalability problem. The blockchain will grow rapidly,
> (1MB/10min or 50GB/yr)

2023-06-07 04:50:03

- 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 04:49:03

- 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 04:47:09

- 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 04:45:10

- 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 04:45:04

- 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 04:44:58

- 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 04:44:55

- 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 04:44:45

- 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 04:44:39

- 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 04:40:19

- reply

📅 Original date posted:2011-11-17
🗒️ Summary of this message: Bitcoin-qt.exe crashes intermittently during rapid RPC command sending, with single letter commands triggering the crash most often. No issue has been logged.
📝 Original message:I'm getting an intermittent crashes on bitcoin-qt.exe when doing RPC
commands. I seem to be able to get it to occur most frequently when I
send a bunch of RPC commands in rapid succession. I have never
encountered it with "getbalance", but I have with some other commands.
Sending a single letter as the command seems to trigger the crash most
often.
I was unable to generate the crash using 0.4.1.
I was unable to find an issue logged for this, although I wonder if it
is related to https://github.com/bitcoin/bitcoin/issues/639
Can anyone make suggestion on any other debug information I can gather
before submitting an issue?
Windows 7 x64
Bitcoin 0.5 rc5
Faulting application name: bitcoin-qt.exe, version: 0.0.0.0, time stamp:
0x4d44aa00
Faulting module name: bitcoin-qt.exe, version: 0.0.0.0, time stamp:
0x4d44aa00
Exception code: 0x40000015
Fault offset: 0x00e4b7fa
Faulting process id: 0xf80
Faulting application start time: 0x01cca56065158dac
Faulting application path:
C:\Users\jmack\Desktop\bitcoin-0.5.0rc5-win32\bitcoin-qt.exe
Faulting module path:
C:\Users\jmack\Desktop\bitcoin-0.5.0rc5-win32\bitcoin-qt.exe
Report Id: 050b54aa-1155-11e1-86c0-f46d0496aff0
On 11/16/2011 8:34 AM, Gavin Andresen wrote:
> I need help sanity testing these:
>
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/test/
>
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/test/
>

2023-06-07 04:37:39

- reply

📅 Original date posted:2011-11-05
🗒️ Summary of this message: Strict adherence to the protocol is necessary for financial transactions. Clients that do not comply should be rejected. A user agent string can be added, but kept separate from the protocol version.
📝 Original message:> If clients break the network protocol/do not comply properly with it,
> they should be disconnected and shunned. Hard love. We don't want any
> ambiguity in the protocol.
> However my feeling about the user-agent string is that it is a vanity
> item, but here we'd be enforcing a format that everybody can
> understand and read.
I agree with Amir completely on both these points.
With something as critical as financial transactions, no exceptions can
be made. The reported client and version should be ignored completely.
If a client does not comply with the protocol, they must be rejected
outright.
It is not in the best interest, or ability, to attempt to micromanage
how developers choose to use the information given. Recommendations and
guidelines can be made, but how they choose to implement is ultimately
their decision. In my opinion, clear and concise definition of the
protocol, and strict adherence in the mainline client, are the best
options available.
The protocol version should be indicated so that it can properly be
handled. Neither the name of the client, or it's version, need to be
reported in this. Protocol validation should ignore this completely.
I do not believe that leaving out the client name and version entirely
is the best option though. As silly as it may seem to some, vanity and
recognition are very strong motivators. We want to encourage more
supporters to the scene, not scare them away. The additional data
provided by this could also be used for calculating various statistics.
It sounds like BitcoinJ and BitDroid have already found ways of adding
it in anyway. I believe it is in the best interest of the developers to
formalize how this information will be included, and use it to their
advantage.
TL;DR: Adhere strictly to the protocol, and reject clients that do not.
Add a user agent string of some kind, but keep it separate from the
protocol version.