Nostr notes by

📅 Original date posted:2012-07-15 📝 Original message:Hi, ...

2023-06-07T10:22:55Z

In reply to nevent1q…qpv0
_________________________

📅 Original date posted:2012-07-15
📝 Original message:Hi,

Can I remove the hackathon from bitcoin.org and put up the conference instead?

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

2023-06-07T10:21:23Z

In reply to nevent1q…0jw5
_________________________

📅 Original date posted:2012-07-09
📝 Original message:This page really does matter to alternative clients. If you measure the click through statistics, then they are a significant portion of the
traffic. By removing this page, you are directly stunting Bitcoin's
growth.

The only thing that's changed between now and this morning is:

- Addition of Bitcoin Wallet for Android
- Randomisation of entries

I actually got permission from everyone involved before making the page.If you want to remove the page, then we should see a vote by:

- laanwj
- gavin
- sipa
- jgarzik
- BlueMatt
- Diapolo
- luke-jr
- you
- jim from multibit
- gary rowe
- ThomasV
- me
- etotheipi
- Andreas Schildbach
- justmoon
- Mike Hearn
You're proposing to remove the page. You know, and I know and I know that you know that nobody visits the Wiki. Your proposal is not "move to Wiki" really but remove from bitcoin.org. Keep bitcoin.org for Bitcoin-Qt only which is against the stated goals of the rest of your team members (gavin, sipa, jgarzik).

Have you tried the new clients? I've tried all 4, and they are all well written.

Try the new version of Electrum, https://gitorious.org/electrum/electrum - it's more featureful and secure than Bitcoin-Qt what with deterministic wallets, brain-wallets, prioritising addresses, frozen addresses, offline transactions - none of which Bitcoin-Qt has.

MultiBit is also very good with QR integration and the ability for merchants to quickly set themselves up. It's full of guiding help text, and has this paradigm to allow people to work with keys.

Bitcoin Wallet for Android has one of the best bitcoin UIs I've seen and is extremely well thought out in how the user navigates through the software.

The Bitcoin network could function perfectly fine with Electrum nodes and
miners. You would still have miners and we wouldn't have the problem now with huge blocks because miners would be economically incentivised to
keep blocks small. But that's another discussion.

Technically speaking, the randomisation is fine now. It achieves its intended effect, as the page is regenerated daily.

This does not need to be a source of arguing. I see no problem with having this page be a neutral overview of the main clients (as we all agreed together in the beginning):
- Source must be public, and users must be able to run from source.
- Description should be non-spammy and neutral sounding. Cover the negative aspects.
Randomisation of the order simply makes that fairer. Alphabetical is not a good option (as others have suggested) because it can be gamed.

There is absolutely no reason to remove this page unless you think bitcoin.org is only for Bitcoin-Qt which is against the wishes of gavin, sipa, jgarzik, and the long-term stated goal of bitcoin.org as a neutral resource for the community.

----- 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 6:46 PM
Subject: Re: [Bitcoin-development] Random order for clients page

On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> JS randomisation is bad. People shouldn't need JS to view a webpage.

JS randomization doesn't imply needing JS to view the page. It implies
needing JS to see it in random order. You could also combine it with
the server-side randomization if you care about non-js being non
random, though I don't think it matters.

As others have pointed out I don't generally think the randomization
is good in principle, but if its done it should at least achieve its
goals.

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

I'll let other people speak for themselves, but I did consult others
before reverting your last batch of changes.

More generally, we have pull requests in order to get some peer review
of changes. Everyone should use them except for changes which are
urgent or trivially safe. (Presumably everyone with access knows how
to tell if their changes are likely to be risky or controversial)

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

I'm strongly supportive diversity in the Bitcoin network, and some alt
client developers can speak to the positive prodding I've given them
towards becoming more complete software. If I've said anything that
suggests otherwise I'd love to be pointed to it in order to clarify my
position.

Unfortunately none of the primary alternatives are yet complete, the
network would be non-function if it consisted entirely of multibit or
electrum nodes (and as you've noted armory uses a local reference
client as its 'server'). The distinction between multiple kinds of
clients in terms of security and network health are subtle and can be
difficult to explain even to technical users and so until something
changes there the reference client needs to be the option we lead
with. People should us it unless their use-case doesn't match. When it
does they'll know it and they'll be looking. We don't need to make one
of those recommendations a primary option.

I like the proposals of moving this stuff to the Wiki as the wiki
already contains tons of questionable (and sometimes contradictory)
advice and so there is less expectation that placement there implies
any vetting.

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

2023-06-07T10:21:00Z

In reply to nevent1q…xhza
_________________________

📅 Original date posted:2012-07-09
📝 Original message: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.

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

2023-06-07T10:20:54Z

In reply to nevent1q…0yc7
_________________________

📅 Original date posted:2012-07-09
📝 Original message: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.

📅 Original date posted:2012-06-16 📝 Original message:> ...

2023-06-07T10:15:42Z

In reply to nevent1q…vxy2
_________________________

📅 Original date posted:2012-06-16
📝 Original message:> I'm just afraid that the currently simple P2P protocol will turn into a
zoo of complicated (and potentially buggy/insecure) interactions.

This is my biggest fear too. I would rather be extremely conservative in making any changes to the protocol unless absolutely needed. That includes the bloom filters which take away the fact that Bitcoin is stateless.

I was discussing this with another developer who mentioned something interesting: that always in the lifecycle of system's development, you see increasing complexity during its initial lifecycle as the field is being explored. At some later point, the technology matures and becomes standardised. At that point enough is known that the system snaps together and the cruft can be cut away to reduce the system down to core principles.

It's an interesting viewpoint to consider. I do however advise erring on the side of caution. Maybe there needs to a minimum schedule time before a new extension can be added to the protocol (except security fixes). If we're not careful, the protocol will become enormously huge and kludgy. However maybe as that developer pointed out, trying to stall the inevitable is slowing the long-term evolution of Bitcoin down.

________________________________
From: Wladimir <laanwj at gmail.com>
To: Andy Parkins <andyparkins at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Saturday, June 16, 2012 10:42 AM
Subject: Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist

On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins <andyparkins at gmail.com> wrote:

>It's less of a problem in a (nearly) stateless protocol like Bitcoin.
>

It's currently (nearly) stateless, however it would be short-sighted to think it will stay that way. State is being introduced as we speak; for example, connection-specific filters.

I like the idea of a capabilities command; as time goes on and the ecosystem
>of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-
>blockchain/memory-pool-query clients becomes more varied, it's going to be
>more an more important. The particular example that occurs is thin clients
>connecting to the network are going to want to ensure they are connected to
>at least one non-thin client.
>

Which is a perfectly reasonable requirement. However, one could simply standardize what a 'thin client' and what a 'thick client' does and offers (at a certain version level), without having to explicitly enumerate everything over the protocol.

This also makes it easier to deprecate (lack of) certain features later on. You can simply drop support for protocol versions before a certain number (which has happened before). With the extension system this is much harder, which likely means you keep certain workarounds forever.

Letting the node know of each others capabilities at connection time helps somewhat. It'd allow refusing clients that do not implement a certain feature. Then again, to me it's unclear what this wins compared to incremental protocol versions with clear requirements.

I'm just afraid that the currently simple P2P protocol will turn into a zoo of complicated (and potentially buggy/insecure) interactions.

So maybe a capability system is a good idea but then the granularity should be large, not command-level. The interaction between protocol versions and capabilities needs to be defined as well. Does offering "getdata" at protocol version 10 mean the same as offering it at protocol version 11"? Probably not guaranteed. The arguments might have changed. So it's not entirely self-documenting either.

Wladimir

------------------------------------------------------------------------------
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:2012-06-15 📝 Original ...

2023-06-07T10:15:29Z

In reply to nevent1q…k90q
_________________________

📅 Original date posted:2012-06-15
📝 Original message:Introspection/command discovery is nice, but I would prefer it to be immediately done in the first version exchange so no assumptions as to how a network is operating need to be made.

I like the idea of a flat list of commands. It might make sense to have "meta"-commands that alias to groups of commands. i.e "original" for the current core subset up to (and including) "pong". The aliases could exist in a text definition file which is held on github or bitcoin.org/

----- Original Message -----
From: Jeff Garzik <jgarzik at exmulti.com>
To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Cc:
Sent: Saturday, June 16, 2012 2:13 AM
Subject: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist

Outside of major features advertised network-wide in nService bits,
P2P protocol lacks a good method of enumerating minor features or
extensions. The version number increment is coarse-grained, and is
not self-documenting. A simple extension which lists supported
commands is added, as demonstrated in this pull request:

https://github.com/bitcoin/bitcoin/pull/1471

Another option is for verack to return this information at login,
eliminating the need for a separate command/response.

--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

------------------------------------------------------------------------------
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:2012-06-15 📝 Original ...

2023-06-07T10:14:19Z

In reply to nevent1q…n7pz
_________________________

📅 Original date posted:2012-06-15
📝 Original message:Forcing users to switch addresses per received payment to work around a bad fee system would be a braindead decision. You might love software and playing with web plugins, but not everyone does. Artists like Rap News can right now simply throw up an address and begin accepting donations. That's a hugely powerful and impactful selling point for Bitcoin.

I don't really see these problems as a concern. Stefan made an excellent post which touched on this, in that miners have an incentive to keep block sizes low so that their blocks propagate. The real problem here is not about block propagation but the user experience. The way I see it, Bitcoin is becoming more specialised over time and part of that process is abstraction. In the past we all used the Satoshi client for mining, merchant functions, validating blocks and personal uses. These are rapidly diverging, and managing the blockchain is not something that user clients should be doing.

Mike is right when he says the network only needs a few thousand nodes to function fairly. I am not worried about Bitcoin becoming corrupted because of it being a network "by bankers for bankers" because unlike the conventional finance industry, there are no artificial barriers to entry beyond the base cost. This network would always be competitive and strictly operate based on market dynamics.

Case in point: http://en.wikipedia.org/wiki/Coase_theorem

With strict property rights and zero (or low) transaction costs, the allocation of a system does not matter. The system will make efficient use of its resources. I don't see why a cabal would try to corrupt Bitcoin at expense to themselves when a new competitor can enter the market and undercut them. It's why we expect the ROI on mining to be 0 or negative.

I figured out that if you trust data from a blockchain service and only accept data with multiple confirms from each connected service, then you can trivially calculate the probability of being fed corrupt data (assuming a fixed chance per server). In this way, the model is a fault tolerant byzantine system. The chance of being manipulated falls expontentially as you add more servers. And these services can be made highly scalable if you see my BIP 33.

https://en.bitcoin.it/wiki/BIP_0033

________________________________
From: Mike Koss <mike at coinlab.com>
To: Stefan Thomas <moon at justmoon.de>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Friday, June 15, 2012 7:37 PM
Subject: Re: [Bitcoin-development] Near-term scalability

Grouping mempool transactions based on fees of the group seems an unnecessary complexity; it makes it harder to predict if an isolated transaction has enough "juice" to be included in the next Block.

Given your point about economic actors adapting to conditions, would it not be simpler to use a individual "fee per byte" priority algorithm and let transaction generators distribute their fees accordingly (and more predictably)?

This simpler algorithm will prune arbitrary transactions sub-optimally, but has the benefit of being more understandable and predictable from the point of view of transaction generators.

On Fri, Jun 15, 2012 at 9:56 AM, Stefan Thomas <moon at justmoon.de> wrote:

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

--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)

A Bitcoin Primer - What you need to know about Bitcoins.

------------------------------------------------------------------------------
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:2012-05-02 📝 Original message:This ...

2023-06-07T10:06:41Z

In reply to nevent1q…tggt
_________________________

📅 Original date posted:2012-05-02
📝 Original message:This discussion about ordering is absolutely retarded. Once the list fills up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt first and the others ordered however. That was nobody can try to game the system (it remains unexploitable).

If there are no objections, then I am going to merge this branch. The forum thread is divulging into a mess all over the place, and this conversation can go on forever discussing the silly fine details:

http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem:
You suggest creating something new for your hackerspace, like a
bikeshed. But now all anyone will discuss is its colour. No bikeshed
will be built.

Armory & MultiBit, are you OK with that description? I will check with ThomasV about Electrum.

________________________________
From: Gary Rowe <g.rowe at froot.co.uk>
To: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Sent: Wednesday, May 2, 2012 8:34 PM
Subject: Re: [Bitcoin-development] new bitcoin.org clients page

How about keeping it simple?

Bitcoin-Qt
* Requires the entire blockchain
* Standalone client
* Designed for continuous operation
* Available for Windows, Mac, Linux with installer
* Developed in C
* Website: https://bitcoin.org

MultiBit
* Requires a reduced blockchain
* Standalone client
* Designed for occasional use
* Available for Windows, Mac, Linux with installer
* Developed in Java
* Website: http://multibit.org

Armory
* Requires the entire blockchain
* Dependent client of Bitcoin-Qt
* Designed for occasional use
* Available for Windows (64-bit only), Mac, Linux (self-build)
* Developed in Python
* Website: http://bitcoinarmory.com/

Electrum
* Requires no blockchain
* Dependent client of Bitcoin-Qt (on server)
* Designed for occasional use
* Available for Windows, Linux (self-build)
* Developed in Python
* Website: http://ecdsa.org/electrum/

Bitcoin Wallet (Android client)
* Requires a reduced blockchain
* Standalone client
* Designed for occasional use on mobile
* Available for Android only
* Developed in Java
* Website: https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en

On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:

This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in.
>
>On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send.
>
>Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again.
>
>
>
>
>----- Original Message -----
>From: Jeff Garzik <jgarzik at exmulti.com>
>To: grarpamp <grarpamp at gmail.com>
>Cc: bitcoin-development at lists.sourceforge.net
>Sent: Wednesday, May 2, 2012 7:29 PM
>Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
>
>On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
>>> Try "Reply to All"
>>
>> That puts the sender in 'to' and list in 'cc',
>> which dupes to the sender and eventually
>> blows out the to and cc lines as everyone
>> chimes in and doesn't trim. 'reply to' solves
>> most of that. assuming the list sw can do it.
>
>"Reply-To" Munging Considered Harmful
>http://www.unicom.com/pw/reply-to-harmful.html
>
>
>
>--
>Jeff Garzik
>exMULTI, Inc.
>jgarzik at exmulti.com
>
>------------------------------------------------------------------------------
>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
>
>
>------------------------------------------------------------------------------
>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
>

------------------------------------------------------------------------------
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:2012-05-02 📝 Original message:This ...

2023-06-07T10:06:24Z

In reply to nevent1q…eyvj
_________________________

📅 Original date posted:2012-05-02
📝 Original message:This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in.

On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send.

Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again.

----- Original Message -----
From: Jeff Garzik <jgarzik at exmulti.com>
To: grarpamp <grarpamp at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Wednesday, May 2, 2012 7:29 PM
Subject: Re: [Bitcoin-development] new bitcoin.org clients page

On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
>> Try "Reply to All"
>
> That puts the sender in 'to' and list in 'cc',
> which dupes to the sender and eventually
> blows out the to and cc lines as everyone
> chimes in and doesn't trim. 'reply to' solves
> most of that. assuming the list sw can do it.

"Reply-To" Munging Considered Harmful
http://www.unicom.com/pw/reply-to-harmful.html

--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

------------------------------------------------------------------------------
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:2012-04-12 📝 Original message:This ...

2023-06-07T10:03:32Z

In reply to nevent1q…vv9r
_________________________

📅 Original date posted:2012-04-12
📝 Original message:This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless protocols are more secure.

________________________________
From: Pieter Wuille <pieter.wuille at gmail.com>
To: Gavin Andresen <gavinandresen at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Thursday, April 12, 2012 5:01 PM
Subject: Re: [Bitcoin-development] Adding request/reply id in messages

On Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote:
> On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt <sirk390 at gmail.com> wrote:
> > I would like to discuss the following bitcoin protocol improvement proposal:
> >
> > Adding request/reply id in all messages (in the message header,
> > based on what was done for the "checksum" field)
>
> That seems like a perfectly reasonable protocol improvement to me.
> Anybody else have an opinion?

If there is a reasonable use for it, I have no objections.

However: the bitcoin P2P protocol is not fully request-reply based, and trying to use
it that may be be less intuitive than how it looks. For example, doing a second
identical "getblocks" request will not result in more "inv" replies, as the client
prevents retransmits. This is not a large problem, but maybe such an extension
should also include an extra "denied" message, which is sent if the client is
unwilling to answer (and may also be used to report transactions that are not
accepted into the memory pool, for example).

--
Pieter

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
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/20120412/b046c13c/attachment.html>;

📅 Original date posted:2012-02-24 📝 Original message:I ...

2023-06-07T03:09:09Z

In reply to nevent1q…vz3f
_________________________

📅 Original date posted:2012-02-24
📝 Original message:I followed the instructions from build-msw.txt and am getting the same issue from here:

https://bitcointalk.org/index.php?topic=45507.0

MSYS shell:

cd /c/db-4.8.30.NC-mgw/build_unix
sh ../dist/configure --enable-mingw --enable-cxx
make

$ make

./libtool --mode=compile gcc -c -I. -I../dist/.. -O3 ../dist/../mutex/mut_win32.c
libtool: compile: gcc -c -I. -I../dist/.. -O3 ../dist/../mutex/mut_win32.c -DDLL_EXPORT -DPIC -o .libs/mut_win32.o
In file included from ./db_int.h:886:0,
from ../dist/../mutex/mut_win32.c:12:
../dist/../dbinc/repmgr.h:502:13: error: two or more data types in declaration specifiers
../dist/../dbinc/repmgr.h:502:1: warning: useless type name in empty declaration
make: *** [mut_win32.lo] Error 1[/quote]

Any ideas? Sadly the proposed fix in that thread didn't work.

📅 Original date posted:2012-01-29 📝 Original message:Matt ...

2023-06-07T02:59:27Z

In reply to nevent1q…j4z4
_________________________

📅 Original date posted:2012-01-29
📝 Original message:Matt Corallo posted a modification of BIP 20 in an earlier email and I asked him if he wanted to become the champion of that BIP he submitted.

It is a modification of BIP 20 sans the alternative non-decimal number stuff.

https://en.bitcoin.it/wiki/BIP_0021

Right now, I will ask the GUI client implementations like MultiBit or Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they support BIP 20 or BIP 21. Feel free to raise any objections.

More weight will be given to GUIs with actual URI scheme implementations and it's good to have a general consensus.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120129/e0808f48/attachment.html>;

📅 Original date posted:2012-01-16 📝 Original message:Bunk ...

2023-06-07T02:56:11Z

In reply to nevent1q…2vkx
_________________________

📅 Original date posted:2012-01-16
📝 Original message:Bunk argument. This is an issue that affects bitcoin directly.

Wikipedia has far more need to remain neutral and apolitical than bitcoin ever does- you've read Satoshi's politically charged whitepaper or seen the genesis block quote.

http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action

The Wikipedia community decided on a full and global blackout. Bitcoin should do the same in unison with the rest of the web- sites like Reddit, 4chan and Wikipedia.

It's funny / almost comical how you consign this to being just another issue or case of moral alarm. Sad.

----- Original Message -----
From: Jeff Garzik <jgarzik at exmulti.com>
To: Amir Taaki <zgenjix at yahoo.com>
Cc: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Sent: Sunday, January 15, 2012 10:37 PM
Subject: Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout

On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> How is this not the most important world issue right now?
>
> EVERYTHING is under threat. Go nuclear to show our nerd-rage.
>
> Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy.

There are always issues that raise ire and moral outrage. I would
rather that bitcoin.org stay apolitical -- our users will appreciate
this in the long run.

--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

📅 Original date posted:2012-01-15 📝 Original message:How is ...

2023-06-07T02:55:52Z

In reply to nevent1q…y585
_________________________

📅 Original date posted:2012-01-15
📝 Original message:How is this not the most important world issue right now?

EVERYTHING is under threat. Go nuclear to show our nerd-rage.

Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy.

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

2023-06-07T02:54:10Z

In reply to nevent1q…fhu7
_________________________

📅 Original date posted:2011-12-31
🗒️ Summary of this message: The purpose of a certain field is unclear and unused, and its potential use for discovering IP addresses may lead to abuse. Its main reason for existing is unknown.
📝 Original message:Hi,

What is the purpose for this field? Can I safely ignore it? Currently it isn't used and I can't imagine it being too useful.

If you want to discover your own IP address from it, then that's ripe for abuse. Maybe it could be used in conjuction with your own IP lookup mechanism kind of how the clock works.

What is the main reason for this field existing?

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

2023-06-07T02:48:00Z

In reply to nevent1q…ylul
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Bitcoin protocol is functional but not elegant, with constantly changing endians and the need to lookup its own IP address. Namecoin has the same problem as DNS.
📝 Original message:You have to be seriously joking to call the bitcoin protocol elegant. A message based system over TCP with constantly changing endians that needs to lookup its own IP address on several websites is not elegant. It is functioning, not elegant.

Also it is kind of dick to come guns blaring and start insulting slush who runs one of the biggest mining pools and is working on electrum, and sipa who develops the satoshi bitcoin.

Khalahan said:

> Namecoin is a peer-to-peer generic name/value datastore system

Namecoin has the same problem as DNS. From the document:

"The disadvantage of DNS TXT records is that updating a record takes
time. This encourages people to not use new addresses per transaction
which has certain security issues."

________________________________
From: Rick Wesson <rick at support-intelligence.com>
To: Andy Parkins <andyparkins at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Friday, December 16, 2011 5:41 PM
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

Its a negative example -- in that the IETF does not specify anything
in the PATH part of the URI. The scheme, sure, but not in the path,
there are many types of URI schemes ( start with RFC 2396 )

There is significant upside to having your own scheme and having apps
understand how to integrate with it. Frankly, having just one client
(I understand there are more) is an artifact that hinders acceptance
and participation. If you want to go the route of https then
specifying a scheme is your path forward

I still believe that it is experience that is leading this thread down
the rat-hole of CGI and HTTP requests. The stuff isn't magic, it is
just what you are used to. Review the bitcoin protocol, there is an
elegance there -- not found in the https schemes proposed thus far.
CGI isn't a protocol, nor does it address usability/identity issues.

Providing a mapping from user at authority.tld addresses usability and
identity. I'd like to see an elegant transformation, specifically I
take to task anyone that advocates
https://authority/foo/user?tx=1zhd789632uilos as elegant.

-rick

On Fri, Dec 16, 2011 at 9:10 AM, Andy Parkins <andyparkins at gmail.com> wrote:
> On 2011 December 16 Friday, Rick Wesson wrote:
>> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush at centrum.cz> wrote:
>> > I really like this proposal with standard URLs. All other proposals like
>> > DNS mapping or email aliases converted to URLs with some weird logic
>> > looks strange to me.
>>
>> wow, really. Maybe you could review some RFCs, there are thousands of
>> examples where some really smart engineers chose the exact opposite
>> path which you propose below.
>
> Could you point me at an example?
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins at gmail.com

------------------------------------------------------------------------------
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/20111216/9780da73/attachment.html>;

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

2023-06-07T02:46:25Z

In reply to nevent1q…9y0r
_________________________

📅 Original date posted:2011-12-13
🗒️ Summary of this message: The proposal suggests using HTTPS for Bitcoin aliases, with the option for a server service, and clarifies the relevant line of code.
📝 Original message:Maybe I wasn't clear enough in the document, but this is the intent with the HTTPS proposal.

genjix at foo.org

Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system responds with a bitcoin address. Whether the system gives you a new address from a pool of addresses, or contacts the merchant behind the scenes is implementation defined.

I'll clarify it later. This is the relevant line:

string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + pszEncodedNick;

Between HTTPS service and server service, I lean slightly towards HTTPS (automatic encrypted connection, CAs + all benefits of DNS). But still interested in arguments in favour of a server service (daemon answering queries).

----- Original Message -----
From: Gavin Andresen <gavinandresen at gmail.com>
To: Jorge Timón <timon.elviejo at gmail.com>
Cc: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Sent: Tuesday, December 13, 2011 1:06 PM
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

I agree with Mike Hearn and Christian Decker-- paying to
'somebody at foo.com' should become, behind the scenes, a HTTPS query to
https://foo.com/something. If you just want to (say) donate to
eff.org, then paying to '@eff.org' aught to work nicely.

And if namecoin ever takes off you'll pay to 'somebody at foo.bit'.

It seems to me that if it was DNS-based, the address should be
something like 'somebody.bitcoin.foo.com'. But I think it is unlikely
people will setup and run a custom DNS server just to support bitcoin
payments.

--
--
Gavin Andresen

------------------------------------------------------------------------------
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and
improve service delivery. Take 5 minutes to use this Systems Optimization
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

2023-06-07T02:46:02Z

In reply to nevent1q…llwh
_________________________

📅 Original date posted:2011-12-13
🗒️ Summary of this message: FirstBits is not useless, but its resources rise exponentially as the number of participants in the network grows linearly, making it impractical. A shared naming scheme between Bitcoin implementations is proposed.
📝 Original message:lol, way to miss the point nanotube.

FirstBits *is* useless, but not for the reasons you specified. But simply because the resources it needs rises exponentially as the number of participants in the network grows linearly.

The point is that if FirstBits were built into the implementation, that would allow me to simply send to 1brmlab. The proposal here is not for a website where people can lookup bitcoin addresses, but a shared naming scheme between bitcoin implementations. Here's the story again:

> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had
on the wall a picture of their QR code and a bitcoin address. I don't
own a mobile phone so the QR code is
> useless. Then I remembered FirstBits, went to my terminal and typed
> 1brmlab. I got their bitcoin address from the website and copied that,
> then opened my terminal and pasted that in to send 1 BTC.

In our revised history, I simply send 1 BTC to brmlab

BOOM.

Club Mate

----- Original Message -----
From: Daniel F <nanotube at gmail.com>
To: Amir Taaki <zgenjix at yahoo.com>
Cc: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Sent: Tuesday, December 13, 2011 2:32 AM
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is
> useless. Then I remembered FirstBits, went to my terminal and typed
> 1brmlab. I got their bitcoin address from the website and copied that,
> then opened my terminal and pasted that in to send 1 BTC.

ok, imagine if firstbits didn't exist. instead of going to firstbits,
you would have gone to your terminal, opened up brmlabs website, and
copied the address from there?

there may be some arguments for name-> address translation, but i'm
sorry to say, that your example is not one of them. if anything, it
seems to suggest that firstbits is completely useless, since it saves
approximately zero effort.

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

2023-06-07T02:43:39Z

In reply to nevent1q…f8d3
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Professional summarizer skeptical of IBAN's usefulness in Bitcoin. Believes legacy banking systems are inefficient and built by finance people, not engineers. Supports easy-to-implement aliases.
📝 Original message:I think IBANs are not such a good idea. Note that as someone who has spent the last year of my life dealing with hundreds of bank transactions a day and interacting with the banking system (both on a technical, systematic and personnel level), the entire system is a gigantic mess.

The banks are in fact looking to us for answers. That's why we (Bitcoin Consultancy) were invited to the SWIFT conference to join their panel on bank 2.0.

I don't even mind the maxim "take everything the banks have done and do the complete opposite" :)

I invite anyone who is skeptical to read the ECB's specification on SEPA payments. It really is an example of a system made to work alongside legacy systems that rely on inefficient people. The interchange fees are dependent on a totally arbitrary test of merchant indifference and various antitrust regulations.

These systems are usually built not by engineers or hackers, but by finance people. IBAN has no place in bitcoin IMO.

I don't mean to sound too critical, but I'm skeptical of its usefulness. Especially when we already have bitcoin addresses with their own checksums- what value do IBANs add? Nothing except negatives.

________________________________
From: slush <slush at centrum.cz>
To: Khalahan <khal at dot-bit.org>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Friday, December 16, 2011 7:54 PM
Subject: Re: [Bitcoin-development] [BIP 15] Aliases

Khalahan, honestly, using namecoin for aliases is (for me) clean example of over-engineering. I mean - it will definitely work if implemented properly. I played with a namecoin a bit (as my pool was the first 'big' pool supporting merged mining), but I think there's really long way to provide such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't forget that people who want to do lookup need to maintain also namecoin blockchain with their bitcoin client. It goes against my instinct of keeping stuff easy.

For example, yesterday I implemented HTTPS lookup for addresses into my fork of Electrum client. I did it in 15 minutes, it works as expected, it does the job and the implementation is really transparent, becuase implementation is 20 lines of code. There's no magic transformation, no forced "?handle=" parameters or whatever. And I don't care if somebody provide URL https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True

And everybody can do the same in their clients, in their merchant solutions, websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS, Namecoin, IIBAN, email aliases to other programmers...

Those IIBAN - well, why not. At least I see the potential in PR. So far I understand it as some teoretic concept which is not supported by anything else right now. Give it few years until it matures and then add IIBAN alias to Bitcoin client too.

Maybe I'm repeating myself already, but the way to go is to make aliases as easy as possible, so everybody can implement it in their own solution and thus practially remove the need of using standard bitcoin addresses for normal users. Using some superior technology, which is hard to implement or even understand won't solve the situation, because it will ends up with some reference implementation in standard client only and nobody else will use it.

slush

On Fri, Dec 16, 2011 at 6:23 PM, Khalahan <khal at dot-bit.org> wrote:

>Namecoin is a peer-to-peer generic name/value datastore system.
>Don't forget it's not limited to .bit usage ! So, directly mapping
things to .bit url would not be the optimal way of using namecoin.
>
>
------------------------------------------------------------------------------
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/20111216/6566d3c1/attachment.html>;

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

2023-06-07T02:43:19Z

In reply to nevent1q…yrve
_________________________

📅 Original date posted:2011-12-15
🗒️ Summary of this message: Bitcoin developers discuss reusing code for IP transactions to enable dynamic address lookup and mitigate security flaws, with minimal protocol extension.
📝 Original message:This is maybe the best idea. I added it:
https://en.bitcoin.it/wiki/BIP_0015#IP_Transactions

Things I like about this:
- IP transactions are useful, but have a security flaw. This mitigates their security problems.
- The code for IP transactions is already in Satoshi client. If other clients want to add IP transactions, then it can be done with minimal fuss/bloat.
I feel that for any protocol extension, less is more. The less code
needed, the better the extension. Not always but generally we want to
avoid bitcoin protocol bloat which *will* happen far in the future. The
only way to mitigate how spaghettified the standard will be in the
future, is by careful cautious planning now.

- We can have a proxy node running 24/7 for us, serving our public keys in lieu of us.

________________________________
From: theymos <theymos at mm.st>
To: bitcoin-development at lists.sourceforge.net
Sent: Thursday, December 15, 2011 7:59 PM
Subject: Re: [Bitcoin-development] [BIP 15] Aliases

Bitcoin already has code and a protocol for transactions to IP
addresses. Why not reuse that for dynamic address lookup? Just a few
changes are necessary to enable complete user at server.com handling:
- Extend the protocol so that "reply" messages can be signed by a fixed
public key
- Extend "checkorder" messages so they can specify an account to
send BTC to. Or standardize on how to put the account into the
message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
also be used here to avoid having to use the IP transaction protocol
sometimes. The public key for signing "reply" messages can be gotten
from TXT records. This will be safe with DNSSEC and Namecoin. With
plain DNS Bitcoin could take a SSH-like approach and ask the user to
verify the public key the first time it is used, remembering it later.

DoS attacks are already handled by the IP transactions code: the same IP
address is always given the same bitcoin address until it pays to that
bitcoin address.

------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/
_______________________________________________
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/20111215/ea93e7ce/attachment.html>;

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

2023-06-07T02:43:03Z

In reply to nevent1q…aspz
_________________________

📅 Original date posted:2011-12-12
🗒️ Summary of this message: The author suggests using a web service as the best option for implementing aliases for Bitcoin addresses, followed by a server service and DNS TXT records. HTTPS + CA is the most secure option.
📝 Original message:OK, my thoughts. My order of preference is: web service, server service, DNS TXT records.

FirstBits + Vanitygen is out of the question in my mind. Not robust enough.

I like web service since anyone can trivially set one up. You can provide a PHP script and a text file (that users edit) that people upload to XFreeWebHost and then they're instantly set to go. Setting up a web host is very easy nowadays- as easy as click click click.

The other ideas are not so easy.

Also HTTPS + CA is the most secure of the bunch.

I'm curious to hear any other ideas too.

Thanks.

----- Original Message -----
From: Amir Taaki <zgenjix at yahoo.com>
To: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Cc:
Sent: Monday, December 12, 2011 10:21 PM
Subject: [BIP 15] Aliases

I wrote this pre-draft:

https://en.bitcoin.it/wiki/BIP_0015

It's merely a starter for discussions.

Aliases are a way to lookup bitcoin addresses so I can type genjix at genjix.net instead of 1jkddsjdskjwnk2j3kj232kjdkj

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

2023-06-07T02:43:00Z

In reply to nevent1q…9snr
_________________________

📅 Original date posted:2011-12-12
🗒️ Summary of this message: BIP 0015 proposes a way to use aliases to lookup Bitcoin addresses, making it easier to remember and type them. It's up for discussion.
📝 Original message:I wrote this pre-draft:

https://en.bitcoin.it/wiki/BIP_0015

It's merely a starter for discussions.

Aliases are a way to lookup bitcoin addresses so I can type genjix at genjix.net instead of 1jkddsjdskjwnk2j3kj232kjdkj

📅 Original date posted:2011-11-05 🗒️ Summary of this ...

2023-06-07T02:37:36Z

In reply to nevent1q…2zg9
_________________________

📅 Original date posted:2011-11-05
🗒️ Summary of this message: A debate on the use of user-agent strings in Bitcoin development, with some arguing it could lead to communication choices based on client type.
📝 Original message:On Saturday, November 05, 2011 12:17:58 PM Christian Decker wrote:
>> Sorry for shooting this approach down, but I'm against it. User-agent
>> strings are an extremely bad idea as it would lead developers to start
>> making communication choices depending on the client type.
> This can be necessary in some cases. What happens when some popular client is
> found with a subtle bug, and cannot otherwise be differentiated from other
> similar-functionality clients? I have found User-Agent very valuable when
> dealing with the wide variety of miner bugs when I have enabled new
> functionality/behaviour on Eligius.

I can agree with this point though. 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.

Fail hard and fast.

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. Lets say with libbitcoin- I'm sure that users of libbitcoin would like to have their client name in the string somehow. This was we can quickly understand which code-bases are being used and all the variants that exist build on those code-bases.

Together with system information (how many Linux users are there?) and various system settings (how many 32bit users are there), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111105/ba67e2f1/attachment.html>;

📅 Original date posted:2011-11-05 🗒️ Summary of this ...

2023-06-07T02:37:26Z

In reply to nevent1q…wf5e
_________________________

📅 Original date posted:2011-11-05
🗒️ Summary of this message: The proposal suggests modifying user-agent strings to create a hierarchy from protocol, variant, gui, flavour, and build for easier parsing.
📝 Original message:>From talking with Patrick Strateman (phantomcircuit), he suggested this idea (which I will elaborate more on in the BIP):

User-agent strings are a good starting point, however they aren't easy for parsing so we'll make a small modification to them.

We need a hierarchy from protocol, variant, gui, flavour, build

/Satoshi:314700/bitcoin-qt:0.4/

How does that sound? In BitcoinJ's case:

/BitcoinJ:0.2/AndroidBuild:0.8/

Thoughts:

- Do we need a freely defined comments field?

/BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/
/Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/

________________________________
From: Christian Decker <decker.christian at gmail.com>
To: Mike Hearn <mike at plan99.net>
Cc: Amir Taaki <zgenjix at yahoo.com>; "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Sent: Saturday, November 5, 2011 2:45 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers

On BitDroid I stopped updating the protocol version at 31700 and set the string to be both Version and Client, just like BitcoinJ :-)

On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn <mike at plan99.net> wrote:

BitCoinJ already sets the subver field to its name and version.
>
>
>------------------------------------------------------------------------------
>RSA(R) Conference 2012
>Save $700 by Nov 18
>Register now
>http://p.sf.net/sfu/rsa-sfdev2dev1
>_______________________________________________
>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/20111105/c39c56c9/attachment.html>;

📅 Original date posted:2011-11-02 🗒️ Summary of this ...

2023-06-07T02:37:14Z

In reply to nevent1q…utnc
_________________________

📅 Original date posted:2011-11-02
🗒️ Summary of this message: Bitcoin protocol identifier needs a unique name, and calling it Satoshi is a fitting tribute to the creator of the original client reference protocol.
📝 Original message:Bitcoin is the protocol. The client protocol identifier needs a unique name. It is not a public name that anybody ever sees except protocol developers.

For instance with libbitcoin, there might be several clients using it, but they'd all have the same protocol identifier.

I think calling it Satoshi is apt homage to the person who made the original client reference protocol.

Satoshi
BitcoinCommunityOriginal
...

Take your pick.

________________________________
From: Luke-Jr <luke at dashjr.org>
To: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Cc: Amir Taaki <zgenjix at yahoo.com>
Sent: Wednesday, November 2, 2011 10:46 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers

On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote:
> "Satoshi 0.5"

What is "Satoshi 0.5" anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt;
the wx GUI client is gone, which is more or less what "Satoshi" referred to in
the past...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111102/bf8785d4/attachment.html>;

📅 Original date posted:2011-11-02 🗒️ Summary of this ...

2023-06-07T02:37:07Z

In reply to nevent1q…gjju
_________________________

📅 Original date posted:2011-11-02
🗒️ Summary of this message: Discussion on locking protocol version numbers and using sub_version_num as a client and version identifier in Bitcoin development. BIP proposal suggested.
📝 Original message:Cool thread. I enjoyed reading that :) Thanks for sharing.

________________________________
From: Christian Decker <decker.christian at gmail.com>
To: Amir Taaki <zgenjix at yahoo.com>
Cc: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Sent: Wednesday, November 2, 2011 10:42 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers

Just for reference: https://github.com/bitcoin/bitcoin/pull/63
The issue resulted in my most useless pull request fixing two variables :-)

I second the use of sub_version_num as a Client and Version identifier.

Regards,
Chris

On Wed, Nov 2, 2011 at 11:33 PM, Amir Taaki <zgenjix at yahoo.com> wrote:

Point taken.
>
>
>About the sub_version_num though. I prefer to let the field by defined clients however they wish, with just a guideline suggestion that IDENTIFIER VERSION is a format they should follow.
>
>
>The idea being that different projects would have different release scheduling schemes and it'd be restrictive to lock people into the popular major.minor system.
>
>
>So for the current bitcoin to find out the version number of other clients (if it was needed), it would have to parse the number from the string:
>
>
>"Satoshi 0.5"
>
>
>Although there would be little reason for this with a sane protocol versioning scheme.
>
>
>If we're agreed then I'll start on that BIP.
>
>
>
>________________________________
>From: Gavin Andresen <gavinandresen at gmail.com>
>To: Amir Taaki <zgenjix at yahoo.com>
>Sent: Wednesday, November 2, 2011 9:34 PM
>Subject: Re: [Bitcoin-development] Lock protocol version numbers
>
>Good idea.
>
>Sounds perfect for a BIP....
>
>
>On Wed, Nov 2, 2011 at 5:23 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
>> Hey,
>> Can we lock the version numbers to be the protocol version (which changes
>> rarely) and instead use the sub_version_num field + revision number for
>> individual builds?
>
>--
>--
>Gavin Andresen
>
>
>
>------------------------------------------------------------------------------
>RSA(R) Conference 2012
>Save $700 by Nov 18
>Register now
>http://p.sf.net/sfu/rsa-sfdev2dev1
>_______________________________________________
>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/20111102/12e3637a/attachment.html>;

📅 Original date posted:2011-11-02 🗒️ Summary of this ...

2023-06-07T02:37:01Z

In reply to nevent1q…nsse
_________________________

📅 Original date posted:2011-11-02
🗒️ Summary of this message: The proposal is to let clients define the sub_version_num field as they wish, with a guideline suggestion to follow the IDENTIFIER VERSION format.
📝 Original message:Point taken.

About the sub_version_num though. I prefer to let the field by defined clients however they wish, with just a guideline suggestion that IDENTIFIER VERSION is a format they should follow.

The idea being that different projects would have different release scheduling schemes and it'd be restrictive to lock people into the popular major.minor system.

So for the current bitcoin to find out the version number of other clients (if it was needed), it would have to parse the number from the string:

"Satoshi 0.5"

Although there would be little reason for this with a sane protocol versioning scheme.

If we're agreed then I'll start on that BIP.

________________________________
From: Gavin Andresen <gavinandresen at gmail.com>
To: Amir Taaki <zgenjix at yahoo.com>
Sent: Wednesday, November 2, 2011 9:34 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers

Good idea.

Sounds perfect for a BIP....

On Wed, Nov 2, 2011 at 5:23 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> Hey,
> Can we lock the version numbers to be the protocol version (which changes
> rarely) and instead use the sub_version_num field + revision number for
> individual builds?

--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111102/92391645/attachment.html>;

📅 Original date posted:2011-11-02 🗒️ Summary of this ...

2023-06-07T02:36:48Z

In reply to nevent1q…mqe4
_________________________

📅 Original date posted:2011-11-02
🗒️ Summary of this message: Satoshi proposes locking version numbers to protocol version and using sub_version_num field + revision number for individual builds to avoid version bumping.
📝 Original message:Hey,

Can we lock the version numbers to be the protocol version (which changes rarely) and instead use the sub_version_num field + revision number for individual builds?

Satoshi 0.4
BitcoinJava 120311
bitcoin-js 6

Like so. Otherwise we will have version bumping insanity :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111102/bf315b92/attachment.html>;