<unnamed>

Public Key

npub1f8c8h5evqyy29yp6p7jelyzw6vfwp6jz05exn66l4ygwkj57ytzqmap20e

Profile Code

nprofile1qqsynurm6vkqzz9zjqaqlfvljp8dxyhqafp86vnfad06jy8tf20z93qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dst6hmad

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 10:21:36 UTC

- reply

📅 Original date posted:2012-07-09
📝 Original message:> I think by "users" you mean, geeks who understand wiki syntax.
The point is to expand the circle of contributors. I'm pretty sure there
are more people who can edit a wiki than people who know HTML and how to
create a git pull request. :)
> Inability to agree on columns isn't why the page looks like that.
My apologies, I vaguely remembered Luke's original proposal and that it
got rejected, but you're correct, the reason wasn't a debate on the
columns but that people didn't like the feature matrix at all.
I didn't really mean to argue on the details of what the page should
look like, but just to briefly respond to Mike's point:
> It looks like that because feature matrices aren't especially helpful
> for newbies to make a decision, especially when the "features" in
> question were often things like how they handled the block chain or
> which protocol standards they support, ie, things only of interest to
> developers.
A well-designed feature matrix can quite useful and user-friendly.
http://www.apple.com/ipod/compare-ipod-models/
Prose is better to get a sense of the philosophy and basic idea of a
client. If it was between having only a feature matrix or only prose,
I'd probably go for the prose as well.
What a feature matrix is good at though is it allows you to very quickly
find the specific feature or general criteria you're looking for without
reading through all of the text. So it might be a useful addition maybe
not on Bitcoin.org, but certainly on the wiki.
On 7/10/2012 12:37 AM, Mike Hearn wrote:
>> 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]
> Probably because their listing is even more useless than any of the
> proposals that were presented here. Thank goodness it didn't end up
> like that. Their table doesn't even attempt to list features or
> differentiating aspects of each client.
>
> I think the XMPP guys have pretty much given up on directly marketing
> the system to end users.
>
>> - more up-to-date (anyone can update them)
> Fortunately reasonable clients don't appear/disappear/change that often.
>
>> - more in touch with users:
> I think by "users" you mean, geeks who understand wiki syntax. Because
> that's what it'll end up trending towards. I don't believe a wiki
> would reflect the needs of your average person. It's still better to
> have these arguments here and try to find a user-focussed consensus
> than hope one will converge from a wiki.
>
>> 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.
> Inability to agree on columns isn't why the page looks like that. I
> know because I'm the one who argued for the current design.
>
> It looks like that because feature matrices aren't especially helpful
> for newbies to make a decision, especially when the "features" in
> question were often things like how they handled the block chain or
> which protocol standards they support, ie, things only of interest to
> developers.
>
> It's much easier to communicate the differences to people with a short
> piece of text, and maybe if there is no obvious way to explain why
> you'd want to use a given client, that's a good sign it's not worth
> listing there. Otherwise you end up like xmpp.org.
>
>> 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.
> It's true that bitcoin.org needs to be conservative. That said, I'd
> like there to be sections for them too, actually. I agree that risk
> isn't purely about how it's implemented and that whilst we might like
> to push particular ideologies around protocols or code licensing, that
> isn't especially relevant to end users who have different priorities.
> Track record counts for a lot as well.
>

2023-06-07 10:21:29 UTC

- reply

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

2023-06-07 10:21:03 UTC

- reply

📅 Original date posted:2012-07-09
📝 Original message:> You are not a developer of any alternative clients
I am and I'm going to have to agree with Greg. Information about clients
is bound to be transient and controversial.
My relatively naive suggestion would be to move it to the Wiki. If it
can handle the controversies involved with the Trade page, it should
easily be able to handle the controversies involved with a Clients page
like this one. A link to that page could be added under Bitcoin Wiki on
Bitcoin.org.
On the subject of randomization, I think that's a bad idea. Randomness
does not equal fairness and more importantly it does not serve the
users, which should be the overriding concern. As a user I don't want to
be recommended a random client but the most sensible choice. As
alternative client implementors we should not be overly concerned about
Bitcoin.org recommending the wrong client, truly good clients will
benefit from word-of-mouth and eventually rise to the top. If you want a
"fair" ordering, then I'd order by number of downloads for downloadable
clients and Alexa rank for any hosted / online services if it were
decided that such should be listed at all.
On 7/9/2012 6:09 PM, Amir Taaki wrote:
> JS randomisation is bad. People shouldn't need JS to view a webpage.
>
> Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be first either when it dominates the front page. It is perfectly fine as it is.
>
> You are not a developer of any alternative clients, and this is a webpage for Bitcoin clients. I have made a change to remove a source of disputes, and make the process more fair and equal. Your suggestion to remove the clients page is your bias towards thinking that there should be only one Bitcoin client that everyone uses (the one which you contribute towards).
>
> If you want to suggest removing the clients page, then fine, lets also remove all reference to Bitcoin-Qt from the front-page and turn it into a http://bittorrent.org/ style website.
>
> Fact is that the other clients are rapidly becoming stable and mature, and the ecosystem is diversifying. The argument that the other clients were not up to scratch held maybe a few months ago, but not now.
>
>
>
> ----- Original Message -----
> From: Gregory Maxwell <gmaxwell at gmail.com>
> To: Amir Taaki <zgenjix at yahoo.com>
> Cc: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
> Sent: Monday, July 9, 2012 5:04 PM
> Subject: Re: [Bitcoin-development] Random order for clients page
>
> On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki <zgenjix at yahoo.com> wrote:
>> Took me a while, but finally got it working.
>> Entries on the clients page are randomly ordered when the page is generated.
>> https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
>> We should regenerate the page every 2 days. This gives fair exposure to all the clients listed.
> If you had authored this as a pull request rather than making the
> change unilaterally I would have recommended leaving it so the
> reference client was always first. I also would have suggested that it
> use JS randomization instead of jekyll in order to get more even
> coverage, though I think thats a more minor point.
>
> Some people were concerned when this page was created that it would
> just be a source of useless disputes. I think its becoming clear that
> this is the case. I think the cost of dealing with this page is
> starting to exceed the benefit it provides and we should probably
> consider removing it.
>
>
> ------------------------------------------------------------------------------
> 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
>

2023-06-07 10:14:11 UTC

- reply

📅 Original date posted:2012-06-15
📝 Original message:Thanks Mike for the writeup - I'm very sad to have missed the discussion
on IRC since fee economics are probably my favorite topic, but I'll try
to contribute to the email discussion instead.
> (4) Making the block size limit float is better than picking a new
> arbitrary threshold.
Fees are a product of both real and artificial limits to transaction
validation.
The artificial limits like the block size limit are essentially putting
a floor on prices by limiting supply beyond what it would otherwise be.
E.g. the network could confirm more transactions theoretically, but the
block size limit prevents it.
The real limits are the bandwidth, computing and memory resources of
participating nodes. For the sake of argument suppose a 1 TB block was
released into the network right now and we'll also assume there was no
block size limit of any kind. Many nodes would likely not be able to
successfully download this block in under 10-30 minutes, so there is a
very good chance that other miners will have generated two blocks before
this block makes its way to them.
What does this mean? The miner generating a 1 TB block knows this would
happen. So in terms of economic self interest he will generate the
largest possible block that he is still confident that other miners will
accept and process. A miner who receives a block will also consider
whether to build on it based on whether they think other miners will be
able to download it. In other words, if I receive a large block I may
decide not to mine on it, because I believe that the majority of mining
power will not mine on it - because it is either too large for them to
download or because their rules against large blocks reject it.
It's important to understand that in practice economic actors tend to
plan ahead. In other words, if there is no block size limit that doesn't
mean that there will be constant forks and total chaos. Rather, no miner
will ever want to have a block rejected due to size, there is plenty of
incentive to be conservative with your limits. Even if there are forks,
this simply means that miners have decided that they can make more money
by including more transactions at the cost of the occasional dud.
Therefore, from an economic perspective, we do not need a global block
size limit of any kind. As "guardians of the network" the only thing we
need to do is to let miners figure out what they wanna do.
HOWEVER, the existing economic incentives won't manifest unless somebody
translates them into code. We have to give our users (miners & endusers)
the tools to create a genuine fee-based verification market.
On the miner side: I would make the block size limit configurable with a
relatively high default. If the default is too low few people will
bother changing it, which means that it is not worth changing (because a
majority uses the default anyway), which means even fewer people will
change it and so on.
The block size limit should also be a soft rather than a hard limit -
here are some ideas for this:
- The default limit for accepting blocks from others should always be
significantly greater than the default limit for blocks that the client
itself will generate.
- There should be different size limits for side chains that are longer
than the currently active chain. In other words, I might reject a block
for being slightly too large, but if everyone else accepts it I should
eventually accept it too, and my client should also consider
automatically raising my size limit if this happens a lot.
The rationale for the soft limit is to allow for gradual upward
adjustment. It needs to be risky for individual miners to raise the size
of their blocks to new heights, but ideally there won't be one solid
wall for them to run into.
On the user side: I would display the fee on the Send Coins dialog and
allow users to choose a different fee per transaction. We also talked
about adding some UI feedback where the client tries to estimate how
long a transaction will take to confirm given a certain fee, based on
recent information about what it observed from the network. If the fee
can be changed on the Send Coins tab, then this could be a red, yellow,
green visual indication whether the fee is sufficient, adequate or
dangerously low.
A criticism one might raise is: "The block size limit is not to protect
miners, but to protect end users who may have less resources than miners
and can't download gigantic block chains." - That's a viewpoint that is
certainly valid. I believe that we will be able to do a lot just with
efficiency improvements, pruning, compression and whatnot. But when it
comes down to it, I'd prefer a large network with cheap
microtransactions even if that means that consumer hardware can't
operate as a standalone validating node anymore. Headers-only mode is
already a much-requested feature anyway and there are many ways of
improving the security of various header-only or lightweight protocols.
(I just saw Greg's message advocating the opposite viewpoint, I'll
respond to that as soon as I can.)
> (1) Change the mining code to group transactions together with their
> mempool dependencies and then calculate all fees as a group.
+1 Very good change. This would allow miners to maximize their revenue
and in doing so better represent the existing priorities that users
express through fees.
> There was discussion of some one-off changes to address the current
> situation, namely de-ranking transactions that re-use addresses.
Discouraging address reuse will not change the amount of transactions, I
think we all agree on that. As for whether it improves the
prioritization, I'm not sure. Use cases that we seek to discourage may
simply switch to random addresses and I don't agree in and of itself
this is a benefit (see item 4 below). Here are a few reasons one might
be against this proposal:
1) Certain use cases like green addresses will be forced to become more
complicated than they would otherwise need to be.
2) It will be harder to read information straight out of the block
chain, for example right now we can pretty easily see how much volume is
caused by Satoshi Dice, perhaps allowing us to make better decisions.
3) The address index that is used by block explorers and lightweight
client servers will grow unnecessarily (an address -> tx index will be
larger if the number of unique addresses increases given the same number
of txs), so for people like myself who work on that type of software
you're actually making our scalability equation slightly worse.
4) You're forcing people into privacy best practices which you think are
good, but others may not subscribe to. For example I have absolutely
zero interest in privacy, anyone who cares that I buy Bitcoins with my
salary and spend them on paragliding is welcome to know about it.
Frankly, if I cared about privacy I wouldn't be using Bitcoin. If other
people want to use mixing services and randomize their addresses and
communicate through Tor that's fine, but the client shouldn't force me
to do those things if I don't want to by "deprioritizing" my transactions.
5) We may not like firstbits, but the fact remains that for now they are
extremely popular, because they improve the user experience where we
failed to do so. If you deprioritize transactions to reused addresses
you'll for example deprioritize all/most of Girls Gone Bitcoin, which
(again, like it or not) is one of the few practical, sustainable niches
that Bitcoin has managed to carve out for itself so far.
> Having senders/buyers pay no fees is psychologically desirable even
> though we all understand that eventually, somebody, somewhere will be
> paying fees to use Bitcoin
Free is just an extreme form of cheap, so if we can make transactions
very cheap (through efficiency and very large blocks) then it will be
easier for charitable miners to include free transactions. In practice,
my prediction is that free transactions on the open network will simply
not be possible in the long run. Dirty hacks aside there is simply no
way of distinguishing a spam transaction from a charity-worthy
transaction. So the way I envision free transactions in the future is
that there may be miners in partnership with wallet providers like
BlockChain.info that let you submit feeless transactions straight to
them based on maybe a captcha or some ads. (For the purist, the captcha
challenge and response could be communicated across the bitcoin network,
but I think we agree that such things should ideally take place
out-of-band.)
That way, the available charity of miners who wish to include feeless
transactions would go to human users as opposed to the potentially
infinite demand of auto-generated feeless transactions.
On 6/15/2012 1:29 PM, Mike Hearn wrote:
> I had to hit the sack last night as it was 2am CET, but I'd like to
> sum up the discussion we had on IRC about scalability and SatoshiDice
> in particular.
>
> I think we all agreed on the following:
>
> - Having senders/buyers pay no fees is psychologically desirable even
> though we all understand that eventually, somebody, somewhere will be
> paying fees to use Bitcoin
>
> - In the ideal world Bitcoin would scale perfectly and there would be
> no need for there to be some "winners" and some "losers" when it comes
> to confirmation time.
>
> There was discussion of some one-off changes to address the current
> situation, namely de-ranking transactions that re-use addresses. Gavin
> and myself were not keen on this idea, primarily because it just
> avoids the real problem and Bitcoin already has a good way to
> prioritize transactions via the fees mechanism itself. The real issue
> is that SatoshiDice does indeed pay fees and generates a lot of
> transactions, pushing more traditional traffic out due to artificial
> throttles.
>
> The following set of proposals were discussed:
>
> (1) Change the mining code to group transactions together with their
> mempool dependencies and then calculate all fees as a group. A tx with
> a fee of 1 BTC that depends on 5 txns with zero fees would result in
> all 6 transactions being considered to have a fee of 1BTC and
> therefore become prioritized for inclusion. This allows a transition
> to "receiver pays" model for fees. There are many advantages. One is
> that it actually makes sense ... it's always the receiver who wants
> confirmations because it's the receiver that fears double spends.
> Senders never do. What's more, whilst Bitcoin is designed to operate
> on a zero-trust model in the real world trust often exists and it can
> be used to optimize by passing groups of transactions around with
> their dependencies, until that group passes a trust boundary and gets
> broadcast with a send-to-self tx to add fees. Another advantage is it
> simplifies usage for end users who primarily buy rather than sell,
> because it avoids the need to guess at fees, one of the most
> problematic parts of Bitcoins design now.
>
> The disadvantages are that it can result in extra transactions that
> exist only for adding fees, and it requires a more modern payment
> protocol than the direct-IP protocol Satoshi designed.
>
> It would help address the current situation by avoiding angry users
> who want to buy things, but don't know what fee to set and so their
> transactions get stuck.
>
> (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to
> avoid paying excessive fees and queue-jumping. Guess that's on my
> plate.
>
> (3) Scalability improvements seem like a no brainer to everyone, it's
> just a case of how complicated they are.
>
> (4) Making the block size limit float is better than picking a new
> arbitrary threshold.
>
> On the forums Matt stated that block chain pruning was a no-go because
> "it makes bitcoin more centralized". I think we've thrashed this one
> out sufficiently well by now that there should be a united opinion on
> it. There are technical ways to implement it such that there is no
> change of trust requirements. All the other issues (finding archival
> nodes, etc) can be again addressed with sufficient programming.
>
> For the case of huge blocks slowing down end user syncing and wasting
> their resources, SPV clients like MultiBit and Android Wallet already
> exist and will get better with time. If Jeff implements the bloom
> filtering p2p commands I'll make bitcoinj use them and that'll knock
> out excessive bandwidth usage and parse overheads from end users who
> are on these clients. At some point Bitcoin-Qt can have a dual mode,
> but who knows when that'll get implemented.
>
> Does that all sound reasonable?
>
> ------------------------------------------------------------------------------
> 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
>

2023-06-07 10:10:09 UTC

- reply

📅 Original date posted:2012-05-26
📝 Original message:Zooko is spot on - slower confirmations will give people a reason to set
higher fees. As soon as fees reach a level where they matter, even
botnet operators will be looking into ways of including transactions for
some extra profit.
In the meantime slightly slower confirmations aren't a problem. Consider
that even if it takes four blocks to get your transaction included
instead of one, once it is included, you still benefit from every new
block in terms of security. So if you're looking for six confirmations
for example, even a three block delay will only be a 50% delay for you.
And of course there are techniques for instant transactions which
continue to be refined and improved.
As for the proposed solutions: Punishing 1-tx blocks is complete and
utter nonsense. It's trivial to include a bogus second transaction.
Any additional challenges towards miners like hashes of the previous
block are at best useless. If I was running a botnet, I'd just grab that
hash from a website (pretty good chance Blockchain.info will have it :P)
or mining pool or wherever and keep going undeterred. At worst they may
affect scalability one day. You might imagine a peer-to-peer network of
miners who for cost reasons don't download all blocks anymore, but
verify only a percentage of them at random. They might then exchange
messages about invalid blocks including a proof (invalid tx, merkle
branch) why the block is invalid. This is just one idea, the point is
that assumptions about what a legitimate miner looks like may not always
hold in the future.
Finally, there is an ethical aspect as well. If a miner wishes not to
include my transaction that is his choice. He has no more an obligation
to sell his service to me than I have to buy it from him. If I really,
really want him to include my transaction I will have to offer to pay more.
If we as developers think that confirmations are too slow or that more
blocks should include transactions, then the right measures would be:
- Educating users about the relationship between confirmation speed and fees
- Raising the default transaction fee
Every market has a supply curve, so it is economically to be expected
that there will be some miners who don't include transactions, simply
because they are at that end of the supply curve where it is not worth
it for them to sell their service. All markets must have a certain
tension - there must be miners who don't include transactions for there
to be users who want their transactions included more quickly. In other
words there must be somebody not confirming if confirmations are to have
value. If you interfere with that all you'll accomplish is keep
transaction fees below market level, which will make the transition from
inflation-financed hashing to transaction-financed hashing more painful
and disruptive.
Cheers,
Stefan

2023-06-07 02:49:59 UTC

- reply

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

2023-06-07 02:26:46 UTC

- reply

📅 Original date posted:2011-09-15
🗒️ Summary of this message: Gavin Andresen proposes adding a -banscore option to ban nodes accumulating more than -banscore misbehavior points for -bantime seconds.
📝 Original message:A few thoughts:
Should the DoS protection auto-disable if the node has less than a
minimum number of connections? The idea being that if our node seems to
be kicking /everybody /off the roster maybe there is something wrong
with the protections.
It would be nice if the node sent a message to the banned peer with a
code indicating the reason for the ban, specifically the offense that
put Bitcoin over the edge. Logging the reason is probably fine for most
cases, but I wanted to put the idea out there, because it might make
debugging easier if there are some weird bans happening in the wild and
we can't figure out why.
Should sending lots of messages that don't pass the protocol-level
checksum test be a bannable offense? Or generally sending garbage data?
The attacks I'm thinking of are cross-protocol attacks. So as rough
example: The attacker puts an iframe on a website with a url like
http://victim.com:8333 so lots of people's browsers connect to it. Maybe
he could even use something like [magic-bytes]tx\0[...][valid orphan
transaction] in the URL, so the browser would send GET /[magic-bytes]
etc. and the Bitcoin node would interpret it.
kjj wrote:
> A few non-standard transactions are probably legitimate. A whole bunch
> of them are probably not. I would think that assigning a point or two
> of badness to a peer sending one is pretty reasonable, with the
> understanding that we would need to adjust that as the network evolves.
Strongly disagree. What is a non-standard transaction today may /be /a
standard transaction tomorrow.
On 9/15/2011 2:25 PM, Gavin Andresen wrote:
> Thanks Mike, that's exactly the kind of detailed review I was looking
> for. I think you're right an all points.
>
> I'll simplify: I'll add a -banscore option (default 100), and if a
> node accumulates more than -banscore misbehavior points it'll get
> dropped and banned for -bantime (default 60*60*24) seconds.
>
> I'll make bad signatures a banning offense, and I'll remove the
> number-of-sigops and non-standard-transaction penalties.
>
> I used a mutable field with const setter to avoid modifying a bunch of
> methods to take non-const blocks/transactions instead of const; I
> think it is appropriate because a block/transaction's DoS score is
> really meta-data and not part of it's state.
>
> I'll make GetTime() unit-test friendly as you suggest.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110915/d97d1e45/attachment.html>

2023-06-07 02:12:47 UTC

- reply

📅 Original date posted:2011-08-04
🗒️ Summary of this message: The creation of nodes/clusters accepting 10000+ incoming connections while making few outgoing connections could be an argument for double spend protection. The shortage of listeners may be due to the network consisting largely of end-users with residential type networks. In the long term, trends favor more clients allowing incoming connections. Policies to temp ban malicious nodes can be implemented.
📝 Original message:On 8/5/2011 12:18 AM, Gregory Maxwell wrote:
> Except for the fact that such a party is a DOS attack on the network
> which is already short on functioning listeners.
To the transaction radar it doesn't much matter whether its connections
are outgoing or incoming (assuming it can keep its nodes' IPs secret and
it has reasonable uptime). So you could say that this is an argument
*for* this kind of double spend protection if it means the creation of
nodes/clusters accepting 10000+ incoming connections while making few
outgoing connections. My point is, the amount of connections a node has
has nothing to do with its effect on the in/out balance.
Some words on the shortage of listeners itself:
Could this be because the network right now consists largely of end
users with residential type networks? With BitTorrent a lot of users go
through the trouble of opening up ports in their router manually in
order to get more peers and better download speeds - this is not (yet?)
a widespread practice with Bitcoin. (I know Bitcoin has UPnP support,
but I haven't found any numbers on how widely the IGD protocol is
actually deployed. Wikipedia says that "some NAT routers" support it and
that it's not an IETF standard. All routers I've actually seen in real
life had it disabled by default.)
In the long term all the trends favor more clients allowing incoming
connections: End users will tend to move towards lighter clients and the
ones that stick with full nodes will tend to configure them better -
meaning opening ports etc. - as documentation improves.
As for downright malicious nodes: It should be possible to come up with
some sensible policies to temp ban nodes that don't relay any useful
messages or try to flood you. This is an ongoing optimization problem in
any peer-to-peer network and I expect us to make progress with this over
time.
On 8/5/2011 12:16 AM, Matt Corallo wrote:
> This is exactly what I've been suggesting this whole time.
I had only seen you mention a "miner backbone" which is sort of a more
long-term vision, whereas Transaction Radar exists today. I didn't read
everything though, so if you mentioned this idea specifically, please
just consider my post as further support for your position.

2023-06-07 02:12:21 UTC

- reply

📅 Original date posted:2011-08-04
🗒️ Summary of this message: A pragmatic way to detect double spends is by connecting to multiple clients and checking if they all send the same transaction. A service like Transaction Radar can be used for this purpose. Network support for double spends may not be necessary and could be potentially damaging.
📝 Original message:Since nobody else has mentioned it: There is another (more pragmatic?)
way to detect double spends:
1. Connect to lots of clients
2a. If they all send you the same transaction -> double spend unlikely
2b. If some don't send you the transaction (or send a conflicting one)
-> double spend in progress
Obviously not everyone will run a double spend detector - it's much more
easily realized as a service (just like mining.) Jan put up a proof of
concept: http://www.transactionradar.com/
Would network support like a MSG_DOUBLESPEND be better? I used to think
yes, but looking at the reality of Transaction Radar, I'm not so sure.
Nothing stops such a service from scaling up and connecting to thousands
of random nodes (especially when the network itself grows bigger),
pushing the probabilities of missing a double spend "in the wild" to
near zero. It could also connect directly to important miners/pools as
others have suggested.
Of course this doesn't help against double spends where the attacker
does his own mining*, but neither would MSG_DOUBLESPEND. Given the added
network load I'd argue that network support for double spends is
unnecessary and potentially damaging. DoS is more scary to me than
non-instant transactions.
* In this case of course the hacker will be exposed to some randomness,
and I doubt many attackers will buy 100 televisions, newspaper
subscriptions or MP3s to get one for free. So this is only a problem for
liquid goods with tiny spreads (any investment or stored value instrument.)