Amir Taaki [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-07-17 to 2021-04-28
💬 Posted a total of 110 messages
📚 Participated in the following categories: Bitcoin-development, RFC, BIP 15, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1ep4j5tjp6cd2774hrx96vh845dwqzhe3z7n3a2a9uxdm2dajqpgscm3rel

Profile Code

nprofile1qqsvs6e29eqavx4002m3nzaxtn66xhqptuc30fc74wj7rxa4x7eqq5g554n7m

Author Public Key

npub1ep4j5tjp6cd2774hrx96vh845dwqzhe3z7n3a2a9uxdm2dajqpgscm3rel

Show more details

Last Notes

2023-06-07 10:28:56

- reply

📅 Original date posted:2012-08-16
📝 Original message:MSG_MEMTX solves the issue of not knowing whether a given inv is in response to a "mempool" command or not.
I don't buy the argument that always sending a response "inv" makes things easier because code should always be able to handle misbehaviour from the remote node (ommiting the "inv"). However I would argue that it is good to have it, as it makes designing flows of logic much easier (first send this, wait for response, do this, ...).
----- Original Message -----
From: Stefan Thomas <moon at justmoon.de>
To: bitcoin-development at lists.sourceforge.net
Cc:
Sent: Thursday, August 16, 2012 8:21 PM
Subject: Re: [Bitcoin-development] BIP 35: add mempool message
> This seems safe, although it forces other full implementations that want to
> expose protocol version 60002 (or later) to also implement this. What do they
> think about this?
BitcoinJS will implement it, it's a useful feature and there is no
reason not to support it.
Two comments from my end:
- This is just a thought, but I wouldn't mind using a new inv_type for
this, e.g. MSG_MEMTX. I could conceivably see a future where broadcast
and relay txs are stored in a very fast local cache whereas the general
mempool is stored in a slower data structure. By being able to
distinguish incoming getdata requests I can save a few milliseconds by
querying the right storage right away. Might also help with things like
telling apart broadcast/relayed transactions from the response to a
mempool request for purposes like DoS scoring etc.
Not a big deal by any means, but I also don't see a downside to it.
inv_types are not a scarce resource, we have four billion of them available.
For now clients would just treat MSG_TX and MSG_MEMTX interchangeably.
- If a node doesn't have anything in it's mempool it sends back an empty
inv message. This is either ambiguous (if other things also send empty
inv messages in the future) or arbitrary (why should an empty inv be
associated with a mempool request of all things.) Instead why not
respond with an inv message that contains a single element of type
MSG_MEMTX and hash 0. That would a very direct way to indicate that this
response is associated with a mempool request.
I'm not married to either suggestion, just trying to add my perspective.
One thing you notice when reimplementing Bitcoin is that Bitcoin's
protocol leaves out a lot of information not for space reasons, but
because the reference client's implementation doesn't happen to need it.
Sometimes however this locks other clients into doing things the same
way. If we can make the protocol a bit richer, especially if this
doesn't cost any extra bytes, then we should consider it as it might
help some implementation down the road make a neat optimization.
On 8/16/2012 7:56 PM, Pieter Wuille wrote:
> On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote:
>> Consensus was we should do a BIP for all P2P changes, so here it is...
>> feedback requested.
>>
>> https://en.bitcoin.it/wiki/BIP_0035
> I like the idea of being able to query the memory pool of a node; the
> implementation is straightforward, which is good. Maybe effectively using the
> command can be added? I suppose it is interesting in general for nodes to
> get a memory pool refill at startup anyway.
>
>> 1) Upon receipt of a "mempool" message, the node will respond
>> with an "inv" message containing MSG_TX hashes of all the
>> transactions in the node's transaction memory pool.
>>
>> An "inv" message is always returned, even if empty.
> I'm not sure about this last. What is it good for? inv packets can always be
> sent, even not in response to others, so it is not that this gives you an
> acknowledgement the mempool is updated?
>
>> 3) Feature discovery is enabled by checking two "version" message attributes:
>>
>> a) Protocol version >= 60002
>> b) NODE_NETWORK bit set in nServices
> This seems safe, although it forces other full implementations that want to
> expose protocol version 60002 (or later) to also implement this. What do they
> think about this?
>
> I would like to suggest to allocate an extra service bit for this. We still
> have 63 left, and this is a well-defined and useful extra service that was
> not yet provided by any earlier node. Doing that would also mean that
> mempool-providing survices may be discovered before connecting to them, as
> the service bits are carried around in addr messages. Any opinions about that?
>
------------------------------------------------------------------------------
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:28:49

- reply

📅 Original date posted:2012-08-16
📝 Original message:My thoughts:
The extension is simple. It's only really useful for the use-cases listed if the majority of nodes implement it. As I view the proposal, it is perfectly simple and uncomplicated. If it's implemented, then I suggest to just increment version and make it part of the protocol.
On the flipside it is another notch in complicating an already diffuse protocol, but it seems a rather benign offense in that regard compared to other changes (past and future).
----- Original Message -----
From: Pieter Wuille <pieter.wuille at gmail.com>
To: Jeff Garzik <jgarzik at exmulti.com>
Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Sent: Thursday, August 16, 2012 6:56 PM
Subject: Re: [Bitcoin-development] BIP 35: add mempool message
On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote:
> Consensus was we should do a BIP for all P2P changes, so here it is...
> feedback requested.
>
> https://en.bitcoin.it/wiki/BIP_0035
I like the idea of being able to query the memory pool of a node; the
implementation is straightforward, which is good. Maybe effectively using the
command can be added? I suppose it is interesting in general for nodes to
get a memory pool refill at startup anyway.
> 1) Upon receipt of a "mempool" message, the node will respond
> with an "inv" message containing MSG_TX hashes of all the
> transactions in the node's transaction memory pool.
>
> An "inv" message is always returned, even if empty.
I'm not sure about this last. What is it good for? inv packets can always be
sent, even not in response to others, so it is not that this gives you an
acknowledgement the mempool is updated?
> 3) Feature discovery is enabled by checking two "version" message attributes:
>
> a) Protocol version >= 60002
> b) NODE_NETWORK bit set in nServices
This seems safe, although it forces other full implementations that want to
expose protocol version 60002 (or later) to also implement this. What do they
think about this?
I would like to suggest to allocate an extra service bit for this. We still
have 63 left, and this is a well-defined and useful extra service that was
not yet provided by any earlier node. Doing that would also mean that
mempool-providing survices may be discovered before connecting to them, as
the service bits are carried around in addr messages. Any opinions about that?
--
Pieter
------------------------------------------------------------------------------
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:26:44

- reply

📅 Original date posted:2012-07-29
📝 Original message:oh, bitcoin...
Thanks justmoon :D
----- Original Message -----
From: Stefan Thomas <moon at justmoon.de>
To: bitcoin-development at lists.sourceforge.net
Cc:
Sent: Sunday, July 29, 2012 1:33 PM
Subject: Re: [Bitcoin-development] script tests - invalid script in script_valid.json?
OP_WITHIN is lower-bound-inclusive, but upper bound exclusive, so 1 0 1 WITHIN is false.
bool fValue = (bn2 <= bn1 && bn1 < bn3);
https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L854
On 7/29/2012 6:31 PM, Amir Taaki wrote:
> Hi!
>
> Is this a valid script?
>
> ["1 0 1", "WITHIN NOT"]
>
> The first value (1) is tested to make sure it is between the lower (0) and upper (1) value. This evaluates to true, placing on the stack a single byte of [01]. NOT then inverses this to a 0 byte false value of [].
>
> What am I missing here?
>
> Thanks
>
> ------------------------------------------------------------------------------
> 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

2023-06-07 10:26:37

- reply

📅 Original date posted:2012-07-29
📝 Original message:Hi!
Is this a valid script?
["1 0 1", "WITHIN NOT"]
The first value (1) is tested to make sure it is between the lower (0) and upper (1) value. This evaluates to true, placing on the stack a single byte of [01]. NOT then inverses this to a 0 byte false value of [].
What am I missing here?
Thanks

2023-06-07 10:23:08

- reply

📅 Original date posted:2012-07-17
📝 Original message:OK, pull request seems good.
FYI we lost money on last year's conference, and are hoping to break even this year. The only people to make profit will be nefario and anyone else we give a share in it (people who help realise it). Otherwise money made goes towards next year's conference and paying for things to make a better conference (like Gavin wanted to attend but couldn't afford a ticket). It is not a commercial event, and I've been pushing to keep the sponsorship and community parts highly separated. Like I really do not wish to sell a speaker slot, but if I have to (to pay the bills) then it will be obvious due to scheduling and disclaimers that speakers are sponsors.
----- Original Message -----
From: Luke-Jr <luke at dashjr.org>
To: bitcoin-development at lists.sourceforge.net
Cc: Jeff Garzik <jgarzik at exmulti.com>; Amir Taaki <zgenjix at yahoo.com>
Sent: Tuesday, July 17, 2012 2:09 AM
Subject: Re: [Bitcoin-development] bitcoin.org - remove hackathon
On Monday, July 16, 2012 11:47:02 PM Jeff Garzik wrote:
> Vladimir does raise a fair point, though. Hackathon seems appropriate
> for bitcoin.org as it is focused on dev-related activities. (full
> disclosure: speaking at bitcoin2012.com) The conference might or
> might not be. The conference does seem community focused, so I don't
> object to it being on bitcoin.org... But if consensus prefers
> otherwise, that's OK too.
IMO, bitcoin.org is more community-focussed anyway.
How often do devs use the site, compared to GitHub etc?
Someone else made a pullreq for Bitcoin Magazine; I suggest(ed) that
for-profit organizations should be asked to pitch in some way or another.
Who should organize that, I don't know. If Bitcoin Consultancy/Amir is behind
the conference, I suggest their/his development contributions should be
sufficient in that respect.
> PS. This seems like material for pull requests, which is preferred
> over mailing list email + git push. When working on the satoshi
> client, we all ACK each other's pull req for anything beyond the
> trivial.
I concur, this should be discussed in a pullreq.

2023-06-07 10:22:55

- reply

📅 Original date posted:2012-07-15
📝 Original message:Hi,
Can I remove the hackathon from bitcoin.org and put up the conference instead?

2023-06-07 10:22:05

- reply

📅 Original date posted:2012-07-09
📝 Original message:By that time in the future, when there are many clients, there should just be a flat list or no list at all.
----- Original Message -----
From: Nils Schneider <nils at nilsschneider.net>
To: bitcoin-development at lists.sourceforge.net
Cc:
Sent: Monday, July 9, 2012 6:33 PM
Subject: Re: [Bitcoin-development] Random order for clients page
I don't think that's a good idea as it can easily confuse or annoy users
when things move around. The ordering should be preserved as much as
possible so users can remember where they found a client they liked
(e.g. 2nd row, 1st column and screenshot with light and blue colors).
Making them search the entire page is inefficient and will just get
worse once there are many clients on the page (and I think that's the goal).
On 09.07.2012 17:54, Amir Taaki 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.
>
>
> ------------------------------------------------------------------------------
> 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

2023-06-07 10:21:00

- reply

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

2023-06-07 10:20:00

- reply

📅 Original date posted:2012-07-06
📝 Original message:It would be nice if Bitcoin was engineered this way from the start. The amount of workarounds, special cases and code bloat to deal with the fact that txs are non-unique was a massive headache for me.
________________________________
From: Mark Friedenbach <mark at monetize.io>
To: Jeff Garzik <jgarzik at exmulti.com>
Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Sent: Friday, July 6, 2012 6:56 PM
Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes <peter at coinlab.com> wrote:
>> The proposal is simple, and it's a small change for miners, I imagine.
>>
>> My question is: why?
>>
>> I worry about stuffing too many requirements on the coinbase. I suppose
>> the coinbase is easily extendible if we run out of bytes, but I think I'd
>> like to see some more discussion / good / bad type cases for making this
>> change. What do we get over just the prev_hash by doing this?
>
>With the existing setup (sans height in coinbase), you might not have
>unique transactions, with all that entails.
>
But those issues are solvable through other, non-backwards incompatible means. For example, mandate that a <transaction hash, output index> refers to the first such pair that is not already spent. No?
Mark
------------------------------------------------------------------------------
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:18:39

- reply

📅 Original date posted:2012-06-21
📝 Original message:This is happening in Berlin if anyone is around: http://bitcoin-hackathon.com/
I am happy to host if space is needed.

2023-06-07 10:15:51

- reply

📅 Original date posted:2012-06-17
📝 Original message:As the only person to have created and maintaining a full reimplementation of the Bitcoin protocol/standard, I do think Bitcoin is filled with arbitrary endianness and magic numbers. However it is a tiny and simple protocol.
The big problem is not implementing the Bitcoin protocol, but the fact that once you have created a codebase, you want to perfect and fine-tune the design. During the meantime, the Bitcoin protocol is being changed. Change to the Bitcoin protocol is far more damaging to people that want to implement the protocol than any issues with the current protocol.
That's not to say, I disagree with changes to the protocol. I think changes should be a lot more conservative and have a longer time frame than they do currently. Usually changes suddenly get added to the Satoshi client and I notice them in the commit log or announcements. Then it's like "oh I have to add this" and I spend a week working to implement the change without proper consideration or reflection which ends up with me having to compromise on design choices. That is to remain compatible with the protocol.
However it is not my intent to slow down progress so I usually try to hedge against that kind of feeling towards conservatism.
----- Original Message -----
From: Jeff Garzik <jgarzik at exmulti.com>
To: Wladimir <laanwj at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Sunday, June 17, 2012 5:19 PM
Subject: Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
On Sat, Jun 16, 2012 at 4:42 AM, Wladimir <laanwj at gmail.com> wrote:
> 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.
What is missing here is some perspective on the current situation. It
is -very- easy to make a protocol change and bump PROTOCOL_VERSION in
the Satoshi client.
But for anyone maintaining a non-Satoshi codebase, the P2P protocol is
already filled with all sorts of magic numbers, arbitrarily versioned
binary data structures.. already an unfriendly zoo of complicated and
potentially buggy interactions. There is scant, incomplete
documentation on the wiki -- the Satoshi source code is really the
only true reference.
I see these problems personally, trying to keep ArtForz' half-a-node
running on mainnet (distributed as 'blkmond' with pushpool).
In an era of HTTP and JSON, NFS and iSCSI, bitcoin's P2P protocol is
woefully backwards, fragile, limited and inflexible when it comes to
parameter/extension exchange and negotiation. Even iSCSI, that which
is implemented on hard drive firmware, has the ability to exchange
key=value parameters between local and remote sides of the RPC
connection.
Calling the current P2P protocol "simple" belies all the
implementation details you absolutely -must- get right, to run on
mainnet today. Satoshi client devs almost never see the fragility and
complexity inherent in the current legacy codebase, built up over
time.
--
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

2023-06-07 10:15:42

- reply

📅 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

2023-06-07 10:15:00

- reply

📅 Original date posted:2012-06-16
📝 Original message:Did anyone try sending them an email asking them to stop or offering help to fix their site? What did they say? I'm sure they would try to be accomodating.
----- Original Message -----
From: Jonathan Warren <jonathan at bitcoinstats.org>
To: bitcoin-development at lists.sourceforge.net
Cc:
Sent: Saturday, June 16, 2012 4:35 AM
Subject: Re: [Bitcoin-development] SatoshiDice and Near-term scalability
Yes, I measure mainnet confirmation times on a regular basis.
http://bitcoinstats.org/post/tx-confirmation-times-June2012.png
Before fairly recently, fee-paying transactions never took anywhere close to
this long to be confirmed.
Jonathan Warren
(Bitcointalk: Atheros)
-----Original Message-----
From: Jeff Garzik [mailto:jgarzik at exmulti.com]
Sent: Friday, June 15, 2012 1:17 PM
To: bitcoin-development at lists.sourceforge.net
Subject: [Bitcoin-development] SatoshiDice and Near-term scalability
Hard-fork requires a very high level of community buy-in, because it shuts
out older clients who will simply refuse to consider >1MB blocks valid.
Anything approaching that level of change would need some good, hard data
indicating that SatoshiDice was shutting out the majority of other traffic.
Does anyone measure mainnet "normal tx" confirmation times on a regular
basis? Any other hard data?
------------------------------------------------------------------------------
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:19

- reply

📅 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

2023-06-07 10:13:08

- reply

📅 Original date posted:2012-06-15
📝 Original message:Why though? The bottleneck is not network traffic but disk space usage/blockchain validation time.
----- Original Message -----
From: Mike Hearn <mike at plan99.net>
To: Jeff Garzik <jgarzik at exmulti.com>
Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Sent: Friday, June 15, 2012 3:43 PM
Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
> Yes, the format is something that must be hashed out (no pun
> intended). Need input from potential users about what information
> they might need.
Matts point that a branch-per-transaction may duplicate data is well
made, that said, I suspect a format that tries to fix this would be
much more complicated.
How about see this project as a three part change?
First step - add the mempool command and make nodes sync up their
mempools on startup.
Second step - if protocol version >= X, the "block" message consists
of a header + num transactions + vector<hash> instead of the full
transactions themselves.
On receiving such a block, we go look to see which transactions we're
missing from the mempool and request them with getdata. Each time we
receive a tx message we check to see if it was one we were missing
from a block. Once all transactions in the block message are in
memory, we go ahead and assemble the block, then verify as per normal.
This should speed up block propagation. Miners have an incentive to
upgrade because it should reduce wasted work.
Third step - new message, getmerkletx takes a vector<hash> and returns
a merkletx message: "merkle branch missing the root + transaction data
itself" for each requested transaction. The filtering commands are
added, so the block message now only lists transaction hashes that
match the filter which can then be requested with getmerkletx.
------------------------------------------------------------------------------
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:08:43

- reply

📅 Original date posted:2012-05-16
📝 Original message:A bloom filter seems like an interesting idea. However this proposal is concerned mainly with the initialisation stage, whereas this bloom filter is for pushed blocks.
This proposal still updates new transactions and blocks in the same way, and it's not inconceivable to later use a bloom filter to make that part more efficient (although it's questionable if pushing this server side would be a good idea as it would now need to track an additional client state).
________________________________
From: Mike Hearn <mike at plan99.net>
To: Amir Taaki <zgenjix at yahoo.com>
Cc: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Sent: Wednesday, May 16, 2012 5:46 PM
Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes
Thanks for getting this started.
With regards to the specific proposal, I don't believe it's the best option and still plan to eventually implement the original design outlined more than a year ago in this thread:
https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
Namely that you use a new protocol command to set a Bloom filter on a connection. Only transactions matching that filter will appear in relayed inventory. Blocks that are requested will arrive as a header plus transaction/merkle branch pairs. Clients are expected to maintain and track the block chain as per usual, but instead of downloading the whole chain and then dropping the irrelevant transactions, that filtering is done server side. By strengthening or weakening the Bloom filters you can choose your preferred point on the privacy/bandwidth-usage spectrum. It is a fairly simple change to the Satoshi and BitcoinJ codebases but still allows clients to gain confidence in their balance by examining the chain, and this is true even in the presence of a hijacked internet connection (you can't trust pending transactions that way, but you can still trust confirmed transactions).
The filters would be applied to each data block in each script rather than having a specific knowledge of addresses. In this way you can select for things like multisig outputs or outputs which don't use addresses / pubkeys to authenticate.
I could write a BIP for this alternative protocol if somebody else wants to implement it. I was going to wait until I had time to do both BIP and implementation, but I think some simple optimizations to BitcoinJ can keep its performance good enough for the short term.

2023-06-07 10:08:37

- reply

📅 Original date posted:2012-05-16
📝 Original message:Hi,
Please check out my proposal,
https://en.bitcoin.it/wiki/BIP_0033
I want to use the existing Bitcoin protocol to provide this functionality in order to maintain compatibility. This proposal does not affect current Bitcoin clients, but allows the parallel system to operate alongside and sometimes intersect with the main Bitcoin network in a positive way.

2023-06-07 10:06:41

- reply

📅 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

2023-06-07 10:06:24

- reply

📅 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

2023-06-07 10:05:31

- reply

📅 Original date posted:2012-04-30
📝 Original message:This is optimisation where it isn't needed. Bandwidth is not the bottleneck of the Bitcoin system. It is the immense time needed to validate the blockchain.
And clients should never send blocks first. They always send an inv packet, then you request the block. It is a disruptive change and brings little.
We don't need to optimise every aspect of Bitcoin :) Just focus on the big bits that matter, while keeping everything working with minimal changes.
For instance say we did this and to maintain backwards compatible, we introduced a new message called "hash+block". Now there are 2 code branches that must be maintained - urgh.
________________________________
From: Wladimir <laanwj at gmail.com>
To: Rebroad (sourceforge) <rebroad+sourceforge.net at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Monday, April 30, 2012 7:26 PM
Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge) <rebroad+sourceforge.net at gmail.com> wrote:
>My proposal is that in addition to the size (which is advertised in
>the header), the hash is also advertised in the header (of a block).
>This would help nodes to determine whether they wanted to reject the
>download. (e.g. if it already had a block matching that hash). This of
>course wouldn't prevent a rogue node from sending an incorrect hash,
>but this would aid in saving bandwidth amongst behaving nodes.
>
I suppose it would make sense for clients to be able to reject blocks that they already have, if that's not currently possible.
The other part of the proposal is to allow nodes to request upload and
>download blocks that have already been partially downloaded.
>
>This could be done by modifying the existing methods of upload,
>download, or by adding a new method, perhaps even using HTTP/HTTPS or
>something similar. This would also help nodes to obtain the blockchain
>who have restrictive ISPs, especially if they are being served on port
>80 or 443. This could perhaps also allow web caches to keep caches of
>the blockchain, thereby making it also more available also.
>
You don't need a BIP if you want to somehow fetch the (initial) block chain
outside the bitcoin protocol. You could download it from some http
server or even pass it along on an USB stick. Then with a simple client change you can import it: https://github.com/bitcoin/bitcoin/pull/883 .
Currently, without this functionality, nodes with restrictive (or
>slow) internet have some options, such as going via a tor proxy, but
>due to the latency, the problem with multiple receptions of the same
>block still occur.
>
If you're behind such a slow internet connection, and concerned about
every bit of bandwidth, it is better to run a lightweight node. For example, Electrum.
Even if you could reduce the wasted bandwidth a bit by puzzling
around with partial blocks, the download will still be substantial (and that's going to get worse before it gets better).
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

2023-06-07 10:03:38

- reply

📅 Original date posted:2012-04-12
📝 Original message:Jeff elaborated the problems very well, but I just want to add this:
Your change is essentially relying (trusting) the server to track a piece of information (your state). Anytime you start depending on another node in some way, it is opening yourself up to be exploited. Nodes should be doing their owning state maintainance, not relying on external parties.
I am very much against the change. As someone who has implemented the complete bitcoin protocol, I had no problems implementing the blockchain download. In fact, I dislike that nodes have to store the last inventory they sent as part of a getblocks in order to trigger the next round. It's be better if there was no state whatsoever.
________________________________
From: Jeff Garzik <jgarzik at exmulti.com>
To: sirk390 at gmail.com
Cc: bitcoin-development at lists.sourceforge.net
Sent: Thursday, April 12, 2012 6:12 PM
Subject: Re: [Bitcoin-development] Adding request/reply id in messages
On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt <sirk390 at gmail.com> wrote:
> Hi,
>
> 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)
>
> The original reason is that I found it very hard to implement robust
> blockchain downloading as we are missing context information:
> The download protocol relies on the other peer sending one (or more) "inv"
> reponse(s) to "getblocks" and sending the "hashContinue".
> But if the other peer doesn't send a response to getblock, send a partial
> response to getblocks, mixes it with some unrelated blocks inventories
> or doesn't send the "hashContinue" it is very hard to detect and handle
> (e.g. ban the peer and switch to another). This could cause some DoS
> attacks by misbehaving peers.
If the peer is misbehaving, then disconnect. Your protocol change
does not offer any clear benefits in this area, as these sorts of
attacks/misbehaviors/bugs are still just as possible, and just as
damaging (or not).
Just disconnect the strange peer!
> The problems are that 1/ we don't know how many "inv" messages to wait for
> after "getblocks" and 2/ we don't know how to distinguish between result of
> "getblocks" and spontaneous "inv" notifications.
> The same is true for "addr" messages (it is both a notification and reply)
> but this is less of a problem as a lack of response to getaddr
> doesn't constitute a DoS.
>
> The idea would be to add a new "requestid" field in messages and define the
> following:
Stateless protocols have a lot of value. They are easiest to
implement, and easier to prove correct. Existing clients like
ArtForz' half-a-node, variants of which are deployed all over the
place in bitcoin-land, rely on the stateless-ness to one degree or
another.
Stateful protocols, too, have their problems as well. One must add
code to help remain "synchronized" between local and remote states,
which your suggested change only hints at. NFSv4 and RPC have a long
history of dealing with stateful-ness issues. Obviously bitcoin P2P
is nowhere near as complex, but the history of NFS development offers
several lessons applicable to your proposed change.
Overall, IMO your listed reasons for needing this major change
(stateless->stateful) do not really justify the change. Handling
initial block download can be accomplished in a number of ways, and
peer(s) may crash or return odd results. You must handle these cases
properly, regardless of the presence of req/reply id's.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
------------------------------------------------------------------------------
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

2023-06-07 10:03:32

- reply

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

2023-06-07 03:12:59

- reply

📅 Original date posted:2012-03-14
📝 Original message:Hi,
luke-jr withdrew BIP 16 and put forwards support for BIP 17. So now there's a consensus to move forwards.
However he submitted BIP 18 to me today. From looking it over, I'm not even sure the idea is tenable nor see the purpose when we are adopting BIP 17. Personally I'd rather not see a high turnover in protocol design when something works (now that we have viable multisig transactions) even compromising on the position of a perfect design.
https://en.bitcoin.it/wiki/BIP_0018
Usually for a BIP, someone submits it to me, I review to see whether the idea is technically sound (not making judgements on the validity), the community discusses the idea and I evaluate the support at the end to change the status. In general I try to accept all BIPs in the interests of fairness, rather than holding a vote or being the executioner.
"Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to bitcoin-development at lists.sourceforge.net. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors <BIPs at Bitcoin.org>. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed."
I don't think BIP 18 has followed this discussion before being accepted. Neither have many other BIPs as we're a small community, and so far we avoided this unneeded level of bureaucracy. However I think this is a good thing to do here.
Should BIP 18 be accepted into the repo or not?
"The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy."
"For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly."
(quotes from BIP 1)

2023-06-07 03:09:55

- reply

📅 Original date posted:2012-02-29
📝 Original message:I support BIP 30.
I gave it a thought. The other ways of resolving this issue, all have various niggles. This is the best way.
________________________________
From: Pieter Wuille <pieter.wuille at gmail.com>
To: Zooko Wilcox-O'Hearn <zooko at zooko.com>
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Sent: Wednesday, February 29, 2012 4:47 PM
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote:
> Could you spell out the attack explicitly? Presumably there aren't a
> lot of people with the "malice energy" to perform the attack but not
> to figure it out for themselves. I, however, have the "niceness
> energy" to think about it for a few minutes but not to figure it out
> for myself. If in your opinion it is realistically dangerous to post
> it publicly, would you be so kind as to include me in the private
> sharing of the explanation?
It's not exactly a secret anymore, as the patch also references it.
Russell O'Connor described the attack on his blog:
http://r6.ca/blog/20120206T005236Z.html
--
Pieter
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
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/20120229/87a7dc28/attachment.html>

2023-06-07 03:01:28

- reply

📅 Original date posted:2012-01-31
📝 Original message:BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To a lesser degree Bitcoin-Qt has the large majority of users too (although that's a line of reasoning I'd discourage).
Normally we should probably Reject BIP 21 and re-submit a new standard (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some sections b) it is still a draft, probably the best thing here is if you all agree on something to run it by BlueMatt and then we'll make it the new BIP 21.
I can see a consensus forming on most parts. Just the send private key is contentious, and there's the topic of adding a time to expire field for merchants (this is a very good idea IMO).
Also BIP 20 is problematic because it is incompatible with about every standard on the web. All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. Note that everytime I have to write Color or Vectorize (as a British speaker) in my code, I die a little inside. But it's convention and American English = International English. Also it would be cool if all code used a *real* international language (like Esperanto) but the world ain't perfect! We live in a decimal-counting English-speaking Windows-using God-worshipping world!
(no offense to decimal-counting English-speaking Windows-using God-worshipping world- I do half those things too :)

2023-06-07 02:56:11

- reply

📅 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

2023-06-07 02:55:52

- reply

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

2023-06-07 02:46:25

- reply

📅 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

2023-06-07 02:43:39

- reply

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

2023-06-07 02:43:19

- reply

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

2023-06-07 02:43:03

- reply

📅 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

2023-06-07 02:39:29

- reply

📅 Original date posted:2011-11-13
🗒️ Summary of this message: The proposed BIP 14 protocol version and user agent format is reasonable, pending changes to the mainline client and API work. Version 0.6 should be the last protocol version bump for a while.
📝 Original message:Nice. I'll check with justmoon when I hopefully meet him at the conference. If all is OK, hopefully 0.6 will be the last protocol version bump for a while.
________________________________
From: Mike Hearn <mike at plan99.net>
To: Amir Taaki <zgenjix at yahoo.com>
Cc: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Sent: Saturday, November 12, 2011 7:31 PM
Subject: Re: [Bitcoin-development] [RFC] BIP 14 - Protocol Version and User Agent
Looks pretty reasonable to me. If Gavin changes the mainline client to use this format I'll change BitcoinJ as well. It'll need a bit of API work so clients are sure to set it up properly.
On Thu, Nov 10, 2011 at 10:16 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
Hi,
>
>
>https://en.bitcoin.it/wiki/BIP_0014
>
>
>Thanks to Gavin Andresen for proof reading and suggesting clarifications. Thanks to Patrick Strateman for suggesting the hierarchical format and pointing out some flaws of browser user-agents to me.
>
>
>The timeline is written in the past tense since BIPs are meant to be readable in the future for explaining why we took certain decisions with bitcoin. A nice cache for future historians when bitcoin is ubiquitous ;)
>
>
>
>The next version 0.6 should be the protocol version which becomes peeled off from the current client. There are still some changes migrating into the protocol that need to be finished.
>
>
>------------------------------------------------------------------------------
>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/20111113/a2a06f10/attachment.html>

2023-06-07 02:39:23

- reply

📅 Original date posted:2011-11-10
🗒️ Summary of this message: BIP 0014 is a hierarchical deterministic wallet structure for Bitcoin. The next version 0.6 should include this protocol version.
📝 Original message:Hi,
https://en.bitcoin.it/wiki/BIP_0014
Thanks to Gavin Andresen for proof reading and suggesting clarifications. Thanks to Patrick Strateman for suggesting the hierarchical format and pointing out some flaws of browser user-agents to me.
The timeline is written in the past tense since BIPs are meant to be readable in the future for explaining why we took certain decisions with bitcoin. A nice cache for future historians when bitcoin is ubiquitous ;)
The next version 0.6 should be the protocol version which becomes peeled off from the current client. There are still some changes migrating into the protocol that need to be finished.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111110/e4da0fa6/attachment.html>

2023-06-07 02:37:26

- reply

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

2023-06-07 02:37:14

- reply

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

2023-06-07 02:37:07

- reply

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

2023-06-07 02:37:01

- reply

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

2023-06-07 02:36:48

- reply

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

2023-06-07 02:36:03

- reply

📅 Original date posted:2011-10-27
🗒️ Summary of this message: Request for help to contact MT to bring it back online as the BIPs are not yet copy-edited and a new one needs to be added.
📝 Original message:Anybody know how to contact MT about getting it back online? I still haven't finished copy-editing the BIPs and need access to them since there's a new one to be added.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111027/6dfec4cd/attachment.html>

2023-06-07 02:27:44

- reply

📅 Original date posted:2011-09-18
🗒️ Summary of this message: Bitcoin Enhancement Proposal (BEP) 0001, adapted from Python PEP 0001, aims to standardize changes to the Bitcoin protocol and is open for revisions and additional authors.
📝 Original message:I adapted the Python PEP 0001 to Bitcoin (its license is public domain):
https://en.bitcoin.it/wiki/Bitcoin_Enhancement_Proposals
https://en.bitcoin.it/wiki/BEP_0001
BEP 0001 is open to additional authors and revisions.
Ideally these should go in a github.com/bitcoin/beps/ repo.
Lets have a standardisation track for changes to the protocol.

2023-06-07 02:27:19

- reply

📅 Original date posted:2011-09-19
🗒️ Summary of this message: Bitcoin.org should become a forum for developers to exchange ideas about the direction of Bitcoin, similar to bittorrent.org, with a process for proposing changes.
📝 Original message:>Eventually, when there are a bunch of bitcoin implementations to
>choose from, I think bitcoin.org should look like bittorrent.org -- it
>should become a forum for developers to exchange ideas about the
>direction of bitcoin.
>
>Gavin Andresen
Thanks for your support. This is a noble ideal and will ensure bitcoin's eventual success by serving as a neutral platform for discussions.
One step I've taken in this direction is to setup a process for proposing changes to the bitcoin protocol. See my other email to this list and this url:
https://en.bitcoin.it/wiki/Bitcoin_Enhancement_Proposals
The first proposal BEP 0001 is copied from Python's PEP 0001 and is a good starting point. I've marked it as a draft since it's only a non-working proposal. After that with mutual consent and discussion, we can move it to active status and start to think about setting up an arbitration committee.
We should in general favour long discussion over voting. The Wikipedia model for resolving issues through hammering out details is superior to debian with a cycling board of voting members.
The bittorrent page looks like a good future ideal to model ourselves off of and the EP pages too:
http://bittorrent.org/beps/bep_0000.html
BEP 0001 needs review and comments. As you can see, bittorrent did the exact same thing here (copying the PEP process) with success:
http://bittorrent.org/beps/bep_0001.html
genjix / Amir Taaki