Stefan Thomas [ARCHIVE]

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

Public Key

npub1f8c8h5evqyy29yp6p7jelyzw6vfwp6jz05exn66l4ygwkj57ytzqmap20e

Profile Code

nprofile1qqsynurm6vkqzz9zjqaqlfvljp8dxyhqafp86vnfad06jy8tf20z93qpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxg60h5u2

Publishing to

relay.nostr.band

Author Public Key

npub1f8c8h5evqyy29yp6p7jelyzw6vfwp6jz05exn66l4ygwkj57ytzqmap20e

Show more details

Last Notes

2023-06-07 10:36:55

- reply

📅 Original date posted:2012-10-21
📝 Original message:> Any objections from other transaction-validating implementations?
Sounds good to me. I think it's important to give people a chance to fix
their software, but Pieter's proposal does that.
On 10/21/2012 7:05 PM, Gavin Andresen wrote:
> Any objections from other transaction-validating implementations?
>
> I strongly support more precisely defining the transaction validity
> rules by changing the reference implementation.
>

2023-06-07 10:28:53

- reply

📅 Original date posted:2012-08-16
📝 Original 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?
>

2023-06-07 10:28:08

- reply

📅 Original date posted:2012-08-13
📝 Original message:> More elaboration of the use cases might therefore be useful.
I'm implementing a DHT, rather than storing the whole blockchain index
locally, a future version of BitcoinJS will store only a user defined
percentage (anywhere from 0-100%.) Any misses will be resolved by
querying the network.
Thanks to ultraprune, we no longer need a full index for verification.
And for all the other use cases like lightweight server queries and
block explorer queries a bit of latency is acceptable in exchange for
scalability and decentralization. This feature will give people to
option to run anywhere from a large BitcoinJS node (100% index) to a
small one (20% index) to a lightweight one (0% index.) All of them are
equally queryable, so if you're just trying out BitcoinJS you won't have
to download the block chain just to run the block explorer example. Only
when your block explorer's traffic grows will you need to contribute
some query services back to the network in order not to get rate-limited.
> these capabilities are not advertised with
> CAddress, so how does one usefully discover and make use of them?
Pieter brought up this very point when he reviewed an earlier draft.
This prompted the creation of the second BIP I mentioned:
https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Service_Discovery
The basic principle is quite simple - prefix the standard addr message
with a service-specific message to mark off service support. It's easy
to implement and very efficient (without compression it's 1.288 bits per
node, with compression it's quite possibly more efficient than the
services field.) Because this stuff is a bit more complex and because it
requires no changes to the Bitcoin protocol, Amir and I chose to split
it off into a separate BIP and I want to work on it a little more. But
if you are wondering how peer exchange might work for these custom
services, please do take a look at it.
> you may as well just form an entirely independent network
When I designed the DHT, I did just that. Later I was working on a
concept for a decentralized pool and I noticed I was solving the same
problems again. And with all three services running a node might be
maintaining three separate TCP connections to the exact same peer.
So then I considered making the DHT network extensible, so that the
decentralized pool protocol could live in there. But, well if I'm doing
that, why not just make the regular Bitcoin protocol extensible and let
both extensions live in there.
For a custom service you DO need the following:
- service-specific DNS seeds
- service announcement (BIP: CS)
- service-specific messages (BIP: CS)
- service-specific peer exchange (BIP: CSD)
And those four things cover a lot of what Bitcoin does. But once you're
thinking about n custom services it starts to look easier to add
semantics for "some nodes support some things" in one network rather
than instantiating n networks.
On the opposite end of the spectrum there are very simple services.
Consider a WebSocket transport. Some nodes might offer
Bitcoin-over-WebSocket, for example to implement an SPV client in the
browser. But they don't connect to each other via WebSocket, since they
prefer plain TCP. So in this case you need peer exchange, but not much
else. You could create a new P2P network for the sole purpose of
exchanging peers, but again it seems much easier if there were ways to
do this on the Bitcoin network.
One final point: A major focus of this BIP is to make it easy to
canonicalize custom services if we choose to do so. The idea is that
custom services get to prove themselves in the wild - those that work
well may be added to the standard protocol. That's a good reason to 1)
encourage custom services to live in-band and 2) recommend compatibility
with Bitcoin's standard mechanisms (12 byte command names, 1 bit service
announcement, 1 bit peer exchange etc.)
On 8/13/2012 3:15 PM, Mike Hearn wrote:
> I think it's pretty reasonable, although people will want to use node
> flags to get into the addr broadcasts anyway.
>
> That said, I suspect (based on previous discussions) that there would
> be quite some pushback against putting extra functionality into the
> core Bitcoin network. Most likely people will re-use the code with
> different peer discovery seeds and bootstrap similar but unrelated P2P
> networks for doing new applications.
>
> For instance, what if we want to do the language translation app I've
> talked about a few times before? You need a way to floodfill broadcast
> invalid transactions to interested parties. The pubsub mechanism in
> the Bitcoin protocol was an interesting way to do that, but I think it
> got removed. To broadcast to interested nodes now, you'd have to find
> them via addr broadcasts and then connect directly. And if you're
> going to do that, you may as well just form an entirely independent
> network.
>
> More elaboration of the use cases might therefore be useful.
>

2023-06-07 10:28:02

- reply

📅 Original date posted:2012-08-13
📝 Original message:Hey everyone,
I was working on some custom protocol extensions for Bitcoin that I
wanted to experiment with and I noticed that in order to enable nodes to
announce these services the only mechanism the protocol currently
provides is to use one of the 64 bits of the services field. This is
obviously a resource that will run out quickly if we all just help
ourselves, so I set out to come up with a standardized way to announce
custom protocol extensions, without using up NODE_* flags.
Please kindly review my solution:
https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Services
Thanks to Amir Taaki, Mike Hearn and Pieter Wuille who provided
invaluable feedback while writing the draft.
Note: Earlier drafts of this BIP contained a description of a mechanism
for peer exchange for these custom services. However, since that part of
the BIP was (1) just a recommendation and (2) rather complex, Amir and I
agreed to split it off into a separate BIP [1] that will be refined some
more and submitted later.
Cheers,
Stefan
[1]
https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Service_Discovery

2023-06-07 10:26:47

- reply

📅 Original date posted:2012-07-29
📝 Original message:I was baffled by this exact script, too. :)
Big props to Gavin for adding those data-driven test cases. I can't
overstate how useful they are.
Is there interest to port more tests (P2SH, checksig, checkmultisig,
block verification, maybe even DoS rules) into data-driven format? It
might be something that I'd like to help with if pull requests in that
direction are welcome.
On 7/29/2012 6:42 PM, Amir Taaki wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> 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:40

- reply

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

2023-06-07 10:21:49

- reply

📅 Original date posted:2012-07-10
📝 Original message:> I wouldn't expect any really important features which don't have
> complicated compromises attached to them to be omitted from all
> clients for all that long.
True, it's those compromises that people should base their decision on.
To make that easier was the motivation for me to suggest feature
matrices in the first place.
Right now if I read Electrum's description, it doesn't say anything
about the tradeoffs with a lightweight client like the slightly weaker
privacy guarantees. At best I could deduce that from the fact that
unlike Bitcoin-Qt it doesn't explicitly list privacy as an advantage.
So applying the same "MyBitcoin test" to the current Bitcoin Clients
page and if you want to be fair, we'd have to assume that if it was
indeed included it would also just be a short pitch listing only pros
and no cons. So it would say something like: "MyBitcoin starts instantly
and is really easy to use and great for beginners." etc.
Obviously if you compare a bad matrix to good short descriptions and
vice versa you'll get the conclusion you're trying to get.
I think Alan had the best idea - let's have the Clients page as it is
and have it link to the wiki for those who want a more detailed
comparison. On the wiki page we can then have explanations of the basic
client types, separate matrices for features and for security/privacy
and whatever else might be useful to know when choosing a client. Then
users who don't really care aren't bothered by "too much information"
and users who do can easily click through and find out about the
different tradeoffs.
On 7/10/2012 5:05 AM, Gregory Maxwell wrote:
> On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>> What a feature matrix is good at though is it allows you to very quickly
>> find the specific feature or general criteria you're looking for without
>> reading through all of the text. So it might be a useful addition maybe
>> not on Bitcoin.org, but certainly on the wiki.
> I'm generally not a fan of feature matrixes, they encourage "checkbox
> decision making"— which is seldom very good for the decider, though
> it's much loved by the marketing department that puts together the
> matrix. But just becase something is loved by marketing departments
> for its ability to set the agenda in variously biased ways doesn't
> mean its a great thing to emulate.
>
> Take the matrix Luke linked to for example[1]. Now imagine that we
> tunnel MyBitcoin from a year ago and drop it into that table. It
> would have every light green, except 'encryption' (which wouldn't have
> been green for bitcoin-qt then either). It would basically be the
> dominant option by the matrix comparison, and this is without any
> lobbying to get MyBitcoin specific features (like their shopping chart
> interface) added, not to mention the "_vanishes with everyone's
> money_" feature.
>
> I don't think I'm being unreasonable to say that if you could drop in
> something that retrospectively cost people a lot into your decision
> matrix and it comes out on top you're doing something wrong.
>
> In tables like this significant differences like "a remote hacker can
> rob you" get reduced to equal comparison with "chrome spoiler", and
> it further biases development motivations towards features that make
> nice bullets (even if they're seldom used) vs important infrastructure
> which may invisibly improve usage every day or keeps the network
> secure and worth having. "Of course I want the fastest startup! Why
> would I choose anything else?" "What do you mean all my bitcoin is
> gone because the four remaining full nodes were taken over and reorged
> it all?"
>
> I wouldn't expect any really important features which don't have
> complicated compromises attached to them to be omitted from all
> clients for all that long.
>
> Basically matrixes make bad decision making fast, and by making it
> fast it's more attractive than careful decision making that always
> takes time. The text is nice because it contextualizes the complete
> feature set and helps you understand why different clients exist, what
> problems they attempt to solve, and what compromises they make. ...
> without making the unrealistic demand of the user they they know how
> to fairly weigh the value of technical and sometimes subtle issues.
>
>
> [1] https://en.bitcoin.it/wiki/Clients
>
> ------------------------------------------------------------------------------
> 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:36

- reply

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

2023-06-07 10:21:29

- reply

📅 Original date posted:2012-07-09
📝 Original message:> However that starts the project down the road of being dominated by
> our internal politics rather than what actually makes sense from the
> end users perspective.
I strongly agree, but this is *why* I suggested moving it to the wiki. I
recently had to choose an XMPP client and I looked on xmpp.org - after a
frustrating experience with their listing [1], I went to Wikipedia who
have an decent feature-based matrix [2].
(There may be better examples, but I'm using this one, because this
actually did happen.)
This is just anecdotal, but there are some reasons why wikis tend to do
a better for this kind of thing is because they are:
- more up-to-date (anyone can update them)
- more in touch with users:
-> Users can edit the page and add a column to a feature matrix for
example).
-> The editing discussions include users. I guarantee there are more
Bitcoin end users with a wiki account than a Github account.
- immediately recognizable as a wiki (thanks to Mediawiki/Wikipedia.)
As such many users will correctly treat and interpret the information
presented as community-generated and fallible.
So they are more user-oriented in the sense that they will be influenced
by a diverse set of backgrounds and views vs. a Github based page which
will be dominated by developers. If you want to see "the result of
internal politics", the current client page is a good example. We
couldn't agree on the columns for a feature matrix, so now we just have
walls of text. Some of the options that are de-facto the most popular
with users like BlockChain.info or just using your MtGox account are not
mentioned at all. When analyzing client security, Greg discussed
counterparty risks but ignored other risk factors like default backup
behavior and the usability of security features.
But even if I grant you that those clients' overall risk profile is
worse than Bitcoin-Qt's, maybe I'm happy to take that risk in exchange
for less setup/maintenance effort. Based on our support requests at
WeUseCoins I know that there are tons of users with < 1 BTC in their
wallets. If my hourly wage is 20$ and I have 20$ in my Bitcoin wallet
then spending one hour per month downloading/updating/figuring-out the
client is equivalent to a total loss.
The list is obviously designed by open-source developers and that's
fine, it's bitcoin.org, arguably we *should* try to push users in a
specific direction, arguably we *should* err on the side of caution in
order to not be caught recommending a hosted wallet that gets hacked.
But if user orientation is supposed to be the focus, then the wiki will
both allow us (because it's less "official") and force us (because users
will have a say) to include even clients we personally wouldn't use. :)
[1] http://xmpp.org/xmpp-software/clients/
[2]
http://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#XMPP-related_features
On 7/9/2012 8:30 PM, Mike Hearn wrote:
> It's easy to say, this page is controversial, so let's get rid of it.
>
> However that starts the project down the road of being dominated by
> our internal politics rather than what actually makes sense from the
> end users perspective. That route spells doom for any product. You can
> always tell when a UI or product is the result of internal politics,
> whether it be the difficulty of plug-n-play hardware on Linux (no
> driver api) to how Microsoft is incapable of producing anything that
> isn't built on Windows. Gmail labs is another example of this.
>
> It makes sense that if I go to bitcoin.org, I am educated about the
> system and what is available for it. It doesn't make any sense to have
> some stuff on the main site and other stuff on a wiki (which may get
> randomly vandalized and looks less professional), based on how
> "controversial" some developers find it.
>
> FWIW I am dead set against anyone randomly changing the website
> without a pull request and such changes should be reverted and
> resubmitted through the proper channels. I don't perceive much value
> in randomization or trying to make this page "fair". If anything, we
> need to pick somebody (one person) who has a strong focus on regular
> people and their needs, then just make them the sole committer to the
> website. That way disputes can be resolved by them making a decision,
> instead of ridiculous edit wars.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 10:21:03

- reply

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

2023-06-07 10:18:59

- reply

📅 Original date posted:2012-06-24
📝 Original message:Very interesting for you to bring this up. I had a similar idea for a
totally different use case. Greg recently pointed out an interesting
dilemma saying that (significantly) larger blocks would lead to
centralization. So I've been working on a design for a decentralized
pool that can handle gigabyte sized blocks by splitting up the work
among its members.
At the moment P2Pool nodes all verify all transactions in all blocks.
But it seems feasible to create a system where miners who have over the
last 10000 blocks contributed to the pool's proof-of-work are allocated
a proportional piece of verification work with redundancy and
deterministic randomness that makes manipulation of the allocation
extremely difficult. Such a pool would be very unlikely to accept an
invalid block or transaction in practice.
However, with these block sizes obviously non miners are going to have
to be SPV, so even just a 0.0001% chance of an invalid block being
accepted has profound implications for the network. If a decentralized
pool like that had more than 50% of the hashing power and it accepted a
single invalid block, that tainted chain would be forever regarded as
valid by SPV clients. There needs to be some way to recover once an
invalid block has been accidentally accepted by an imperfect miner.
Based on that I also started to think about proofs of invalidity that
would circulate. Basically you would add a new network message that
would contain the proof that a specific signature and therefore the
whole block is invalid.
As long as the block's proof-of-work is valid and the block's parent is
one of the last n = 50000 blocks, the message is relayed (subject to a
cooldown, warnings would be less frequently relayed the older the
offending block is.)
The mechanism works in exactly the way Mike mentions: It allows even SPV
clients to punish any miner who is dishonest or negligent with their
verification work. That gives miners a good reason not to be dishonest
or negligent in the first place.
(Motivation:
Processing more transactions means that hashing is a smaller part of the
overall cost for miners. For example, paying for 50 BTC worth of hashing
per block costs 0.05 BTC per tx at 1000 tx/block, but only 0.0005 BTC at
100000 tx/block.
Number of transactions is a lever that lets us have lower fees and more
network security at the same time. Like Greg correctly pointed out, this
is not worth having if we have to sacrifice decentralization. But if we
don't, it becomes a no-brainer.
My IMTUO proposal [1] showed a way where miners don't need a copy of the
set of unspent outputs at all. This means the minimum storage
requirements per node no longer grow with the number of transactions.
However, the price for this was about five times greater bandwidth usage
per verified transaction. Since every miner still had to verify every
transaction it looked like bandwidth would become an even bigger problem
with IMTUO than storage would have been without. However, if a small
miner can do less than 100% verifications and still contribute, suddenly
IMTUO may become viable. That would accomplish the holy grail of Bitcoin
scalability where the network successfully runs on trust-atomic entities
all of which can choose to store only a small fraction of the block
chain, verify a small fraction of transactions and perform a small
fraction of the hashing.)
[1] https://en.bitcoin.it/wiki/User:Justmoon/IMTUO
On 6/24/2012 2:45 PM, Mike Hearn wrote:
> I've been having a discussion with d'aniel from the forums about how
> to handle the possibility of a majority-miner conspiracy to raise
> inflation, if most economic actors use SPV clients.
>
> Because of how blocks are formatted you cannot check the coinbase of a
> transaction without knowing the fees in the block, and the fees can
> only be calculated if you have all the input transactions for every
> transaction in that block. Because the attack scenario is an attempted
> takeover of the economy by miners, attempting to put hints into the
> blocks won't work - we have to assume the hardest chain is in fact
> wrong according to the rules signed up to by the Bitcoin user.
>
> The most obvious goal for a cartel of miners is to change the
> inflation formula, either for purely selfish reasons (they want more
> money than can be obtained by fees) or due to coercion by
> governments/central banks who still subscribe to the "inflation is
> good" idea.
>
> Whilst "good" nodes (still on the old ruleset) won't relay blocks that
> violate the rules no matter how hard they are, in a situation where an
> SPV client DOES hear about the bad best chain, it would switch to it
> automatically. And who knows how the network might look in future -
> perhaps most nodes would end up run by miners, or other entities that
> upgrade to the new ruleset for other reasons.
>
> d'aniel made a good proposal - having good nodes broadcast
> announcements when they detect a rule that breaks the rules, along
> with a proof that it did so. Checking the proof might be very
> expensive, but it would only have to be done for split points,
> limiting the potential for DoS. If a node announces that it has a
> weaker chain and that the split point is a rule-breaker, the SPV
> client would download the headers for the side chain to verify the
> split, then download all the transactions in the split block along
> with all their inputs, and the merkle branches linking the inputs to
> the associated block headers. In this way the fee can be calculated,
> the inflation formula applied and the coinbase value checked.
>
> If the block is indeed found to be a rule-breaker, it'd be blacklisted
> and chains from that point forward ignored.
>
> Miners may decide to allow themselves to create money with
> non-index-zero transactions to work around this. In that case the good
> node can announce that a given tx in the rule-breaker block is
> invalid. The SPV node would then challenge nodes announcing the longer
> chain to provide the inputs for the bad tx all the way back to a
> pre-split coinbase.
>
> Doing these checks would be rather time consuming with huge blocks,
> but it's a last resort only. In the absence of bugs, the mere presence
> of the mechanism should ensure it never has to be used.
>
> ------------------------------------------------------------------------------
> 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:42

- reply

📅 Original date posted:2012-06-22
📝 Original message:Flights booked. Mike Hearn and I will be there. :)
On 6/22/2012 1:03 AM, Amir Taaki wrote:
> This is happening in Berlin if anyone is around: http://bitcoin-hackathon.com/
>
> I am happy to host if space is needed.
>
>
> ------------------------------------------------------------------------------
> 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:17:47

- reply

📅 Original date posted:2012-06-19
📝 Original message:Here are my 2 cents after using LevelDB as the default backend for
BitcoinJS for about a year.
LevelDB was written to power IndexedDB in Chrome which is a JavaScript
API. That means that LevelDB doesn't really give you a lot of options,
because they assume that on the C++ layer you don't know any more than
they do, because the actual application is on the JavaScript layer. For
example whereas BDB supports hashtables, b-trees, queues, etc., LevelDB
uses one database type, LSM trees which is an ordered data structure
that is pretty good at everything.
Another gotcha was the number of file descriptors, LevelDB defaults to
1000 per DB. We originally used multiple DBs, one for each of the
indices, but it was easy enough to combine everything into one table,
thereby solving the fd issue. (Lowering the file descriptor limit also
works of course, but if you lower it too much, LevelDB will start to
spend a lot of time opening and closing files, so I believe combining
your tables into one is the better option.)
Overall, LevelDB is a fantastic solution for desktop software that is
faced with multiple use cases that aren't known at compile time. It
isn't really designed for something like Bitcoin which doesn't need
ordered access, has relatively predictable characteristics and - at
least some of the time - runs on servers.
That said, it does seem to work well for the Bitcoin use case anyway.
Thanks to the LSM trees, It's very quick at doing bulk inserts and we
don't seem to need any of the bells and whistles that BDB offers. So I
can't think of a reason not to switch, just make sure you all understand
the deal, LevelDB unlike Tokyo/Kyoto Cabinet is *not* intended as a
competitor or replacement for BDB, it's something quite different.
On 6/19/2012 6:06 PM, Mike Hearn wrote:
>> What problem does it solve?
> Primarily that block verification and therefore propagation is too
> slow because it's very CPU and IO intensive. The CPU work can be
> multi-threaded. The IO work, not as much. As Bitcoin grows we need to
> scale the nodes. Eventually there may be multi-machine nodes, but for
> now we can buy more time by making the existing nodes faster.
>
> I don't see this as a replacement for moving users to SPV clients.
> Obviously, otherwise I would not be writing one ;)
>
>> If the problem it will solve is the "too easy to get a DB_RUNRECOVERY
>> error" because bdb is fragile when it comes to its environment... then
>> LevelDB looks very interesting.
> I have no experience with how robust LevelDB is. It has an API call to
> try and repair the database and I know from experience that BigTable
> is pretty solid. But that doesn't mean LevelDB is.
>
>> If the problem is bdb is creaky and old and has obscure semantics and
>> a hard-to-work-with API, then yes, lets switch (I'm easily seduced by
>> a pretty API and blazing fast performance).
> The code is a lot simpler for sure.
>
>> As long as it compiles and runs on mac/windows/linux that doesn't
>> really worry me.
> It was refactored out of BigTable and made standalone for usage in
> Chrome. Therefore it's as portable as Chrome is. Mac/Windows/Linux
> should all work. Solaris, I believe, may need 64 bit binaries to avoid
> low FD limits.
>
>> Lack of infrastructure because it is new does worry me; for example,
>> could I rework bitcointools to read the LevelDB blockchain? (are
>> there python bindings for LevelDB?)
> Yes: http://code.google.com/p/py-leveldb/
>
> First look at the code is here, but it's not ready for a pull req yet,
> and I'll force push over it a few times to get it into shape. So don't
> branch:
>
> https://github.com/mikehearn/bitcoin/commit/2b601dd4a0093f834084241735d84d84e484f183
>
> It has misc other changes I made whilst profiling, isn't well
> commented enough, etc.
>
> ------------------------------------------------------------------------------
> 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:54

- reply

📅 Original date posted:2012-06-15
📝 Original message:I do agree that changing/lifting the block size limit is a hard fork
measure, but Mike raised the point and I do believe that whatever we
decide to do now will be informed by our long term plan as well. So I
think it is relevant to the discussion.
> Can someone please help quantify the situation? kthanks :)
According to BlockChain.info we seem to have lots of small blocks of
0-50KB and some larger 200-300 KB blocks. So in terms of near term
measure one thing I would like to know is why miners (i.e. no miners at
all) are fully exhausting the available block size despite thousands of
transactions in the memory pool. I'm not too familiar with the default
inclusion rules, so that would certainly be interesting to understand.
There are probably some low hanging fruit here.
The fact that SatoshiDice is able to afford to pay 0.0005 BTC fees and
fill up the memory pool means that either users who care about speedy
confirmation have to pay higher fees, the average actual block size has
to go up or prioritization has to get smarter. If load increases more
then we need more of any of these three tendencies as well. (Note that
the last one is only a very limited fix, because as the high priority
transactions get confirmed faster, the low priority ones take even longer.)
On 6/15/2012 7:17 PM, Jeff Garzik wrote:
> On Fri, Jun 15, 2012 at 12:56 PM, Stefan Thomas <moon at justmoon.de> wrote:
>> The artificial limits like the block size limit are essentially putting
> [...]
>
> Changing the block size is an item for the hard-fork list. The chance
> of the block size limit changing in the short term seems rather low...
> it is a "nuclear option."
>
> 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?
>
> Clearly SatoshiDice is a heavy user of the network, but there is a
> vast difference between a good stress test and a network flood that is
> shutting out non-SD users.
>
> Can someone please help quantify the situation? kthanks :)
>

2023-06-07 10:14:11

- reply

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

2023-06-07 10:10:09

- reply

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

2023-06-07 03:13:02

- reply

📅 Original date posted:2012-03-14
📝 Original message:> luke-jr withdrew BIP 16 and put forwards support for BIP 17.
You are so funny sometimes. xD
On 3/14/2012 4:07 PM, Amir Taaki wrote:
> 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)
>
> ------------------------------------------------------------------------------
> 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
>

2023-06-07 03:12:02

- reply

📅 Original date posted:2012-03-03
📝 Original message:> I've updated the draft to include long polling, and remove some assumptions of
> using HTTP for transport.
Looks good to me.
On 3/3/2012 4:44 PM, Luke-Jr wrote:
> On Saturday, March 03, 2012 10:05:58 AM Gavin Andresen wrote:
>>> HTTP and JSON-RPC are a client-server model; there is no way for the
>>> server to make calls to the client. It's not practical to expect clients
>>> to run their own JSON-RPC server - many cannot listen on WAN ports at
>>> all.
>> You're doing that thing where either you say something before you've
>> done adequate research, or you're being needlessly pedantic; I just
>> copied and pasted this from section 2.1 of the JSON-RPC spec:
> I wasn't aware anyone was considering JSON-RPC over anything other than HTTP.
>
> I've updated the draft to include long polling, and remove some assumptions of
> using HTTP for transport.
>
> ------------------------------------------------------------------------------
> 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
>

2023-06-07 03:11:56

- reply

📅 Original date posted:2012-03-03
📝 Original message:> Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S->C json-rpc, what (javascript) library do you use for this?
As for an explicitly standard way, there is none. The JSON-RPC 1.0 spec
<http://json-rpc.org/wiki/specification> says "The specifications do not
require a certain transport protocol. The use of TCP/IP socket streams
is encouraged. The serialized request and response objects are sent to
the peers through the byte streams. " The JSON-RPC 2.0 spec
<http://jsonrpc.org/specification> goes out of its way to say "It is
transport agnostic in that the concepts can be used within the same
process, over sockets, over http, or in many various message passing
environments."
The de-facto standard for bidirectional JSON-RPC is plain TCP sockets.
BitcoinJS currently implements this - we detect whether an incoming
connection is HTTP or raw JSON-RPC based on the first character. (HTTP
must start with an uppercase letter, raw JSON-RPC must start with an
opening curly bracket.)
There are two things to watch out for with JSON-RPC over plain TCP:
1. Plain TCP sockets (unlike HTTP) have no standardized authentication
mechanism, so I added an extra RPC call auth("username", "password").
2. The TCP packets may or may not correspond to JSON-RPC messages. You
can either use a streaming JSON parser (yajl in ANSI C, Jackson in Java,
etc.), or you can just count (non-string-literal) curly braces to detect
when a complete message has arrived.
Many JSON-RPC libraries come with TCP socket support out of the box:
http://json-rpc.org/wiki/implementations
We're planning to add more features to our JSON-RPC API in the future,
such as:
- JSON-RPC over TLS sockets
- Challenge-response authentication
- TLS client handshake (certificate authentication)
As for HTTP Keep-Alive: It works, but I don't think it's very widely
supported among client libraries and HTTP isn't really made for this
type of thing, so my gut instinct would be to avoid it. That said, it
doesn't hurt to offer the option.
On 3/3/2012 6:08 PM, Michael Grønager wrote:
>> HTTP and JSON-RPC are a client-server model; there is no way for the server to
>> make calls to the client. It's not practical to expect clients to run their
>> own JSON-RPC server - many cannot listen on WAN ports at all.
> Well, I think what Stefan had in mind was http keep-alive combined with an event system. So similar to the way a web chat application work, just for json-rpc. BitcoinJS already uses this for realtime updating a webwallet. Libcoin is also prepared for this with a quite advanced, non-blocking, http server so I second Stefan that an update function could indeed be of relevance.
>
> Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S->C json-rpc, what (javascript) library do you use for this?
>
> Cheers,
>
> Michael
>
>
>> ------------------------------------------------------------------------------
>> 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
>
> ------------------------------------------------------------------------------
> 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/20120304/72c6808b/attachment.html>

2023-06-07 03:11:47

- reply

📅 Original date posted:2012-03-03
📝 Original message:From what I understand the BIP uses a polling model, e.g. a miner would
use getmemorypool to request new work from a pool in intervals. Would it
make sense to specify a version of the API supporting long polling?
For BitcoinJS specifically, since we also support JSON-RPC over TCP, I'd
even be interested in a genuine "push" API. Something like C->S
"listenmemorypool", S->C "updatememorypool" (continually).
On 2/28/2012 11:06 PM, Luke-Jr wrote:
> Please review and comment/critique:
> https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 03:11:09

- reply

📅 Original date posted:2012-03-03
📝 Original message:Since several independent clients (I know at least libcoin
<https://github.com/ceptacle/libcoin/blob/master/src/coinHTTP/RequestHandler.cpp>
and BitcoinJS
<https://github.com/bitcoinjs/bitcoinjs-server/tree/master/lib/rpc>) aim
to implement JSON-RPC APIs which are either a superset of the original
client's or have at least some compatible functions, I think you can
make a case for including JSON-RPC API calls within the domain of BIPs.
In this instance the BIP aims to create a common protocol between
different clients, miners, mining proxies and pools. That's a lot of
software, so standardization definitely seems like a good idea and I
can't think of a reason not to use the BIP process.
I have some comments on the content of the BIP, but since this thread is
more of a meta-discussion I'll wait until the BIP is officially proposed.
On 3/2/2012 7:51 PM, Amir Taaki wrote:
> Hi,
>
> I got sent this BIP:
>
> https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypool
>
> What is your opinion on this? Is it BIP related?
>
> It is a implementation-specific non-bitcoin-protocol proposal. My
> understanding of BIPs is that
> they apply across bitcoin implementations and largely focus on the
> most generic use-cases
> (like the URIs) and the protocol. Things which affect all clients, and
> allow the system to function
> as a united whole.
>
> That BIPs especially focus on the protocol, and that something like
> this is outside the mandate
> of the BIP process.
>
> For instance, we could imagine a future scenario. Bitcoin-Qt is
> currently based off bitcoind's
> codebase. However wumpus built the client in mind with an abstraction
> layer to enable multiple
> backends (a good design). In our hypothetical situation, there are 3
> different backend codebases
> using Bitcoin-Qt. I do not think a proposal to mandate a changing to
> Bitcoin-Qt's abstraction
> layer or a change in the UI placement would be appropriate BIP material.
>
> OTOH, many clients do need to make use of URIs and the BIP process is
> totally correct, as it
> standardises a behaviour which is needed for interoperability of the
> network and community.
>
> Thoughts?
>
>
> ------------------------------------------------------------------------------
> 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/20120303/f86175ef/attachment.html>

2023-06-07 03:09:58

- reply

📅 Original date posted:2012-02-29
📝 Original message:> The purpose of this mail is asking for support for adding this rule to
> the protocol rules. If there is consensus this rule is the solution, I
> hope pools and miners can agree to update their nodes without lengthy
> coinbase-flagging procedure that would only delay a solution. So, who
> is in favor?
Looks good to me. I also second the notion that we should deploy this
quickly, given that it's a bug fix.
On 2/28/2012 5:48 PM, Pieter Wuille wrote:
> Hello all,
>
> as some of you may know, a vulnerability has been found in how the
> Bitcoin reference client deals with duplicate transactions. Exploiting
> it is rather complex, requires some hash power, and has no financial
> benefit for the attacker. Still, it's a security hole, and we'd like
> to fix this as soon as possible.
>
> A simple way to fix this, is adding an extra protocol rule[1]:
>
> Do not allow blocks to contain a transaction whose hash is equal to
> that of a former transaction which has not yet been completely spent.
>
> I've written about it in BIP30[2]. There is a patch for the reference
> client, which has been tested and verified to make the attack
> impossible. The change is backward compatible in the same way BIP16
> is: if a supermajority of mining power implements it, old clients can
> continue to function without risk.
>
> The purpose of this mail is asking for support for adding this rule to
> the protocol rules. If there is consensus this rule is the solution, I
> hope pools and miners can agree to update their nodes without lengthy
> coinbase-flagging procedure that would only delay a solution. So, who
> is in favor?
>
> [1] https://en.bitcoin.it/wiki/Protocol_rules
> [2] https://en.bitcoin.it/wiki/BIP_0030
>

2023-06-07 02:56:53

- reply

📅 Original date posted:2012-01-17
📝 Original message:I'm firmly against a *blackout* - it would harm users' trust in Bitcoin
since people looking to download the client or to get information about
Bitcoin may end up in the wrong place. I constantly have to delete
YouTube spam advertising this or that "miracle GPU miner" or "secure
Bitcoin client", which of course are all just the same trojan.
As for making a statement or putting up a banner - that's ok with me.
On 1/17/2012 7:15 AM, Gregory Maxwell wrote:
> On Mon, Jan 16, 2012 at 9:37 PM, Kyle Henderson<k at old.school.nz> wrote:
>> For those that believe one particularly noisy country in the North America
>> region with a policy called SOPA or PIPA directly affects Bitcoin - can you
>> point out precisely where it does so?
> In addition to the concerns about internet freedom and domain name
> system filtering which are against the interests of bitcoin users and
> the bitcoin system generally, SOPA contains new requirements for
> payment networks which may adversely impact Bitcoin services
> businesses and limit their ability to do business in the US and other
> places where similar legislation is adopted. There are many millions
> of potential Bitcoin users in the US, so US law matters for our
> ecosystem even though far from all Bitcoin users are in the US
> themselves.
>
> (21) PAYMENT NETWORK PROVIDER-
> (A) IN GENERAL- The term `payment network provider' means
> an entity that directly or indirectly provides the proprietary
> services, infrastructure, and software to effect or facilitate a
> debit, credit, or other payment transaction.
> [...]
> (i) PREVENTING AFFILIATION- A payment network provider
> shall take technically feasible and reasonable measures, as
> expeditiously as possible, but in any case within 5 days after being
> served with a copy of the order, or within such time as the court may
> order, designed to prevent, prohibit, or suspend its service from
> completing payment transactions involving customers located within the
> United States or subject to the jurisdiction of the United States and
> the payment account--
> (I) which is used by the foreign infringing site,
> or portion thereof, that is subject to the order; and
> (II) through which the payment network provider
> would complete such payment transactions.
>
> If you really want to go for the more extreme interpretation, it's not
> hard to conclude that the Bitcoin system itself is a "payment network"
> by the definition under the act, and if so in theory the AG's office
> could— without due process— order miners and mining pools located in
> the US to, for example, not process transactions containing the well
> known addresses of targeted infringing sites (e.g. The Wikileaks
> donation address). Though I personally think this is far out.
>
> I also think that other people will covered the SOPA/PIPA awareness
> (e.g. Wikipedia is shutting down for 24 hours) more than we could
> possibly do with our own resources.
>
> But this attitude of it being someone elses problem? I think thats
> nonsense. We live in _one world_, one world which is getting smaller
> every day. The value of a network—or of a economy— comes from the
> number of potential connections it can make. One reason Bitcoin is
> good is because it deconstructs some of the old barriers and anything
> that risks imposing new ones is a threat to us all.
>
> So, don't participate because bitcoin.org's help would be so small as
> to be pointless— sure. But because it doesn't matter? hardly.
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 02:54:51

- reply

📅 Original date posted:2012-01-02
📝 Original message:+1. I love this proposal.
It's two less bytes than OP_EVAL even.
It allows static analysis.
It doesn't require any change to the script interpreter. (You can do a
static replacement step between parsing and execution.)
It allows all urgent use cases.
It doesn't consume a NOP. If we ever want recursion or something else,
we can still add OP_EVAL,... then.
@roconnor:
> 1. make the script: OP_NOP1 HASH160 <push-20-byte-hash> EQUAL to make
> it extremely easy to see from the first byte that this is verly likely
> to be a special transaction (or more accurately if the first byte
> isn't OP_NOP1 then you immediately know it isn't a special script and
> can even disregard the token).
I disagree. If people actually do mean HASH160 <hash> EQUAL, let *them*
add a NOP. Or better to avoid NOP let them use HASH160 <hash>
EQUALVERIFY 1. Point is, if you don't want code replacement you can
easily break the pattern. But code replacement will be overwhelmingly
more common, so it should be as small as possible. Every byte matters.
On 1/2/2012 4:59 PM, Gavin Andresen wrote:
> Here are my latest thoughts on a safer OP_EVAL alternative, inspired
> by all the ideas and agitated IRC and email
> discussions of the last week or so:
>
> Goal: Let users publish a short "funding address" that is the hash of
> an arbitrary redemption Script revealed when they spend the funds,
> implemented in a backwards-compatible-in-the-blockchain way.
>
> Proposal:
>
> A new 'standard' transaction type, "pay to Script hash":
>
> scriptPubKey: HASH160<push-20-byte-hash> EQUAL
>
> Redeemed with the same scriptSig as the OP_EVAL proposal:
> <signatures> <serialized Script>
>
> Old clients/miners will ignore<signatures> and just validate that the
> hash of<serialized Script> matches.
>
> New clients/miners will recognize the new type of transaction and will
> do the following additional validation:
>
> 1. Fail validation if there were any operations other than "push data"
> in the original scriptSig.
> 2. Deserialize the top (last) item on the scriptSig stack (fail
> validation if it fails to deserialize properly).
> 3. Run an additional validation on the deserialized script, using the
> remaining items on the scriptSig stack and the deserialized script as
> the scriptPubKey.
>
>
> ---------------
>
> As Amir said in IRC chat today, "the idea is a hack.... but I like it."
>
> I like it, too-- it is cleaner than OP_EVAL, more straightforward to
> implement, and pretty much exactly matches the feature I care about
> (moving code from the scriptPubKey to the scriptSig). There are no
> special cases like "CODESEPARATORS not allowed in<serialized
> script>".
>

2023-06-07 02:54:41

- reply

📅 Original date posted:2012-01-02
📝 Original message:The OP_EVAL discussion went into some private discussion for a bit, so
here is a summary of what we talked about.
Roconnor pointed out that the currently proposed OP_EVAL removes the
ability to statically reason about scripts. Justmoon pointed out that
this is evidenced by the changes to GetSigOpCount:
Currently, the client first counts the number of sigops and if it is
over a certain limit, it doesn't execute the script at all. This is no
longer possible with OP_EVAL, since OP_EVAL can stand for any number of
other operations, which might be part of some piece of data. The script
that is executed by OP_EVAL can be changed (polymorphic code). Gavin's
patch deals with this, by counting the sigops at runtime and aborting
only after the limit has been reached.
Here is an example for a script that based on naive counting contains no
sigops, but in fact contains 20:
[20 signatures] 20 [pubkey] OP_DUP OP_DUP OP_2DUP OP_3DUP OP_3DUP
OP_3DUP OP_3DUP OP_3DUP 20 "58959998C76C231F" OP_RIPEMD160 OP_EVAL
RIPEMD160( 58 95 99 98 C7 6C 23 1F )
hashes to
AE4C10400B7DF3A56FE2B32B9906BCF1B1AFE975
which OP_EVAL interprets as
OP_CHECKMULTISIG "400B7DF3A56FE2B32B9906BCF1B1AFE9" OP_DROP
The nonce 58959998C76C231F was generated using this code:
https://gist.github.com/1546061
Gavin and Amir argued that it is possible to "dry run" the script,
avoiding the expensive OP_CHECKSIG operation and running only the other
very cheap operations. However, sipa pointed out that in the presence of
an OP_CHECKSIG a dry runner cannot predict the outcome of conditional
branches, so it has to either do the OP_CHECKSIG (and become just a
regular execution) or it has to follow both branches. Roconnor and
justmoon suggested the following script to illustrate this point:
[sig] [pubkey]
[some data]
[sig] [pubkey] OP_CHECKSIG OP_IF OP_HASH160 OP_ELSE OP_HASH256 OP_ENDIF
(previous line repeated 33 times with different sigs/pubkeys)
OP_EVAL
This script is valid assuming that the resulting hash from the branch
that is chosen based on what signatures are valid contains an
OP_CHECKSIG. (And the initial [sig] and [pubkey] are valid.) But a dry
runner trying to count how many OP_CHECKSIGs this script contains would
run into the first OP_CHECKSIG OP_IF and have to run both branches. In
both branches it would again encounter a OP_CHECKSIG OP_IF and run all
four branches, etc. In total it has to run (2^33 - 2) * 1.5 SHA256
operations (8 GHash) and 2^32 - 1 RIPEMD160 operations. Therefore we now
believe a dry runner is not possible or at least too complicated to be
involved in protocol rules such as the sigops limit.
As a result people are now on a spectrum from those who feel strongly
that static analysis is an important property and not something to give
up easily all the way to those who think it's superfluous and the other
side is just unnecessarily delaying OP_EVAL deployment.
One thing I want to note is that static analysis is a property for which
there is a better argument than for other, weaker properties, such as
limited recursion depth. Bitcoin currently allows you to:
* Tell if a script contains a specific opcode or not
* Count how many times a script will execute an operation at most
* Count how many total operations a script will execute at most
* Count how many signatures a script will execute at most
* Find the maximum length of a datum pushed onto the stack
* Find the maximum number of items that can be pushed onto the stack
* Find the maximum size (in bytes) of the stack
* Calculate how long a script will run at most
OP_EVAL as proposed makes these upper bounds almost meaningless as it
can contain, indirectly, up to 32 instances of any other opcode. (About
3-6 instances are currently practical.) The only way to answer these
questions would then be to fully execute the script.
Suppose we want to one day allow arbitrary scripts as IsStandard, but
put constraints on them, such as enforcing a subset of allowed opcodes.
(See list above for other possible restrictions.) If we want to include
OP_EVAL in the set of allowed opcodes, it's important that OP_EVAL is
implemented in a way that allows static analysis, because we can then
allow it while still maintaining other restrictions.
If proponents of the current implementation want to argue that we don't
need static analysis now, the burden is on them to show how we could
retrofit it when/if we get to this point or why they think we will never
want to allow some freedom in IsStandard that includes OP_EVAL.
There are several proposals for OP_EVAL that allow static analysis:
* Using a fixed position reference prefix (sipa)
* Using an execute bit on data set by an opcode (justmoon)
* Using OP_CODEHASH (roconnor)
* Using OP_CHECKEDEVAL (sipa)
* Using OP_HASH160 OP_EQUALVERIFY as a special sigPubKey (gavinandresen)
Let's fully develop these proposals and see how much of a hassle it
would actually be to get a statically verifiable OP_EVAL. I think that's
a prerequisite for having the argument on whether it is *worth* the hassle.
(Update: Gavin's latest proposal looks *very* good, so that may settle
the debate quickly.)
On 12/30/2011 6:19 PM, roconnor at theorem.ca wrote:
> On Sat, 31 Dec 2011, Chris Double wrote:
>
>> On Fri, Dec 30, 2011 at 5:42 AM, <roconnor at theorem.ca> wrote:
>>> Basically OP_DUP lets you duplicate the code on the stack and that
>>> is the
>>> key to looping. I'm pretty sure from here we get get Turing
>>> completeness.
>>> Using the stack operations I expect you can implement the SK-calculus
>>> given an OP_EVAL that allows arbitrary depth.
>>>
>>> OP_EVAL adds dangerously expressive power to the scripting language.
>>
>> If you look at the archives of the concatenative programming mailing
>> list [1] you'll see lots of examples of people creating stack
>> languages with minimal operations that exploit similar functionality
>> to reduce the required built in operations. The discussion on the list
>> is mostly about stack based languages where programs can be pushed on
>> the stack and executed (eg. Joy [2]/Factor/Some Forths).
>>
>> I don't think the scripting engine in bitcoin has the ability to
>> concatenate, append or otherwise manipulate scripts on the stack to be
>> eval'd though does it?
>
> It will limited ability manipulate scripts on the stack through the
> use of arithmetic and hashing operations, and if OP_CAT, OP_SUBSTR and
> friends are ever restored, it will have even more abilities.
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>
>
> _______________________________________________
> 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/20120102/5e4eb4bb/attachment.html>

2023-06-07 02:53:38

- reply

📅 Original date posted:2011-12-29
🗒️ Summary of this message: OP_EVAL rollout on main network may be delayed, but deploying it on testnet quickly can allow for real-life application testing and adjustments.
📝 Original message:> RE: delaying EVAL rollout: I could live with rolling out just BIP 11
> (up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and
> delaying EVAL rollout on the main network, but I worry that will just
> encourage people to delay thoroughly reviewing/testing for a couple of
> months, and we'll be right back here at the beginning of March.
How about releasing it on testnet first? If you want "less smart" people
such as myself to help test, well I don't think I would get anywhere if
I tried to abstractly reason about every possibility. Low-level testing
is certainly important, but for me "thorough testing" requires an actual
network of nodes (running different clients) and applications capable of
creating and verifying real OP_EVAL transactions.
My suggestion would be: Deploy OP_EVAL on testnet quickly, let's build
some real-life applications and if it works well, /then /let's pull the
trigger for mainnet. If some issues or improvements arise, we'll have a
chance to adjust it and try again.
I don't think this is too conservative or paranoid. I think this is a
textbook use case for testnet.
On 12/29/2011 7:00 PM, Gavin Andresen wrote:
> RE: preventing OP_EVAL from executing the result of calculations:
>
>> This is not adequate:<data> OP_SHA256 OP_EVAL runs random code that is more> than 5 bytes.
> Good point, the rule should be "OP_EVAL shall fail if asked to execute
> 8 or fewer bytes."
>
> RE: this minor disadvantage:
>
>>> OP_EVALs are not executed, and so the code associated with them does
>>> not have to be part of the transaction, if they are in the
>>> non-executed branch of an OP_IF. That could be good for privacy, and
>>> could be good for reducing block-chain size.
>> I don't understand the above paragraph.
> It is the "Either This or That can redeem" case that motivated me to
> allow 2-deep EVAL recursion.
>
> Start with the most straightforward code for doing "this or that" (in
> pseudocode):
>
> scriptSig:<sigs> <either the code for This or the code for That>
> scriptPuKey:
> IF<hash of code> EQUALS hash of This or hash of That:
> EVAL
> ELSE
> fail validation
> ENDIF
>
> That can be done with CODESEPARATOR/CODEHASH.
>
> But if you want to then bundle that up so the scriptPubKey is a
> standard 'pay to script', you get:
>
> scriptSig:<sigs> <either the code for This or the code for That>
> <serialized IF... code from above>
> scriptPubKey: ... standard DUP HASH160<> EQUALVERIFY EVAL
>
> To be backwards compatible with old clients the scriptSig would have to be:
>
> <hash1> <hash2> <sigs> CODESEPARATOR this_or_that_code
> CODEHASH
> CODESEPARATOR
> IF<hash of code> does not equal hash2:
> fail verification
> ENDIF
>
> That could only be done if the definition of CODEHASH was modified to
> hash only the stuff between CODESEPARATORS instead of hashing from
> CODESEPARATOR to the end of the scriptSig.
>
> RE: static analysis:
>
>> Yes, but maybe there is other static analysis miners may want to do. I
>> can't imagine every scenario.
> The vast majority of miners are "discouraging" (not relaying or
> putting into blocks) anything besides 'standard' transaction types.
>
> Until somebody smarter than me (like Russell) has done a deep analysis
> of Script and all of its opcodes, I don't think that should change.
> The standard transaction types are easy to reason about, and the
> standard types extended with OP_EVAL are also easy to reason about--
> you can template-match them to find out how many ECDSA operations a
> CHECKMULTISIG will do, etc.
>
> Again, in practice, I don't think EVAL as proposed is a danger.
>
> RE: delaying EVAL rollout: I could live with rolling out just BIP 11
> (up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and
> delaying EVAL rollout on the main network, but I worry that will just
> encourage people to delay thoroughly reviewing/testing for a couple of
> months, and we'll be right back here at the beginning of March.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111229/6e7f0034/attachment.html>

2023-06-07 02:49:59

- reply

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

2023-06-07 02:45:39

- reply

📅 Original date posted:2011-12-13
🗒️ Summary of this message: Using Namecoin as a decentralized DNS alternative is suggested due to its ability to transfer/trade names securely and share mining without bloating the Bitcoin block chain.
📝 Original message:>> Would it be too strange to use namecoin?
> This has the same problem as FirstBits, except .bit domains are dirt cheap,
> whereas vanitygen at least slows down grabbing all the common words...
Grabbing is no more an issue than mining Bitcoins is an issue. Sure,
domain grabbers will have the domains first, but they want to profit and
therefore are willing to sell them for whatever price they can get. Just
like the trading of any other limited resource, this process sounds like
somebody is getting rich for nothing, but it does tend to put the
limited resources to good use as people who waste good domains can't
afford them in the long run. The problem with Firstbits is that the
names already grabbed have fixed private keys that are known by their
originators. That makes the names untradable. This may be fixable with
split keys, but a lot of "good" 1firstbits are already made useless in
this way.
Names in Namecoin can be transferred/traded securely, strong
cryptography is built in and it shares mining without bloating the
Bitcoin block chain. I see it as a decentralized DNS alternative at a
time when domain seizures are on the rise, even absent any court order.
So I would use one of the DNS-based solutions that Amir suggested and
simply require standard-compliant clients to be able to look up .bit
(i.e. Namecoin) domains as well. That way we have a pragmatic solution,
but one that also provides security and true decentralization for the
more paranoid of our users.
On 12/13/2011 12:41 AM, Luke-Jr wrote:
> On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote:
>> Would it be too strange to use namecoin?
> This has the same problem as FirstBits, except .bit domains are dirt cheap,
> whereas vanitygen at least slows down grabbing all the common words...
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02:42:51

- reply

📅 Original date posted:2011-12-08
🗒️ Summary of this message: A proposal to include the hash of the block a transaction wants to appear after to prevent transaction reversals and ensure secure withdrawals. Hosted wallets should keep each account as separate public keys for better risk isolation.
📝 Original message:Hey Andy,
Bitcoin already does something which in practice has exactly this
effect: If a transaction is reversed, any transactions based on its
outputs are rejected.
Hosted wallets can make use of this - but as you correctly point out,
depending on the service, it can get tricky. What if I exchange the
money to USD and back before withdrawing? You could have an algorithm
where MtGox prefers to spend outputs from your own deposits as the
inputs for your withdrawals, it's not trivial though and never 100% secure.
I have trouble thinking of a good example where you need an explicit
block dependency as you describe. The only times you'd want to use this
dependency of transactions on specific previous transactions is when you
can clearly and easily associate the money. But if you can clearly and
easily associate the money, you might as well just relate the
transactions (use the outputs from the deposit transaction as the inputs
of the withdrawal transaction.)
This is btw something that would strongly agree with: Hosted wallets
should absolutely keep each account as separate public keys. With that
you lose free and instant internal transactions, but you gain instant
deposits and much better risk isolation.
This is just my view. Thanks and keep the thought-provoking stuff coming!
Cheers,
Stefan
On 12/8/2011 11:47 AM, Andy Parkins wrote:
> Hello,
>
> Another of my crazy ideas:
>
> When a transaction is first broadcast, it should include the hash of the block
> it wants to appear after, let's call it's basis block. That block can be
> anything the claimer wants; but it allows the miners to add this condition:
> the transactions outputs a new transaction claims must be before the new
> transaction's basis block.
>
> Consider this block chain fork:
>
> * -- * -- F -- * -- 1 -- 4 -- 5
> \
> * -- 2 -- 3
>
> Let's say in block 2; I transfer coins from address A to Mt.Gox (or any other
> pooled-account online wallet). In block 1 I transfer credit from address A to
> address B. In block 3 I transfer credit from Mt.Gox's pool to address B.
>
> The chain at 3 races out first, but eventually the chain at 5 becomes "the
> one". If Mt.Gox are foolish enough to broadcast my withdrawl in 3; there is
> nothing to stop that same withdrawl making it into 4 (since it comes from a
> pooled fund address). Therefore Mt.Gox can't allow such a fast turnaround and
> must wait for six confirmations of 2 before allowing use of the funds. That
> is an inconvenience for all the honest users.
>
> With my proposed change, the Mt.Gox transaction broadcast at 3 would include
> "block 2" as its basis block. Therefore that transaction could never make it
> into block 4, as no miner will include a transaction based on block 2 in the
> block 4 chain.
>
> Mt.Gox is probably not a good example, as they have problems with fiat to deal
> with too. However, for other online wallet accounts it would allow faster
> acceptance of received funds, since there is no danger of loss should an
> attacker arrange a reorganisation.
>
> This basis block would be optional (implied by the input transactions if it
> isn't present); and would only need storing for the pending transactions, so
> no incompatible change is needed to the block format.
>
>
>
> Andy

2023-06-07 02:39:32

- reply

📅 Original date posted:2011-11-14
🗒️ Summary of this message: Unable to provide a summary as there is no text provided. The attachment is an HTML file.
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111114/f5f219de/attachment.html>

2023-06-07 02:36:16

- reply

📅 Original date posted:2011-10-27
🗒️ Summary of this message: The Bitcoin community discusses using Git as a backup for important information, such as BIPs, due to the unreliability of the wiki.
📝 Original message:+1 for something based on git. Github has a dedicated wiki feature that
is git-backed:
https://github.com/bitcoinjs/node-bitcoin-p2p/wiki/
git://github.com/bitcoinjs/node-bitcoin-p2p.wiki.git
On 10/27/2011 6:15 PM, Daniel F wrote:
> +1 on git. not necessarily as replacement, but at least as backup.
> could possibly use markdown and github pages, which automagically
> pushes git commits out to the website (uses markdown syntax, iirc)
>
> On Thu, Oct 27, 2011 at 11:22 AM, Nils Schneider<nils at nilsschneider.net> wrote:
>> Can we use a git repo or something more redundant for BIPs? They're
>> rather important and the wiki has been unreliable before.
>>
>> On 27.10.2011 17:15, Amir Taaki wrote:
>>> 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.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The demand for IT networking professionals continues to grow, and the
>>> demand for specialized networking skills is growing even more rapidly.
>>> Take a complimentary Learning at Cisco Self-Assessment and learn
>>> about Cisco certifications, training, and career opportunities.
>>> http://p.sf.net/sfu/cisco-dev2dev
>>>
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>> ------------------------------------------------------------------------------
>> The demand for IT networking professionals continues to grow, and the
>> demand for specialized networking skills is growing even more rapidly.
>> Take a complimentary Learning at Cisco Self-Assessment and learn
>> about Cisco certifications, training, and career opportunities.
>> http://p.sf.net/sfu/cisco-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning at Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02:30:10

- reply

📅 Original date posted:2011-09-29
🗒️ Summary of this message: BitcoinJS plans to remove dependencies on cryptopp and use OpenSSL to calculate midstate, which is currently redundant and easily calculable.
📝 Original message:BitcoinJS uses OpenSSL to calculate midstate:
https://github.com/bitcoinjs/node-bitcoin-p2p/blob/master/native.cc#L380
On 9/29/2011 1:40 PM, Nils Schneider wrote:
> Yes, that's possible and what
> https://github.com/bitcoin/bitcoin/pull/535 does. However, deprecating
> midstate (and hash1) would allow for much cleaner code.
>
> A pull request for marking midstate (and hash1) as deprecated can be
> found at https://github.com/bitcoin/bitcoin/pull/538
>
> On 29.09.2011 12:23, John Smith wrote:
>> Nils,
>>
>> Sounds good. I'm also doubtful of depending on two crypto libraries when
>> OpenSSL does perfectly well.
>>
>> However, losing compatibility with miners is not very nice. Is there
>> really not a way to compute midstate with OpenSSL?
>>
>> JS
>>
>> On Mon, Sep 26, 2011 at 7:42 PM, Nils Schneider<nils at nilsschneider.net
>> <mailto:nils at nilsschneider.net>> wrote:
>>
>> Hey,
>>
>> I'd like to simplify the internal reference miner and remove all
>> dependencies on cryptopp (it's the only place we use cryptopp instead of
>> OpenSSL).
>>
>> Unfortunately, cryptopp is also used to calculate getwork "midstate".
>> This field is redundant and the miner could easily calculate it from the
>> blockheader so I'd like to remove it.
>>
>> Any thoughts? Where should such a change should be announced so all
>> miners can be upgraded?
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> <mailto:Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02:26:46

- reply

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

2023-06-07 02:12:47

- reply

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

2023-06-07 02:12:21

- reply

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

2023-06-07 02:03:43

- reply

📅 Original date posted:2011-07-08
🗒️ Summary of this message: Bitcoin is standardizing version bytes for different applications, with reserved bits for network, data class, and version number. Testnet may use XOR hack or reset.
📝 Original message:Hey Pieter,
> Otherwise, we could reset testnet (not actually reset, just
> change its addresses a bit), and simply state odd=testnet, even=realnet.
We could use the XOR hack for now and remove it the next time we reset
testnet. But I do think the 111 is baggage we want to get rid of. Using
the lsb as a simple flag is much cleaner.
Cheers,
Stefan
On 7/7/2011 1:15 PM, Pieter Wuille wrote:
> Hello everyone,
>
> after a discussion on IRC, we decided to try to standardize the version bytes
> used by bitcoin for several applications.
>
> There are 3 components that seem meaningful:
> * network? (realnet, testnet, alternate chains?)
> * data class? (address, private key, master key, ...?)
> * version? (real version, per data class defined)
>
> There is no technical reason why different network and different data classes
> would need separate version bytes, but i think it is a good thing to keep
> them from colliding. People will mix them up, and when things are well
> defined, a nice warning message could help a lot ("Oops it seems you entered
> a private key instead of an address!").
>
> So, first of all, there is already one actually used alternate chain, namely
> namecoin, using version byte 52 for addresses. For this reason, i'd like to
> reserve bit 16 in the version byte for "alternate chain". When bit 16 is set,
> everything is up to the network itself, and no further semantics are defined.
>
> When bit 16 isn't set:
>
> Then remains the rest of the network. The problem is that testnet already uses
> version 111, which is not a single bit. We can use a trick though, namely
> choosing bit 1 for testnet, and if bit 1 is set, XOR the rest of the version
> number with 111. Otherwise, we could reset testnet (not actually reset, just
> change its addresses a bit), and simply state odd=testnet, even=realnet.
>
> That leaves use with 6 more bits to play with, namely 128,64,32 and 8,4,2.
> As 128 is already used for private keys, let's use (128,64,32) for data classes,
> and (8,4,2) for versions.
>
> So, in full:
> * Bits 128/64/32 define data class
> ** 0 = address
> ** 32,64,96,160,192 = reserved for future use
> ** 128 = private key
> ** 224 = extended data class, another "data class" byte follows
> * Bit 16 defines "private"
> ** 0 = bitcoin
> ** 16 = alternate chain
> * Bits 8/4/2 define version number
> ** 0 = only thing used for now
> ** 2,4,6,8,10,12 = reserved for future use
> ** 14 = extended version, another version byte follows
> * Bit 1 defines testnet
> ** 0 = realnet
> ** 1 = testnet (possibly using XOR 111, if not reset)
>
> This whole discussion started when Stefan wanted to define a format for master keys from which
> to derive deterministic wallet keys, i suggest using data class 192 for that, leaving the
> lower numbers for more basic data, like public keys.
>
> Any comments?
>