Nostr notes by

📅 Original date posted:2012-07-09 📝 Original message:> ...

2023-06-07T12:21:29+02:00

In reply to nevent1q…k7s3
_________________________

📅 Original date posted:2012-07-09
📝 Original message:> However that starts the project down the road of being dominated by
> our internal politics rather than what actually makes sense from the
> end users perspective.

I strongly agree, but this is *why* I suggested moving it to the wiki. I
recently had to choose an XMPP client and I looked on xmpp.org - after a
frustrating experience with their listing [1], I went to Wikipedia who
have an decent feature-based matrix [2].

(There may be better examples, but I'm using this one, because this
actually did happen.)

This is just anecdotal, but there are some reasons why wikis tend to do
a better for this kind of thing is because they are:

- more up-to-date (anyone can update them)
- more in touch with users:
-> Users can edit the page and add a column to a feature matrix for
example).
-> The editing discussions include users. I guarantee there are more
Bitcoin end users with a wiki account than a Github account.
- immediately recognizable as a wiki (thanks to Mediawiki/Wikipedia.)
As such many users will correctly treat and interpret the information
presented as community-generated and fallible.

So they are more user-oriented in the sense that they will be influenced
by a diverse set of backgrounds and views vs. a Github based page which
will be dominated by developers. If you want to see "the result of
internal politics", the current client page is a good example. We
couldn't agree on the columns for a feature matrix, so now we just have
walls of text. Some of the options that are de-facto the most popular
with users like BlockChain.info or just using your MtGox account are not
mentioned at all. When analyzing client security, Greg discussed
counterparty risks but ignored other risk factors like default backup
behavior and the usability of security features.

But even if I grant you that those clients' overall risk profile is
worse than Bitcoin-Qt's, maybe I'm happy to take that risk in exchange
for less setup/maintenance effort. Based on our support requests at
WeUseCoins I know that there are tons of users with < 1 BTC in their
wallets. If my hourly wage is 20$ and I have 20$ in my Bitcoin wallet
then spending one hour per month downloading/updating/figuring-out the
client is equivalent to a total loss.

The list is obviously designed by open-source developers and that's
fine, it's bitcoin.org, arguably we *should* try to push users in a
specific direction, arguably we *should* err on the side of caution in
order to not be caught recommending a hosted wallet that gets hacked.
But if user orientation is supposed to be the focus, then the wiki will
both allow us (because it's less "official") and force us (because users
will have a say) to include even clients we personally wouldn't use. :)

[1] http://xmpp.org/xmpp-software/clients/
[2]
http://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#XMPP-related_features

On 7/9/2012 8:30 PM, Mike Hearn wrote:
> It's easy to say, this page is controversial, so let's get rid of it.
>
> However that starts the project down the road of being dominated by
> our internal politics rather than what actually makes sense from the
> end users perspective. That route spells doom for any product. You can
> always tell when a UI or product is the result of internal politics,
> whether it be the difficulty of plug-n-play hardware on Linux (no
> driver api) to how Microsoft is incapable of producing anything that
> isn't built on Windows. Gmail labs is another example of this.
>
> It makes sense that if I go to bitcoin.org, I am educated about the
> system and what is available for it. It doesn't make any sense to have
> some stuff on the main site and other stuff on a wiki (which may get
> randomly vandalized and looks less professional), based on how
> "controversial" some developers find it.
>
> FWIW I am dead set against anyone randomly changing the website
> without a pull request and such changes should be reverted and
> resubmitted through the proper channels. I don't perceive much value
> in randomization or trying to make this page "fair". If anything, we
> need to pick somebody (one person) who has a strong focus on regular
> people and their needs, then just make them the sole committer to the
> website. That way disputes can be resolved by them making a decision,
> instead of ridiculous edit wars.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

📅 Original date posted:2011-12-18 🗒️ Summary of this ...

2023-06-07T04:49:59+02:00

In reply to nevent1q…qz82
_________________________

📅 Original date posted:2011-12-18
🗒️ Summary of this message: Stefan suggests that DHTs should focus on performance rather than anonymity, and users who want anonymity can connect through Tor or Freenet. Chris proposes a hypercube structure for the network to reduce the need for broadcasts and storage requirements on nodes.
📝 Original message:Hey Chris,

> The storage would be distributed, messages are routed on behalf of
> others, which makes finding the origin of the query hard to find
> (think Tor)

This type of intermediate routing makes Tor slow
<https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf>;.
Bitcoin does not and imho should not make anonymity guarantees. Many
users do not need them.

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 really the only thing I wanted to point out - if you do DHTs,
focus on performance, not anonymity. :)

Cheers,

Stefan

On 12/17/2011 2:37 PM, Christian Decker wrote:
> A while back I had proposed a similar idea to the DHT, although my
> main goal was to reduce the need for broadcasts.
>
> My idea was to structure the network in a hypercube and use prefixes
> to address different parts of the network, and use those prefixes also
> to find the location where an item (transaction, block, ...) should be
> stored. Each vertex in the hypercube is a small, highly connected,
> cluster of nodes. The storage would be distributed, messages are
> routed on behalf of others, which makes finding the origin of the
> query hard to find (think Tor), each node would have to store only
> O(log(p)) items, with p being the prefix length, maximum number of
> hops is equal to the dimension of the hypercube O(log(n)).
>
> Newly created transaction will be sent directly to the location
> they'll be stored and miners retrieve new transactions at regular
> intervals. It might increase delays to the confirmations, but it
> reduces the number of broadcasts and storage requirements on nodes
> greatly.
>
> Regards,
> Chris
>
>
> On Sat, Dec 17, 2011 at 2:13 PM, Michael Grønager
> <gronager at ceptacle.com <mailto:gronager at ceptacle.com>> wrote:
>
> Hey Eric,
>
> Two comments.
>
> 1.
> The ability to query for transactions belonging to pubkeys or
> bitcoin addresses is supported today by several implementations:
> * blockexplorer.com <http://blockexplorer.com>;
> * bitcoin-js
> * my own libBTC (will more on this soon)
>
> To query for transactions you need to use json-rpc and not the
> bitcoin protocol, however. But still the purpose is the same: to
> be able to build thin clients that can rely on a server for
> storing the blockchain and keeping connected on the p2p network.
>
> The reason for not having these queries part of the standard
> protocol (I think) are as they breaks anonymity, and that you
> would actually encourage people to participate in the p2p.
>
> 2. The second part you mention, to some how move the storage of
> the blockchain into a DHT based storage would be quite nice. The
> benefit of this is that it could be a way to integrate the smaller
> clients into the network without breaking the anonymity. But it
> should be thought out quite carefully. Further, if each client
> only store a fraction of the blockchain we should work out what
> fraction that need to be in order to ensure a similar service
> level. I would be happy to work with you on this.
>
> Cheers,
>
> Michael
>
> On 17/12/2011, at 08:41, Eric Lombrozo wrote:
>
> > Hey, guys.
> >
> > I haven't posted here before so I'll introduce myself. My name's
> Eric,
> > I've been developing cryptocurrency-related
> > software for several months now, I've implemented some libraries for
> > dealing with core bitcoin datastructures, made
> > some custom builds of bitcoind and interfaced it with a few apps
> I've written.
> >
> > In doing so, I've come to appreciate just how little of the
> potential
> > for the bitcoin protocol is being exploited right now...
> > not only in terms of the script features but in terms of the
> potential
> > commands and node types that could exist.
> >
> > For instance, the protocol spec at
> > https://en.bitcoin.it/wiki/Protocol_specification only has 16
> commands
> > listed and
> > only one service type...despite having a full 12 bytes for a command
> > code and a full eight bytes for a services
> > type.
> >
> > The fact that only one node service type is specified is
> probably due
> > to the fact that the satoshi client was written
> > to be a standalone monolithic app that took care of all the
> essential
> > needs for a network of peers.
> > i.e. block chain storage/management, transaction
> signing/verification,
> > key generation/wallet management, block mining, etc...
> > However, I think there's an urgent need for breaking up all these
> > different tasks into separate components that can run as independent
> > services on different types of devices.
> >
> > One of the big issues I'm dealing with now pertains to block chain
> > storage. As of right now, it is implemented as sequential
> > disk files using Berkeley DB in the satoshi client. Then you have
> > other projects that have been using SQL tables, etc...
> > But I believe the direction this really needs to move towards is
> some
> > sort of distributed hash table...and the database queries
> > should be performed using the bitcoin protocol itself. Perhaps
> adding
> > a few more commands. As things stand right now,
> > the only way to query for transactions or blocks is by their
> hash. And
> > once a transaction gets incorporated into a block and
> > removed from the transaction pool, one can no longer query it by the
> > transaction hash without stepping outside the bitcoin protocol.
> > We need access to the disk file that stores the blocks whether it be
> > via Berkeley DB or SQL or whatever.
> >
> > I propose an extension to the bitcoin protocol to provide
> methods for
> > performing more sophisticated queries, such as "Give me
> > an inventory of transactions involving this particular public
> key" or
> > "Give me an inventory all transactions in the last n blocks with
> > unredeemed outputs." This could be done by adding a few more
> commands.
> >
> > Furthermore, I propose a new network services type for nodes that
> > serve as block chain/transaction pool storage.
> >
> > Of couse, any peer that wishes to verify the integrity of the block
> > chain would still have to download at the very least
> > all the block headers...and to be completely sure, also all the
> blocks
> > themselves...and verify everything. But it would be
> > very nice to be able to run thin services that can rely on other
> > network peers to do this work. It is still possible to attain
> > a high level of confidence in the integrity by querying multiple
> peers
> > for similar objects and comparing. It is also possible
> > to run your own dedicated block chain storage servers which you
> trust.
> >
> > There are other ideas I have for other types of services, too.
> >
> > Anyhow, I'm just throwing this out there...if anyone's
> interested I'd
> > love to develop these ideas further and help put together some
> > specs.
> >
> > -Eric Lombrozo
> >
> >
> ------------------------------------------------------------------------------
> > 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
> <mailto:Bitcoin-development at lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> 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
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111218/2b6112bd/attachment.html>;