<unnamed>

Public Key

npub1xqshkqv2g7uea4xzqwvmgjcz7u8vfavw6aazs999v0azsv3w7u3qpymc2p

Profile Code

nprofile1qqsrqgtmqx9y0wv76npq8xd5fvp0wrky7k8dw73gzjjk873gxgh0wgspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsqatefq

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:30:42 CEST

- reply

📅 Original date posted:2015-02-20
📝 Original message:Hello Adam,
On Fri, 20 Feb 2015, Adam Back wrote:
> So I was wondering what about changing to committing a bloom filter of
> the addresses in the block. Its seems surprising no one thought of it
> that way before (as it seems obvious when you hear it) but that seems
> to address the privacy issues as the user can fetch the block bloom
> filters and then scan it in complete privacy. (Someone appeared on
> bitcoin wizards IRC a while back and made this observation.)
I have heard this idea of inverting the bloom filter before (possibly in
#bitcoin-wizards), and as I see it it would indeed improve the privacy.
Apart from privacy it would also lower the burden for nodes. A block scan
with bloom filter is effectively a cheap DoS on a node.
In addition to that it will also avoid the 'transaction withholding
attack' that is possible with the current bloom filtering, at least if the
filter is e.g. committed to in the block header.
The drawback would be overhead - the bloom filter per block will have a
significant size (to avoid false positives), and the client would have to
fetch entire blocks that have its transactions in it.
I don't think that is so bad in practice, after all the % of blocks that
will have transactions for a given wallet will generally be low, so the
block size is amortized in a way. Of course, if the block size would be
increased this would become worse.
Wladimir

2023-06-07 17:29:24 CEST

- reply

📅 Original date posted:2015-02-01
📝 Original message:On Sun, 1 Feb 2015, xor wrote:
> Why is that?
v0.9.4 is not really a release, just a tag in git.
It contains merely a workaround for a change in OpenSSL which caused
problems - see Gregory Maxwell's post.
As the releases are statically built against OpenSSL, it is not
necessary to upgrade if you use releases from bitcoin.org. Hence no change
on the site.
(but it can be used by people building from source, or distributions
packages such as the Ubuntu PPA, which unwisely dynamically link OpenSSL)
> Also, is it correct that there wasn't a release candidate before the release?
> Sounds dangerous to me.
Again, there hasn't been any 0.9.4 release, neither a release candidate or
anything else.
Testing and such should be focused on the 0.10 release candidates.
Wladimir

2023-06-07 17:28:40 CEST

- reply

📅 Original date posted:2015-01-28
📝 Original message:On Wed, 28 Jan 2015, Nicolas DORIER wrote:
> I agree that the use protocol buffer and x509 by BIP70 is a poor choice.
Well x509 is an international standard in common use, you can't do much
better with regard to portability. Your suggestion about HTTPS makes
little sense, you do know what TLS uses x509 internally as well?
Re: protocol buffers, I don't know if it's the best possible one, but one
serialization method had to be picked. If it weren't, we could still have
still been discussing which one to use by now. Just like for JSON there
are bindings for many languages.
Though JSON parsers are much more diverse, which people using Bitcoin
Core's RPC have bumped into e.g. some have some problems
handling large numbers. Something you wouldn't expect using a
straightforward binary format. There's no obvious best choice.
Wladimir

2023-06-07 17:27:44 CEST

- reply

📅 Original date posted:2014-12-10
📝 Original message:On Wed, Dec 10, 2014 at 6:47 AM, Wladimir <laanwj at gmail.com> wrote:
> Abbreviations:
>
> Concept ACK -> agree with the idea and overall direction, but haven't
> reviewed the code changes nor tested it
> utACK -> reviewed the code changes, but did not put it through any testing
> Tested ACK -> reviewed the code changes and verified the functionality/bug fix
And there is also NACK, that's an aspecific 'I wouldn't like this
merged'. I always explain why in the text.
A document on this would be welcome, as it may look like Martian to
outsiders. That's been brought up many times before, but no one ever
created it.
Wladimir

2023-06-07 17:27:44 CEST

- reply

📅 Original date posted:2014-12-10
📝 Original message:Abbreviations:
Concept ACK -> agree with the idea and overall direction, but haven't
reviewed the code changes nor tested it
utACK -> reviewed the code changes, but did not put it through any testing
Tested ACK -> reviewed the code changes and verified the functionality/bug fix
I tend to only use bare "ACK" if there is nothing to test in the first
place, for example for documentation changes.
Wladimir
On Tue, Dec 9, 2014 at 9:30 PM, Matt Corallo <bitcoin-list at bluematt.me> wrote:
> Also utACK ("untested ack") and "tested ack" when people are being explicit.
>
> On 12/09/14 21:14, Sergio Lerner wrote:
>> Is that the full terminology or are there more acronyms?
>> Is this documented somewhere?
>>
>> Best regards,
>> Sergio.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:26:29 CEST

- reply

📅 Original date posted:2014-10-15
📝 Original message:Hello,
I'm trying to create a bit of process around the
https://github.com/bitcoin/bips repository.
A) Currently a lot of pulls are open for various BIPs and it is not
clear who should comment on them, or who decides on changes to be
merged.
Currently all BIP changes have to go through the Bitcoin Core team,
which is a narrow bottleneck and makes little sense when you think
about it. But I don't want to go back to the wiki state in which
everyone can make arbitrary changes to any BIP - we need to distribute
the process somehow.
I'd like to propose to make the author (or someone they delegate to)
the primary contact for each BIP. They should comment on changes, and
either accept or reject them. If they accept them, the change will be
merged.
Of course this means that there is a responsibility for the author to
adhere to BIP 1. For example if your BIP is final, don't allow any
technical changes. To do small clarifications, spelling or adding
implementations or examples is OK, but changing or adding to a
protocol is not - this needs a new BIP. Changing your BIP status
without community consensus is also not OK.
B) I also think it makes sense to move the BIP discussion (both about
the BIP process and individual BIPs) to a separate mailing list.
bitcoin-development currently has a dual function: discussion of
Bitcoin Core implementation concerns, as well as global changes to
Bitcoin (in the form of BIPs).
This makes the list too busy for some people, but it is critical that
everyone writing a Bitcoin node or client is up-to-date with proposals
and can comment on them.
Wladimir

2023-06-07 17:26:29 CEST

- reply

📅 Original date posted:2014-10-15
📝 Original message:> This all makes a lot of sense to me, and would help a lot with the
> workflow. Unfortunately github pulls and issues really have nothing
> to faciltate a multistage workflow... e.g. where something can go
> through several steps.
Indeed, pull requests don't have a "status".
It would be possible to (ab)use labels for this.
The drawback of labels is that only the repository team can set these,
there is no way to delegate. But I suppose it'd be possible to build
something on top of the github API that handles this.
> We're also having problems with people failing to comment on things,
> not even "I looked at this and have no opinion", which is really
> obstructing things.
Well - the only way to avoid that is to set a reasonable deadline,
after which there is a default decision. You'd hope this would
motivate people to get involved in time.
Wladimir

2023-06-07 17:25:40 CEST

- reply

📅 Original date posted:2014-09-12
📝 Original message:On Fri, Sep 12, 2014 at 11:29 AM, Andreas Schildbach
<andreas at schildbach.de> wrote:
> This is the discussion post corresponding to this PR:
> https://github.com/bitcoin/bips/pull/106
>
> "Amend BIP72 by an "h" parameter, which contains a hash of the
> PaymentRequest message that is fetched via the "r" parameter.
>
> The hash is meant to link the trust anchor (e.g. the QR code) to the
> payment request message in a secure way. This will solve the problem
> several apps are comparing address+amount fields as a workaround
> instead, preventing some advanced BIP70 usecases. When these apps read a
> matching hash, they need not compare any of the other fields.
Sounds like a good idea to me.
I had no idea that some clients were comparing addresses and amounts
in the URI with the payment request for security, that seems like a
hacky and inflexible way. This is much better.
Wladimir

2023-06-07 17:25:28 CEST

- reply

📅 Original date posted:2014-08-19
📝 Original message:On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> It would be nice if the issues and git repo for Bitcoin Core were not
> on such a centralized service as github, nice and convenient as it is.
Despite my complaining about github, I don't like the idea of moving
somewhere else. The current way of working - to use github for storing
the tree, and use a custom script for signing+merging - is fine with
me.
Github has a low barrier to contribution. Almost every open source
developer already has a github account. Switching to something
self-hosted makes it more difficult for people to contribute.
Plus if we have to take the hosting upon ourselves, we have to handle
sysadmin work ourselves as well. That's not a good use of the limited
manpower available.
Also it will be a lot of work to migrate over all the current issues
and pulls. I don't look forward to that. I don't see the point of
this, sorry.
Wladimir

2023-06-07 17:25:28 CEST

- reply

📅 Original date posted:2014-08-20
📝 Original message:On Wed, Aug 20, 2014 at 3:26 AM, Troy Benjegerdes <hozer at hozed.org> wrote:
> If bitcoin wants to become irrelevant, then by all means, continue to
> depend on github and all the unknown attack surface it exposes.
>
> Those of us that do run our own servers will migrate to higher quality
> alternatives.
So that means you're volunteering to run a web-accessible mirror of
the bitcoin repositories?
Wladimir

2023-06-07 17:24:14 CEST

- reply

📅 Original date posted:2014-07-18
📝 Original message:On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn <mike at plan99.net> wrote:
> The rationale doesn't seem to apply to rule #4, what's so special about that
> one?
> 4. Non-push operations in scriptSig Any non-push operation in a scriptSig invalidates it.
Having non-push operations in the scriptSig is a source of
malleability, as there can be multiple sequences of opcodes that
evaluate to the same result.
Wladimir

2023-06-07 17:23:44 CEST

- reply

📅 Original date posted:2014-07-15
📝 Original message:On Tue, Jul 15, 2014 at 10:00 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Proxying another's idea, from CoinSummit.
>
> The request: It would be useful to limit the lifetime of a bitcoin
> address. Intentionally prevent (somehow) bitcoins being sent to a
> pubkey/pkh after the key expires.
Payment request expiration was meant to address this.
Adding an optional expiration timestamp to addresses would be
possible, however, it would be a non-backward-compatible change and
lots of software would have to be changed at this point.
In my opinion encouraging the use of the payment protocol and
deprecating the use of addresses is the best way forward, and not just
for this reason.
Wladimir

2023-06-07 17:23:32 CEST

- reply

📅 Original date posted:2014-07-04
📝 Original message:On Wed, Jun 11, 2014 at 5:39 PM, Wladimir <laanwj at gmail.com> wrote:
> If no one screams fire, we plan on removing support for it in the next
> major release, for two reasons:
>
> - It would remove some crufty, hardly tested code paths
>
> - SOCKS5 offers better privacy as it allows DNS redirection
Another one:
- SOCKS5 supports IPv6
Last call...
Wladimir

2023-06-07 17:22:16 CEST

- reply

📅 Original date posted:2014-06-04
📝 Original message:>
>
> assert() should have *no* side effects, that is the problem.
>>
>
I'm pretty sure that all the side effects of assertions have been removed
before 0.9.0.
However, the assertion checks are extremely important to the proper sanity
of the client and network, so IMHO it's fair to still require building with
them enabled.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140604/49578ca3/attachment.html>

2023-06-07 17:21:55 CEST

- reply

📅 Original date posted:2014-05-23
📝 Original message:On Thu, May 22, 2014 at 8:06 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Related: Current multi-sig wallet technology being rolled out now,
> with 2FA and other fancy doodads, is now arguably more secure than my
> PGP keyring. My PGP keyring is, to draw an analogy, a non-multisig
> wallet (set of keys), with all the associated theft/data
> destruction/backup risks.
>
> The more improvements I see in bitcoin wallets, the more antiquated my
> PGP keyring appears. Zero concept of multisig. The PGP keyring
> compromise process is rarely exercised. 2FA is lacking. At least
> offline signing works well. Mostly.
Would be incredible to have multisig for git commits as well. I don't
think git supports multiple signers for one commit at this point -
amending the signature replaces the last one - but it would allow for
some interesting multi-factor designs in which the damage when a dev's
computer is compromised would be reduced.
Sounds like a lot of work to get a good workflow there, though.
My mail about single-signing commits was already longer than I
expected when I started writing there. Even though the process is
really simple.
Though if anyone's interest is piqued by this, please pick it up.
Wladimir

2023-06-07 17:21:54 CEST

- reply

📅 Original date posted:2014-05-21
📝 Original message:Hello Chris,
On Wed, May 21, 2014 at 6:39 PM, Chris Beams <chris at beams.io> wrote:
> I'm personally happy to comply with this for any future commits, but wonder
> if you've considered the arguments against commit signing [1]? Note
> especially the reference therein to Linus' original negative opinion on
> signed commits [2].
Yes, I've read it. But would his alternative, signing tags, really
help us more here? How would that work? How would we have to structure
the process?
At least signed commits are easy to integrate into the current
development process with github - only a different way of merging has
to be used.
> I came across these when searching for a way to enable signing by default,
> e.g. a `git config` option that might allow for this. Unfortunately, there
> isn't one, meaning it's likely that most folks will forget to do this most
> of the time.
I'll remind people if they forget to do it, but I won't require it. As
you say, that would be an extra barrier, and I'm not suggesting this
because I to see people jumping through bureaucratic hoops.
But it is a pretty simple thing to do...
> If you're really serious about it, you should probably reject pull requests
> without signed commits; otherwise, signing becomes meaningless because only
> honest authors do it, and forgetful or malicious ones can avoid it without
> penalty.
This is not because I'm afraid of malicious authors, but because I
want to reduce the risk that github hacks would pose.
Something to watch for would be authors that normally sign pull
requests/merges and suddenly don't. Someone malicious may have gained
access to their github account. This just adds an extra layer of
protection.
Cheers,
Wladimir

2023-06-07 17:21:52 CEST

- reply

📅 Original date posted:2014-05-21
📝 Original message:Hello all,
When you're contributing to Bitcoin Core development please sign your
git commits. This is easy to do and will help in assuring the
integrity of the tree.
How to sign your commits?
------------------------------------------
Provide the `-S` flag (or `--gpg-sign`) to git commit when you commit
your changes, for example
git commit -m "Commit message" -S
Optionally you can provide a key id after the -S option to sign with a
specific key.
What if I forgot?
-------------------------
You can retroactively sign your previous commit using --amend, for example
git commit -S --amend
If you need to go further back, you can use the interactive rebase
command with 'edit'. Replace HEAD~3 with the base commit from which
you want to start.
git rebase -i HEAD~3
Replace 'pick' by 'edit' for the commit that you want to sign and the
rebasing will stop after that commit. Then you can amend the commit as
above. Afterwards, do
git rebase --continue
As this will rewrite history, you cannot do this when your commit is
already merged. In that case, too bad, better luck next time.
If you rewrite history for another reason - for example when squashing
commits - make sure that you re-sign as the signatures will be lost.
How to check if commits are signed?
-------------------------------------------------------
Use git log with show-signature,
git log --show-signature
commit 6fcdad787f1fb381a3a0fe6b1a1e45477426dccb
gpg: Signature made Wed 21 May 2014 12:27:55 PM CEST using RSA key
ID 2346C9A6
gpg: Good signature from "Wladimir J. van der Laan <laanwj at gmail.com>"
Author: Wladimir J. van der Laan <laanwj at gmail.com>
Date: Wed May 21 12:27:37 2014 +0200
qt: Periodic language update
...
You can also pass the --show-signature option to `git show` to check a
single commit.
If you do this on the current repository you'll see that I'm almost
the only person signing commits. I would like more people to get into
this habit.
How to sign merges?
--------------------------------
When using the github interface to merge a pull request, the resulting
merge commit is not signed.
Pieter Wullie wrote a script that simplifies merging and signing. It
can be found in contrib/devtools. Setup instructions can be found in
the README.md in that directory. After setting it up for the
repository you can use the script in the following way:
contrib/devtools/github-merge.sh 1234
Replace 1234 by the pull request number that you want to merge. It
will merge the pull request and drop you into a shell so you can
verify changes and test. Once satisfied, exit the shell and answer the
questions to merge and sign it and push upstream automatically (or
not).
Please use this script when possible for merging instead of the github
interface.
--------------------------
Wladimir

2023-06-07 17:21:46 CEST

- reply

📅 Original date posted:2014-05-19
📝 Original message:On Mon, May 19, 2014 at 11:26 AM, Bjørn Øivind Bjørnsen
<bo.bjornsen at gmail.com> wrote:
> On 18/05/14 19:43, Raúl Martínez wrote:
>> <snip some good ideas>
>
> As an interested party not intimately familiar with the bitcoin codebase
> who also spent some time setting up a node a while ago, I would like to
> add one thing to the above list - network rate limiting.
There is already an (old) patch that implements that. It won't be
merged, though, until headers-first and parallel block download is in.
Only when the node can download blocks from multiple peers at once it
is really safe to allow limiting rates.
(sure - there are tricks to limit rates anyway, like the script in
contrib/qos, but to have it generally available the block download
needs to be more robust first)
Wladimir

2023-06-07 17:21:44 CEST

- reply

📅 Original date posted:2014-05-19
📝 Original message:On Sun, May 18, 2014 at 7:43 PM, Raúl Martínez <rme at i-rme.es> wrote:
> About the small number of bitcoin nodes:
> Hi, I read the message that Mike Hearn sent to this mailing list some days
> ago (2014-04-07 11:34:43) related to the number of bitcoin full nodes.
>
> As an owner of two Bitcoin Nodes, one in my home computer and one in a
> dedicated server, I believe I can contribute with some of my thoughts and
> ideas:
>
> - Allow users to view the bandwith used by Bitcoin Core:
> This is available in the Bitcoin Core GUI (btw, when the computer is
> restarted the data gets reseted) but I cant find it in the bitcoind
> commandline
That's also possible through the RPC. See "getnettotals". You can also
get stats per peer in "getpeerinfo".
I also suggest looking at Jameson Lopp's Statoshi work
(http://statoshi.info) if you like graphs and more detailed stats.
> - Educate users about the correct setup of a bitcoin node:
> Add a page in the bitcoin.org website with a tutorial about running Bitcoin
> Core with the ports opened, about runing bitcoind, etc. This guide shoud not
> be for regular users but for advanced ones.
Yes, such a document would be very welcome.
Maybe coordinate with Saïvann Carignan or David Harding, it could be
part of their bitcoin documentation project.
> - bitcoind and Bitcoin Core should create a bitcoin.conf file on the first
> start:
> The first time the software should create a default config file with a
> random RCP password and username (user can change it later) and the config
> file should be commented so the user can know how to change configurations.
> This is very useful in setups without GUI, for example in Ubuntu Server.
I agree with you that a default configuration file is useful,
*however* this does not need to be created by the daemon.
The idea would be to make bitcoind and its data and configuration
system-wide. See https://github.com/bitcoin/bitcoin/issues/4124
A daemon should not even have write access to its own configuration
files. To follow the example of apache, tor, and such the distribution
installs a default configuration file which the user can adapt.
> - bitcoind and Bitcoin Core should be in Linux repos:
> People want to type "yum install bitcoind" or "apt-get install bitcoind" and
> install bitcoin. No one wants to follow a tutorial made by somewho saying
> that you have to add external repos to install bitcoin in your server.
> For example Electrum has been added to Ubuntu software center recently.
> Bitcoin Core an bitcoind should be on CentOS, Debian, Ubuntu and Ubuntu
> Server repos.
This sounds good, but as usual the practice is much uglier.
Bitcoind was part of the Ubuntu default repos for a while, but they
don't upgrade versions as we need to. This resulted in Ubuntu 12.04
stable being stuck with 0.3.xx forever. It would be even worse for
Debian Stable, which has even older versions of packages.
So right now we need you to add the PPA to get the package for Ubuntu.
This is only a small extra step.
This has to be determined per distribution, though. In some distros
this may be perfectly possible. This is just another place where the
project is completely dependent on volunteers.
> - Create a "grafical interface" for bitcoind on Linux servers:
> Create a command, for example "bitcoind show" that shows a nice summary in
> your Terminal (Console) with all the data that a node administrator wants to
> know.
> When I say "grafical interface" I mean like "top" command, an interface made
> out of characters in ASCII.
Sounds like a fun project for someone in Python. Most of the
information is already available through RPC (and if not, request
it!).
Some hacking with ncurses could quickly make a decent tool here. It
could be packaged with bitcoin itself but that's not necessary. For
example Tor has the tool 'arm' which is a separate package.
You may want to talk with Shawn Wilkinson he has some ideas in this
direction. See also the issue
https://github.com/bitcoin/bitcoin/issues/3122 .
> - Split Bitcoin Wallet from Bitcoin Node:
> I believe that this is planned, some people want to help the network and
> others want to keep a wallet, someones want both.
> With bitcoind you can use the option "disablewallet=1" that allows to save
> some memory.
Running the node without wallet is already possible since 0.9.0 in two ways:
- ./configure --disable-wallet when compiling
- run with -disablewallet (as you say)
This works both for the GUI and the daemon. You can use the resulting
node-only instance ("edge router") with any existing SPV wallet.
There are plans to split off the wallet so that it can run separately,
but I wouldn't be holding my breath.
It feels to me that the general direction things are going in is that
other wallet projects are advancing much faster than Bitcoin Core's
wallet and people will likely switch to other wallet projects for
wallet functionality. Bitcoin Core is moving to an edge router role.
I'm happy to be proven wrong here and would like to see someone work
on bitcoind's wallet, but with the current development resources we
have to focus on a what is most urgent: maintaining and improving the
infrastructure.
> - Inform users if 8333 port is closed:
> That should be more visible, I dont mean an alert or warning but some icon.
Yes, it would be great of connectivity and proxy problems were
signaled in some way.
Detecting whether your port is closed from the outside is an imprecise
art at most, though, as it relies on information from others.
A first step could be showing the number of incoming and outgoing
connections separately in getnetworkinfo. If you have no incoming
connections after a while you can be fairly sure that there is no
outward connectivity.
> - Keep connections if bitcoind is restarted:
> I noticed that if I restart bitcoind (to apply new config) my reset to 0 and
> take some hours to rise up to ~40. I believe that my peers should notice
> that I am down for less than ~15 minutes and try to connect again faster.
What incentive do peers have to reconnect to you specifically? The
nature of a P2P network is that nodes are interchangeable. If a node
fails or kicks them, they'll just try the next node in the list.
Sometimes that will be you, sometimes it will not.
Wladimir

2023-06-07 17:21:07 CEST

- reply

📅 Original date posted:2014-05-08
📝 Original message:On Wed, May 7, 2014 at 10:28 PM, Nelson Castillo
> Is SNMP an option? That way you do not need to implement clients and there
> are many tools written.
It's always good to use an existing standard, but I remember SNMP,
even on a client device/application is pretty complex in itself.
And I suppose the registration for custom OIDs and such is kind of baroque.
I'm not entirely convinced of what the added value in this case would
be. Yes, there are tools for monitoring SNMP, but in my experience
those tools usually support other ways of collecting statistics as
well.
Wladimir

2023-06-07 17:21:06 CEST

- reply

📅 Original date posted:2014-05-07
📝 Original message:On Wed, May 7, 2014 at 10:25 PM, Mike Hearn <mike at plan99.net> wrote:
> Another is to export stats over regular TCP and make them public so
> literally anyone can listen to the stats feed for any node.
TOR does this as well: http://torstatus.blutmagie.de/
No idea what they use to submit/gather the statistics.
Wladimir

2023-06-07 17:21:04 CEST

- reply

📅 Original date posted:2014-05-07
📝 Original message:On Wed, May 7, 2014 at 9:12 PM, Jameson Lopp <jameson.lopp at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In order to gain more insight into what messages and requests a node is processing, I've created a Bitcoin Core fork that outputs statistics to StatsD. I hope that some of you will find this interesting and potentially useful.
>
> http://coinchomp.com/2014/05/07/announcing-statoshi-realtime-bitcoin-node-statistics/
>
> https://jlopp.github.io/statoshi/
>
> Feedback is appreciated!
Ooh nice graphs!
We were coincidentally talking about showing stats from a node on a
local web site on the #bitcoin-dev IRC a few days ago.
At some point, if we're going to offer Bitcoin Core node-only
installers, it'd be nice to include something like this so the user
can keep an eye on their node(s).
Wladimir

2023-06-07 17:19:19 CEST

- reply

📅 Original date posted:2014-04-24
📝 Original message:On Thu, Apr 24, 2014 at 10:02 AM, Wladimir <laanwj at gmail.com> wrote:
> On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <wtogami at gmail.com> wrote:
>>> If you are
> > Another option: Instead of statically building it'd be easy enough to
> build against the 4.6 Qt headers instead without even swapping the
> library. Qt is, after all, forward-compatible - between the 4.x
> versions. This will lose some GUI features but if compatibility is
> more important here that's a choice that can be made.
Are you sure this is Qt 4.6 at all? Not Qt 4.7?
I'd expect *much* more symbols if this was a Qt 4.8 versus 4.6
conflict. Qt 4.7 introduced a lot of new things (see all the
occurences of #if QT_VERSION >= 0x040700 - things like
setPlaceHolderText would be expected to pop up too), but 4.8 did not.
Can you check?
Wladimir

2023-06-07 17:19:19 CEST

- reply

📅 Original date posted:2014-04-24
📝 Original message:On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <wtogami at gmail.com> wrote:
>> If you are
>> a rare user who needs Bitcoin-Qt on an incompatible system you can at least
>> build it from source.
>
> Tails users usually can't really build it from source— talks is a live
> boot mostly stateless linux distribution for privacy applications.
> It's really good in general.
Aside: But is Bitcoin Core a well-suited application for those uses? I
cannot imagine someone running a full node on a stateless system.
Anyhow: As this is only one symbol, we can probably get rid of it (as
we didn't use it in 0.8.6?), or put it behind some #ifdef
COMPATIBILITY_BUILD...
Another option: Instead of statically building it'd be easy enough to
build against the 4.6 Qt headers instead without even swapping the
library. Qt is, after all, forward-compatible - between the 4.x
versions. This will lose some GUI features but if compatibility is
more important here that's a choice that can be made.
Wladimir

2023-06-07 17:19:18 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:> I see that the latest nightly build (thanks for that, Warren) is still not
> compatible with Tails/Debian Squeeze. Is there still an intention to address
> this issue? Might it be fixed by 0.9.2?
Can you be more specific as to what problem you're having?
Wladimir

2023-06-07 17:18:56 CEST

- reply

📅 Original date posted:2014-04-20
📝 Original message:On Sun, Apr 20, 2014 at 6:19 PM, Chris Pacia <ctpacia at gmail.com> wrote:
> The term bit is really only overloaded for those who are techy. 95% of the
> population never uses the term bit in their daily lives and I doubt most
> could even name one use of the term.
> Plus bit used to be a unit of money way back when, so this is kind of
> reclaiming it. I think it's a great fit.
That's a very anglocentric way of thinking.
Here in the Netherlands, a "bit" is something you put in a horses's
mouth. It's also used as imported word (in the information sense).
We've never used the term for money.
Wladimir

2023-06-07 17:18:26 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:On Wed, Apr 9, 2014 at 7:33 PM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
> 1) It's more private. Bloom filters gives away quite accurate statistical
>> information about what coins you own to whom ever you happen to be
>> connected too. An attacker can easily use this to deanonymize you even if
>> you don't reuse addresses; Tor does not help much against this attack.
>>
>
> There is also an option to download everything, but do only a very basic
> surface validation (without keeping track of UTXOs).
> You do not need a full node for that.
>
You may not *need* a full node, but the point of this (which I clearly
explained in my opening post) would be to support the network.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/6371ea18/attachment.html>

2023-06-07 17:18:22 CEST

- reply

📅 Original date posted:2014-04-10
📝 Original message:On Thu, Apr 10, 2014 at 8:38 AM, Mike Hearn <mike at plan99.net> wrote:
> I tend to agree with slush here - counting the IPs in addr broadcasts
> often gives a number like 100,000 vs just 10,000 for actually reachable
> nodes (or less). It seems like optimising the NAT tunneling code would
> help. Starting by adding more diagnostic stuff to the GUI. STUN support may
> also help.
>
> The main constraint with home devices is not IMHO their actual power but
> rather that a lot of people no longer keep computers switched on all the
> time. If you don't do that then spv with bundled Core can't help your
> security because the spv wallet would always be syncing from the p2p
> network for performance reasons.
>
I agree that there is a fundamental incompatibility in usage between
wallets and nodes. Wallets need to be online as little as possible, nodes
need to online as much as possible.
However, a full node background process could also be running if the wallet
is not open itself. Ffor example - by running as a system service.
Bitcoin Core's own wallet is also moving to SPV, so this means a general
solution is needed to get people to run a node when the wallet is not
running.
Maybe the node shouldn't be controlled from the wallet at all, it could be
a 'node control' user interface on its own (this is what -disablewallet
does currently). In this case, there is no need for packaging it with a
wallet The only drawback would be that initially, people wouldn't know why
or when to install this, hence my suggestion to pack it with wallets...
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/edc08ddf/attachment.html>

2023-06-07 17:18:20 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:On Wed, Apr 9, 2014 at 10:12 PM, slush <slush at centrum.cz> wrote:
> Maybe there're other ideas how to improve current situation without needs
> of reworking the architecture.
>
Nothing I've proposed here would require larger changes to the architecture
then were already planned. After SPV lands we are going to split off the
wallet, and that will need an interface to an bitcoind to allow 'running
with full node'. If that can be generalized to be useful for other (SPV)
clients as well, that would be useful, hence I asked for input.
It of course doesn't preclude also looking for other solutions.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/eb8737dd/attachment.html>

2023-06-07 17:18:17 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:On Wed, Apr 9, 2014 at 8:35 PM, Justus Ranvier <justusranvier at gmail.com>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/09/2014 06:19 PM, Wladimir wrote:
> > If no one wants to volunteer resources to support the network
> > anymore, we'll have failed.
>
> If the security of the network depends on a broken incentive model,
> then fix the design of the network so that economics works for you
> instead of against you.
>
My solution would be quick to implement and could help increase the number
of nodes in the short term. It will also smooth the way towards splitting
off the wallet from Bitcoin Core, by giving people a choice what wallet
they use with their full node.
That doesn't preclude looking for longer-term solutions that change the
incentive structure, but that is much more difficult and risky. I don't
believe it's a matter of 'fixing that instead' in a few hours, though I
nevertheless look forward to your pull request.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/b71b8fa0/attachment.html>

2023-06-07 17:18:16 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:On Wed, Apr 9, 2014 at 8:00 PM, Mike Hearn <mike at plan99.net> wrote:
> The right way to start with this, if anyone cares, is to add
> instrumentation to existing SPV wallet apps to report back to home base how
> long they are running for, how much disk space / RAM they have, and
> possibly what kind of hardware.
>
> I *strongly* suspect that the vast majority of SPV wallets are not left
> running permanently, and run on laptops where battery life is at a premium.
> These people will never want to run full nodes.
>
Bitcoins stands or falls with people running full nodes.
If no one wants to volunteer resources to support the network anymore,
we'll have failed.
Sorry. I don't think it will ever make sense to run full nodes on consumer
> hardware again. Our time is much better spent on optimising so it's cheaper
> for full node operators to run them on cheap virtualised servers.
>
Most consumer hardware is much more powerful than 'cheap virtualized
servers'. More memory, disks are cheap, and at least in the Netherlands
home bandwidth is much cheaper than server bandwidth.
Also: any optimization that helps running on cheap servers will also help
running it on consumer hardware. It's not the one or the other.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/00a9ece0/attachment.html>

2023-06-07 17:18:13 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:On Wed, Apr 9, 2014 at 5:41 PM, Natanael <natanael.l at gmail.com> wrote:
> This could probably be done fairly easily by bundling Stratum (it's
> not just for pools!) and allowing SPV wallets to ask Bitcoind to start
> it (if you don't use it, there's no need to waste the resources), and
> then connect to it. The point of using Stratum is that it already is
> being used by Electrum, and that it might be an easier way to support
> SPV clients than creating a new API in bitcoind for it since Stratum
> itself already relies on bitcoind to provide it's services.
>
Why would a new API be needed? (beside maybe some functionality that would
make it easier to integrate)
P2P should be enough for SPV clients such as BitcoinJ to get access to
(filtered) blocks and transations, and RPC can be used to manage/query the
bitcoind instance. I'm not sure what stratum would add.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/a2914bc4/attachment.html>

2023-06-07 17:18:11 CEST

- reply

📅 Original date posted:2014-04-10
📝 Original message:On Thu, Apr 10, 2014 at 8:04 AM, Tamas Blummer <tamas at bitsofproof.com>wrote:
> Serving headers should be default but storing and serving full blocks
> configurable to ranges, so people can tailor to their bandwith and space
> available.
>
I do agree that it is important.
This does require changes to the P2P protocol, as currently there is no way
for a node to signal that they store only part of the block chain. Also,
clients will have to be modified to take this into account. Right now they
are under the assumption that every full node can send them every
(previous) block.
What would this involve?
Do you know of any previous work towards this?
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/fb3a77bb/attachment.html>

2023-06-07 17:18:11 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:On Wed, Apr 9, 2014 at 6:09 PM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
> Le 09/04/2014 17:54, Gregory Maxwell a écrit :
>
> > Sadly today Electrum requires more than a full node, it requires a
> > number of large additional indexes over what a full node has and
> > pruning is precluded. I don't think that increasing the resource
> > utilization of the node is a good way to go there for the purposes
> > expressed here. (not that electrum couldn't be used here, but not
> > unmodified without the resource usage increasing route)
> >
>
> Electrum uses two large indexes:
>
> address -> utxo
>
> (patricia tree, aka "ultimate blockchain compression", see thread
> started by Alan Reiner in the bitcointalk forum)
>
Thanks for the explanation.
Adding a RPC call for a "address -> utxo" query wouldn't be a big deal. It
has been requested before for other purposes as well, all the better if it
helps for interaction with Electrum.
Spent history would be involve a much larger index, and it's not likely
that will end up in bitcoin
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/4cf070b4/attachment.html>

2023-06-07 17:18:09 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:Hello,
This is primarily aimed at developers of SPV wallets.
The recently reported decrease in number of full nodes could have several
reasons, one of them that less people are running Bitcoin Core for the
wallet because the other wallets are getting ahead in both features and
useability.
It's great to see innovation in wallets, but it's worrying that the number
of full nodes decreases.
It may be that lots of people would support the network by running a full
node, but don't want to go through the trouble of installing bitcoin core
separately (and get confused because it's a wallet, too).
Hence I'd like to explore the idea of adding an option to popular SPV
wallets, to spin a bitcoind process in the background. This could be pretty
much transparent to the user - it would sync in the background, the wallet
could show statistics about the node, but is not dependent on it.
In exchange the user would get increased (full node level) security, as the
SPV wallet would have a local trusted node.
Does this sound like a good idea?
Is there any way that Bitcoin Core can help to accomedate this 'embedded'
usage? Specific Interfaces, special builds - maybe add a walletless
bitcoind build to gitian - bindings, dlls, etc?
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/6673abbe/attachment.html>

2023-06-07 17:17:34 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:On Wed, Apr 9, 2014 at 12:38 PM, Wendell <w at hivewallet.com> wrote:
> On that note, I think we have every possibility to make desktop and mobile
> wallets mind-numbingly simple -- and perhaps even do one better. Is this
> now a community priority? If so, I would really appreciate some additional
> contributors to Hive!
>
>
How does that relate to the nodes issue?
Would packaging an optional bitcoind with your wallet be an option, which
is automatically managed in the background, so that users can run a full
node if they want?
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/a1b6a0ec/attachment.html>

2023-06-07 17:17:04 CEST

- reply

📅 Original date posted:2014-04-03
📝 Original message:On Thu, Apr 3, 2014 at 6:47 AM, devrandom <c1.sf-bitcoin at niftybox.net>wrote:
> Nice!
>
> I wonder how much of this could be scripted.
>
Everything, probably, using vmbuilder (and/or vagrant as Nick Simpson
suggests). But that's not the point here. It is to provide exact steps that
people can follow to get a basic (virtual) machine that they can use to do
gitian builds.
I didn't want to end up with a gitian-builder-that-builds-a-gitian-builder
:-) The host machine may not even have any scripting languages installed
(in the case of Windows).
It may be possible to script *some* parts (most of the quoted bash script
is runnable as script) without automating the entire process, but I hope
that over time we can make Gitian itself easier to use/setup, so that less
steps are needed in the first place.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140403/4dd280d6/attachment.html>

2023-06-07 17:17:04 CEST

- reply

📅 Original date posted:2014-04-02
📝 Original message:Hello all,
I'm working on a detailed guide on how to install and set up a Debian VM
for gitian building. As this guide can be used on any operating system that
has VirtualBox, hopefully this will make it easier for people to get
started with gitian builds.
See https://github.com/bitcoin/bitcoin/pull/3994
Rendered version is here:
https://github.com/laanwj/bitcoin/blob/2014_04_debian_gitian_build_doc/doc/gitian-building.md
Comments and patches are welcome.
If you bump into problems while following the guide please let me know.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140402/2338755e/attachment.html>

2023-06-07 17:16:55 CEST

- reply

📅 Original date posted:2014-04-05
📝 Original message:On Sat, Apr 5, 2014 at 12:40 PM, Matt Whitlock <bip at mattwhitlock.name>wrote:
> On Saturday, 5 April 2014, at 12:21 pm, Jorge Timón wrote:
> > I like both DD-MM-YYYY and YYYY-MM-DD. I just dislike MM-DD-YYYY and
> YYYY-DD-MM.
>
> Your preferences reflect a cultural bias. The only entirely numeric date
> format that is unambiguous across all cultures is YYYY-MM-DD. (No culture
> uses YYYY-DD-MM, or at least the ISO seems to think so.)
>
Let's not waste any time shed-painting this. I'd like to finish this
discussion at once:
https://xkcd.com/1179/
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140405/f40e3dcb/attachment.html>

2023-06-07 17:16:54 CEST

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Fri, Apr 4, 2014 at 5:41 AM, kjj <bitcoin-devel at jerviss.org> wrote:
> Matt Whitlock wrote:
> > The creation date in your BIP header has the wrong format. It should be
> 01-04-2014, per BIP 1.
> >
> At first, I thought this was a second April Fool's joke, but then I
> looked and saw that all of the BIPs really do use this format. As far
> as I can tell, we are using this insane format because RFC 822 predates
> ISO 8601 by half a decade.
>
> Since we don't have half a gajillion mail servers to patch, we could, if
> we desired, adopt a sensible date format here. The cost to the
> community would be minimal, with probably not more than a half dozen
> people needing to update scripts. It could even be as simple as one guy
> running sed s/parseabomination/parsedate/g
>
BIPs were based on Python PIPs, PIPs use this same ordering but spell out
the month like '1-Oct-2000'. This is slightly more readable than our format.
http://legacy.python.org/dev/peps/pep-0453/
But to make it more confusing they have two different date conventions
within the header (one for the modified date, and one for the created date).
Personally I'd prefer to standardize on ISO 8601 (YYYY-MM-DD) dates as well.
Feel free to submit a pull against bips/bips that changes around the dates.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/70a5278c/attachment.html>

2023-06-07 17:16:47 CEST

- reply

📅 Original date posted:2014-03-31
📝 Original message:A while ago I created a patch to make it possible to bind the RPC port to a
specific address or even multiple address/port pairs.
https://github.com/bitcoin/bitcoin/pull/3695
I'm fairly confident that it works, but it cannot hurt if some people that
need this functionality tested it before merge. Test results from normal
setups as well as weird corner cases (IPv4+IPv6, VPNs, ...) are welcome.
Regards,
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140331/6e664d9c/attachment.html>

2023-06-07 17:15:37 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:On Thu, Mar 13, 2014 at 6:36 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>
> On 03/13/2014 01:24 PM, Mike Hearn wrote:
> Well it looks like the consensus is to do it, instead of talking about
> it. I'm going to make sure we get uBTC into the next Armory release.
>
As default?
If so, only for new installs? Or will all current users automatically be
switched over?
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/80e3f13d/attachment.html>

2023-06-07 17:15:32 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:On Thu, Mar 13, 2014 at 1:56 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks
> ago, which was disappointing -- it sounded like the consensus was
> uBTC, and moving to uBTC later --which will happen-- may result in
> additional user confusion, thanks to yet another decimal place
> transition.
>
I've kind of given up getting any consensus about this, or even getting
people to care.
Everyone agrees that a decimal shift would be good, but it's the same
boring shed painting discussion every time on how many decimals. In the end
nothing happens.
I can't really blame Andreas for finally taking action and making the
change to mBTC. People in the community are familiar with mBTC because some
exchanges and price sites used mBTC (at least for a while when >$1000),
also mBTC seems to be catching on on reddit etc.
Moving to muBTC (which in itself would be better because it is the final
unit change ever needed without hardfork) would require more coordinated
education effort.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/ff0ee5e1/attachment.html>

2023-06-07 17:14:34 CEST

- reply

📅 Original date posted:2014-03-03
📝 Original message:On Mon, Mar 3, 2014 at 12:02 AM, Tom Geller <tom at tomgeller.com> wrote:
> Anyway, this particular solution doesn't appear to be possible in this
> case, as the file isn't at
> https://github.com/bitcoin/bitcoin/tree/0.9.0/doc/release-notes , and I
> don't believe I could copy it to the repository without going the whole git
> route. Suggestions welcome, here or privately.
>
It's not entirely trivial as you have to make sure you're editing on the
0.9 branch not the master branch, but can be done like this:
- Go to https://github.com/bitcoin/bitcoin/blob/0.9.0/doc/release-notes.md
- Click "edit"
- Make your changes and add a commit message describing the change, usually
something like 'doc: Add missing foowidget to release notes'.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140303/e36aef3a/attachment.html>

2023-06-07 17:12:15 CEST

- reply

📅 Original date posted:2014-01-17
📝 Original message:On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr <luke at dashjr.org> wrote:
>
> https://github.com/bitcoin/bitcoin/pulls/luke-jr
>
> These are pretty much all well-tested and stable for months now.
>
#3242: Autoconf improvements needs rebase, and comment from jgarzik and me
taken into account (about -enable-frontends=).
The others appear to be more controversial as they affect mining/consensus.
I'd really like to see ACKs from more reviewers and testers there before
merging.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140117/8541f89d/attachment.html>

2023-06-07 17:11:44 CEST

- reply

📅 Original date posted:2014-01-16
📝 Original message:On Thu, Jan 16, 2014 at 7:26 AM, Gary Rowe <g.rowe at froot.co.uk> wrote:
> I like "reusable address".
>
Simple and clear, I like it too.
I see the term is routing is used in finance in the USA, but as a Dutch
person I associate "routing address" with network routing, not with
banking. It's non-trivial to translate to a local term.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140116/c241b654/attachment.html>

2023-06-07 17:10:48 CEST

- reply

📅 Original date posted:2013-12-16
📝 Original message:On Mon, Dec 16, 2013 at 11:46 AM, Jim <jim618 at fastmail.co.uk> wrote:
> For the HD version of MultiBit we are removing the import
> of individual private keys entirely and only supporting HD
> addresses, primarily for safety reasons.
>
I'd love to have the same in Bitcoin-Qt as well. Too many sob stories about
people with outdated backups that lost part or all of their coins. These
are much more common than fee messups.
What we should really do is:
- Use deterministic wallets. Making regular backups becomes optional (to
retain label and transaction data and such) instead of mandatory.
- Don't support importing private keys. Replace the importing of private
keys by a "sweep" function.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131216/73f4c6a2/attachment.html>

2023-06-07 17:10:21 CEST

- reply

📅 Original date posted:2013-12-09
📝 Original message:On Mon, Dec 9, 2013 at 4:19 PM, Drak <drak at zikula.org> wrote:
>
> IMO, to avoid that, no files should be placed online unless they are the
> official release.
>
They *are* the official release as soon as they're uploaded. We may wait
for some extra gitian builds to be more confident and make the announcement
on the forums and such, but the downloads themselves don't change anymore.
It really doesn't matter in what order the different places are updated, as
long as the news is propagated everywhere within a reasonable time-span of
say a day. Requiring a certain order would require unnecessary coordination.
Don't make problems where they don't exist, we have enough actual issues.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131209/f8a18b88/attachment.html>

2023-06-07 17:09:49 CEST

- reply

📅 Original date posted:2013-11-19
📝 Original message:On Tue, Nov 19, 2013 at 6:01 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Tue, Nov 19, 2013 at 8:53 AM, Drak <drak at zikula.org> wrote:
> > It's quite normal for standards bodies to allocate numbers when in draft
> > status. If they don't pass, they don't pass - they are clearly labelled
> > DRAFTs.
> >
> > +1 on having things in a github repository. Much better for
> collaboration,
>
> The IETF makes a clear distinction between individual proposals and
> documents which have been accepted by a working group. The former are
> named after their authors. Work is not assigned a number until it is
> complete.
>
Talking about complete, BIP 40 and 41 don't even have an associated
document:
https://github.com/bitcoin/bips
I agree that was over-eager number assigning.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131119/e8ebcf9a/attachment.html>

2023-06-07 17:09:48 CEST

- reply

📅 Original date posted:2013-11-19
📝 Original message:On Mon, Oct 21, 2013 at 4:30 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and
> are not automatically assigned a BIPS number.
>
Are we going to move ahead with this?
If so, I'm volunteering to create the repository and import the current
BIPs from the wiki there (and convert from wiki markup to markdown where
necessary).
2) Time passes. Software for BIP drafts is developed, tested,
> published, and publicly discussed in a typical open source manner.
>
Personally I think it is useful to have a number as soon as a BIP can be
implemented, even if still in draft status; it gives something to refer to
when mentioning a certain improvement proposal (in commit messages and such
it could be called BIP xxx Draft).
I don't think we are at risk of running out of numbers to assign any time
soon.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131119/295bc88c/attachment.html>

2023-06-07 17:07:39 CEST

- reply

📅 Original date posted:2013-10-20
📝 Original message:On Sun, Oct 20, 2013 at 1:20 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> Since much discussion didn't materialize I went and gave it a
> technical once over, posting to the forum.
At least I now understand where he got the idea of bitcoin devs being a
bunch of paranoid, anti-authoritarian nutjobs :-) I've been on a lot of
forums in my life but never encountered one with such selfish, unhelpful,
trolling, complaining sods (well maybe apart from 15-year old gamers).
Nick couldn't have got that idea from discussion on this mailing list or
#bitcoin-dev. Please don't send anyone to that jungle. People shouldn't get
the idea that that the forum is our development community, or even endorsed
by the devs.
As for the real developer community, I haven't noticed so much
unfriendliness or closedness. But the core devs are with very few people
(certainly compared to the number of users) and reviewing and testing takes
time so pull requests, proposals and such can linger for a while. Which can
indeed be frustrating.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131020/e8f3e8eb/attachment.html>

2023-06-07 17:02:26 CEST

- reply

📅 Original date posted:2013-05-25
📝 Original message:On Sat, May 25, 2013 at 7:46 AM, Zooko Wilcox-OHearn <
zooko at leastauthority.com> wrote:
> jgarzik wrote:
> > 1) Rule changes. We don't want these.
>
> In general? What constitutes a rule change?
>
I'm sure he means rule changes with economical impact, such as miner block
reward, total number of bitcoins, block speed. Mostly non-interesting from
a technical view point, but the only changes most altcoins seem to be
making... In any case, these are set in stone and cannot ever be changed
for bitcoin or all hell will break loose.
See also https://en.bitcoin.it/wiki/Hardfork_Wishlist.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130525/cbc46b25/attachment.html>

2023-06-07 13:42:54 CEST

- reply

📅 Original date posted:2013-04-03
📝 Original message:Maybe now that bitcoin is growing out of the toy phase it's an idea to
start gpg signing commits, like the Linux kernel (
https://lwn.net/Articles/466468/).
But I suppose then we can't use github anymore to merge as-is and need
manual steps?
Wladimir
On Tue, Apr 2, 2013 at 12:54 AM, Roy Badami <roy at gnomon.org.uk> wrote:
> And the moment I hit send I realised it's not necessarily true.
> Conceivably, a collision attack might help you craft two commits (one
> good, one bad) with the same hash.
>
> But I still maintain what I just posted is true: if someone gets
> malicious code into the repo, it's going to be by social engineering,
> not by breaking the cyrpto.
>
> roy
>
>
> On Mon, Apr 01, 2013 at 11:51:07PM +0100, Roy Badami wrote:
> > The attack Schneier is talking about is a collision attack (i.e. it
> > creates two messages with the same hash, but you don't get to choose
> > either of the messages). It's not a second preimage attack, which is
> > what you would need to be able to create a message that hashes to the
> > same value of an existing message.
> >
> > (And it neither have anything to do with the birthday paradox, BTW -
> > which relates to the chance of eventually finding two messages that
> > hash to the same value by pure change)
> >
> > If someone gets malicious code into the repo, it's going to be by
> > social engineering, not by breaking the cyrpto.
> >
> > roy
> >
> > On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote:
> > > On 2 April 2013 00:10, Will <will at phase.net> wrote:
> > >
> > > > The threat of a SHA1 collision attack to insert a malicious pull
> request
> > > > are tiny compared with the other threats - e.g. github being
> compromised,
> > > > one of the core developers' passwords being compromised, one of the
> core
> > > > developers going rogue, sourceforge (distribution site) being
> compromised
> > > > etc etc... believe me there's a lot more to worry about than a SHA1
> > > > attack...
> > > >
> > > > Not meaning to scare, just to put things in perspective - this is
> why we
> > > > all need to peer review each others commits and keep an eye out for
> > > > suspicious commits, leverage the benefits of this project being open
> source
> > > > and easily peer reviewed.
> > > >
> > >
> > > Very good points, and I think you're absolutely right.
> > >
> > > But just running the numbers, to get the picture, based of scheiner's
> > > statistics:
> > >
> > > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
> > >
> > > We're talking about a million terrahashes = 2^60 right?
> > >
> > > With the block chain, you only have a 10 minute window, but with source
> > > code you have a longer time to prepare.
> > >
> > > Couldnt this be done with an ASIC in about a week?
> > >
> > >
> > >
> > > >
> > > > Will
> > > >
> > > >
> > > > On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho at gmail.com>
> wrote:
> > > >
> > > >>
> > > >>
> > > >>
> > > >> On 1 April 2013 20:28, Petr Praus <petr at praus.net> wrote:
> > > >>
> > > >>> An attacker would have to find a collision between two specific
> pieces
> > > >>> of code - his malicious code and a useful innoculous code that
> would be
> > > >>> accepted as pull request. This is the second, much harder case in
> the
> > > >>> birthday problem. When people talk about SHA-1 being broken they
> actually
> > > >>> mean the first case in the birthday problem - find any two
> arbitrary values
> > > >>> that hash to the same value. So, no I don't think it's a feasible
> attack
> > > >>> vector any time soon.
> > > >>>
> > > >>> Besides, with that kind of hashing power, it might be more
> feasible to
> > > >>> cause problems in the chain by e.g. constantly splitting it.
> > > >>>
> > > >>
> > > >> OK, maybe im being *way* too paranoid here ... but what if someone
> had
> > > >> access to github, could they replace one file with one they had
> prepared at
> > > >> some point?
> > > >>
> > > >>
> > > >>>
> > > >>>
> > > >>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho at gmail.com>
> wrote:
> > > >>>
> > > >>>> I was just looking at:
> > > >>>>
> > > >>>> https://bitcointalk.org/index.php?topic=4571.0
> > > >>>>
> > > >>>> I'm just curious if there is a possible attack vector here based
> on the
> > > >>>> fact that git uses the relatively week SHA1
> > > >>>>
> > > >>>> Could a seemingly innocuous pull request generate another file
> with a
> > > >>>> backdoor/nonce combination that slips under the radar?
> > > >>>>
> > > >>>> Apologies if this has come up before ...
> > > >>>>
> > > >>>>
> > > >>>>
> ------------------------------------------------------------------------------
> > > >>>> Own the Future-Intel® Level Up Game Demo Contest 2013
> > > >>>> Rise to greatness in Intel's independent game demo contest.
> > > >>>> Compete for recognition, cash, and the chance to get your game
> > > >>>> on Steam. $5K grand prize plus 10 genre and skill prizes.
> > > >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> > > >>>> _______________________________________________
> > > >>>> Bitcoin-development mailing list
> > > >>>> Bitcoin-development at lists.sourceforge.net
> > > >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >>
> ------------------------------------------------------------------------------
> > > >> Own the Future-Intel® Level Up Game Demo Contest 2013
> > > >> Rise to greatness in Intel's independent game demo contest.
> > > >> Compete for recognition, cash, and the chance to get your game
> > > >> on Steam. $5K grand prize plus 10 genre and skill prizes.
> > > >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> > > >> _______________________________________________
> > > >> Bitcoin-development mailing list
> > > >> Bitcoin-development at lists.sourceforge.net
> > > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > > >>
> > > >>
> > > >
> >
> > >
> ------------------------------------------------------------------------------
> > > Own the Future-Intel® Level Up Game Demo Contest 2013
> > > Rise to greatness in Intel's independent game demo contest.
> > > Compete for recognition, cash, and the chance to get your game
> > > on Steam. $5K grand prize plus 10 genre and skill prizes.
> > > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> >
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> >
> ------------------------------------------------------------------------------
> > Own the Future-Intel® Level Up Game Demo Contest 2013
> > Rise to greatness in Intel's independent game demo contest.
> > Compete for recognition, cash, and the chance to get your game
> > on Steam. $5K grand prize plus 10 genre and skill prizes.
> > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> 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/20130403/29d5335d/attachment.html>

2023-06-07 12:45:04 CEST

- reply

📅 Original date posted:2012-12-03
📝 Original message:I do think it would be nice to sweep up dust transactions, however I'm not
that happy with your solution
1) Wouldn't the need to re-transact your coins to keep them safe from
"vultures", result in people frantically sending coins to themselves, and
thus expand the block chain, instead of reduce growth?
2) putting those hard limits in passes a value judgement that IMO should
not be present in the protocol. <1BTC may be worth a lot some day, or it
could go the other way around, with dust spam of 10+ BTC. Either way the
limits will have to be changed again, with yet another fork.
3) The (normal) user does not have a view of his balance consisting of
inputs and outputs of various sizes. He just sees his balance as one
number. And somehow, inexplicably (except through a very difficult
explanation), it's going down... what if he has 10000 BTC in 0.9999999 BTC
units? Annnnnd it's gone after 210000 blocks.
I wonder if there is a way for the whole process to be transparent to the
user. The wallet is 'defragmented' but without losing the swept up coins to
the miner.
Wladimir
On Mon, Dec 3, 2012 at 12:19 PM, Michael Gronager <gronager at ceptacle.com>wrote:
> (Also posted on the forum:
> https://bitcointalk.org/index.php?topic=128900.0)
>
> The amount of "dust" in the block chain is getting large and it is growing
> all the time. Currently 11% of unspent tx outputs (UTXO) are of 1Satoshi
> (0.00000001BTC), 32% is less than 0.0001BTC and 60% is less than 0.001BTC.
> (Thanks to Jan for digging out these numbers!)
>
> This means that a huge part of the block chain is used for essentially
> nothing - e.g. the sum of the 11% is worth roughly 2 US cents !
>
> The main source for these 1 Satoshi payouts is Sahtoshi Dice. And nothing
> wrong with that, however, we should work on ensuring that too many too
> small payments will not kill the size of the blockchain in the end -
> further, they are essentially too small to be included in other transaction
> as the added fee will often make it more expensive to remove them. Hence,
> there is no incentive to get rid of them.
>
> I have an idea for a possible mitigation of this problem - introduction of
> demurrage - not as in it normal meaning as a percentage over time (see:
> http://en.wikipedia.org/wiki/Demurrage_(currency) btw, this has also been
> tried in freicoin), but as a mean to recycle pennies over time. The
> proposal is simple - UTXOs age out if not re-transacted - the smaller the
> coin the faster the aging:
> 1-99 Satoshi: lives for 210 blocks
> 100-9999 Satoshi: lives for 2100 blocks
> 10000-999999 Satoshi: lives for 21000 blocks
> 1000000-99999999 Satoshi: lives for 210000 blocks
>
> Only amounts above 1BTC lives forever - (or we could even impose aging on
> those too..)
>
> The aged coins are simply included in the block mining reward, creating
> another incentive for miners. Further, if we include all coins in this
> recycle scheme coins will never be lost forever.
>
> This scheme will impose some lifetimes also on e.g. colored coins (hence
> you need to use a certain amount to borrow space on the blockchain for the
> time needed, or simply transact them).
>
> If you like this I would be happy to write it into a BIP.
>
> Thoughts ?
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> BUILD Helping you discover the best ways to construct your parallel
> projects.
> http://goparallel.sourceforge.net
> _______________________________________________
> 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/20121203/37667201/attachment.html>

2023-06-07 12:15:32 CEST

- reply

📅 Original date posted:2012-06-16
📝 Original message:As replied on the github issue:
Personally I still think it's better to have a clear standardized "protocol
version", that implies what capabilities are supported, instead of a
capability-based system that explicitly lists them.
Capability-based systems (just look at OpenGL) tend to become horrendously
complex, as you have to take into account all possible combinations of
possible interactions, and constantly check for support of specific
features instead of just comparing a version number.
Sure, it can be necessary to distinguish between different types of nodes,
but there is no need to make it this fine-grained.
Wladimir
On Sat, Jun 16, 2012 at 3:34 AM, Amir Taaki <zgenjix at yahoo.com> wrote:
> Introspection/command discovery is nice, but I would prefer it to be
> immediately done in the first version exchange so no assumptions as to how
> a network is operating need to be made.
>
> I like the idea of a flat list of commands. It might make sense to have
> "meta"-commands that alias to groups of commands. i.e "original" for the
> current core subset up to (and including) "pong". The aliases could exist
> in a text definition file which is held on github or bitcoin.org/
>
>
> ----- Original Message -----
> From: Jeff Garzik <jgarzik at exmulti.com>
> To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
> Cc:
> Sent: Saturday, June 16, 2012 2:13 AM
> Subject: [Bitcoin-development] Proposed new P2P command and response:
> getcmds, cmdlist
>
> Outside of major features advertised network-wide in nService bits,
> P2P protocol lacks a good method of enumerating minor features or
> extensions. The version number increment is coarse-grained, and is
> not self-documenting. A simple extension which lists supported
> commands is added, as demonstrated in this pull request:
>
> https://github.com/bitcoin/bitcoin/pull/1471
>
> Another option is for verack to return this information at login,
> eliminating the need for a separate command/response.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120616/d990c59b/attachment.html>

2023-06-07 05:03:06 CEST

- reply

📅 Original date posted:2012-02-01
📝 Original message:Sounds very nice. Congratulations with the release!
Any plans for porting over bitcoin-qt?
Wladimir
Op 1 feb. 2012 15:19 schreef "Michael Grønager" <gronager at ceptacle.com> het
volgende:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like
> to share with you!
>
> === libcoin is a crypto currency library based on the bitcoin/bitcoin
> "Satoshi" client. ===
>
> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of
> the first version of the crypto currency library "libcoin" based on the
> bitcoin/bitcoin "Satoshi" client.
>
> libcoin also maintains a version of bitcoind that is a 100% compatible
> drop-in replacement of the bitcoin/bitcoind client: You can use it on the
> same computer on the same files and you can call it with the same scripts.
> And you can easily extend it without touching the basic bitcoin source
> files.
>
> The libcoin/bitcoind client downloads the entire block chain 3.5 times
> faster than the bitcoin/bitcoind client. This is less than 90 minutes on a
> modern laptop!
>
> In libcoin, the Satoshi client code has been completely refactored,
> properly encapsulating classes, removing all globals, moving from threads
> and mutexes to a pure asynchronous approach. Functionalities have been
> divided into logical units and libraries, minimizing dependencies for e.g.
> thin clients.
>
> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin,
> litecoin, ...) specific settings are maintained from a single class (Chain)
> and hence experiments with chain settings, mining, security and digital
> currencies for research and educational purposes are easily accessible. See
> the ponzicoin example for how you define your own chain.
>
> The build system of libcoin is based on CMake and supports builds of
> static and dynamic libraries on Linux, Mac OS X, and Windows.
>
> The libcoin license is LGPL v. 3. This mean that you can use it in open
> source as well as in commercial projects, but improvements should go back
> into the libcoin library.
>
> ======
>
> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>
> Join libcoin on twitter: http://twitter.com/libcoin
>
> Download "libcoin Satoshi release":
> http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>
> Best regards,
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120201/50680bfc/attachment.html>

2023-06-07 04:59:50 CEST

- reply

📅 Original date posted:2012-01-31
📝 Original message:>
> IMHO its standard that unknown URL parameters are simply ignored. I
> think we should not change this principle.
>
It's usually the right thing to do to be open to future backward-compatible
changes, but I don't know of any such standard, as it equally makes future
non-backward-compatible changes impossible.
Whatever will be defined in the BIP is the standard in this case.
> > (For example, if something that restricts the validity, such
> > as "expires" is added later on, it is pretty important not to ignore it.
> > Older clients should refuse to comply.)
>
> In this case, you'd need to refuse *all* parameters you don't know
> about. In consequence, all extensions would break older clients.
>
Which is exactly what I want to avoid by defining this up-front.
A versioning scheme can avoid this. Any BIP that breaks backwards
compatibility (for example, adds a multiple-send type or specific
restriction) should increase the version number. A client rejects URLs with
a version number higher than what it knows about.
That's the simplest way to handle it, and enough IMO.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120131/677da89f/attachment.html>

2023-06-07 04:59:43 CEST

- reply

📅 Original date posted:2012-01-31
📝 Original message:To ensure forward compatibility with optional fields, we need to define how
a client handles fields that it doesn't know about.
When should it display an error message, and when should it silently accept
and ignore the extraneous fields?
(For example, if something that restricts the validity, such as "expires"
is added later on, it is pretty important not to ignore it. Older clients
should refuse to comply.)
URL signing should indeed be addressed in a separate BIP and be an
extension mechanism, IMO.
"expires" and "message" could go into BIP 21 one as they're easy to
implement and don't need much discussion.
Wladimir
On Tue, Jan 31, 2012 at 11:01 AM, Gary Rowe <g.rowe at froot.co.uk> wrote:
> I think that the "send to private address" field will require more effort
> to implement than the simpler "expires" and "message" fields and should be
> deferred to a later BIP. There is a pressing need for expires and the only
> point of contention I see is the inclusion of a dual representation (block
> or timestamp).
>
> Personally, I feel that simple is best and while a block number represents
> Bitcoin's pulse, there is no guarantee that a block will be discovered at
> any particular moment. From a merchant perspective the main point of the
> expires field is to limit risk against currency movement (immediate cash
> out) or inventory movement (time limited offer). I have difficulty seeing a
> good use case that would need a block. People have been co-ordinating
> events based on a UTC timestamp for decades and I think we should stick
> with it.
>
> Regarding the "version" field I again think it adds unnecessary
> complexity. Pretty much everything that is needed within the Bitcoin URI
> scheme can be encoded with suitable optional fields (as query params)
> making the whole structure forward compatible. Having a version field seems
> redundant.
>
> Finally, the URI signing mechanism. Apologies for the earlier
> misunderstanding, I was reading from a limited description and it didn't
> make the purpose clear. I've since used
> https://bitcointalk.org/index.php?topic=58534.msg689190#msg689190 as my
> reference which is a lot clearer. I think it's a good idea, and I'll
> definitely support it in my MulitBit Merchant project, but it currently
> seems to need more work so I think should be deferred into a dedicated BIP.
>
> On 31 January 2012 08:35, Wladimir <laanwj at gmail.com> wrote:
>
>>
>> I also wonder whether the "send to private address" should be part of
>> this BIP, or a future one.
>>
>> IMO (but your mileage may vary) this BIP should only define the
>> bare-bones URL scheme, AND provide room for future extensions such
>> as send-to-private-address, send-multiple-signers, and so on. These should
>> be forwards-compatible (as Luke-Jr says) in the sense that older clients
>> can detect schemes they don't understand and give the user an appropriate
>> error message.
>>
>> Maybe we need a send-type parameter to define the scheme?
>>
>> Good point on the version parameter. How are clients supposed to handle
>> this? Refuse to handle the request if their URL scheme parser version is
>> older than in the URL? This should be in the BIP.
>>
>> Wladimir
>>
>> On Tue, Jan 31, 2012 at 9:23 AM, Andreas Schildbach <
>> andreas at schildbach.de> wrote:
>>
>>> Generally I prefer BIP 21 over BIP 20.
>>>
>>> I'm neutral on the 'send' parameter - present in both BIPs - which I
>>> don't understand. I think a practical usecase should be given in the BIP.
>>>
>>> Also, the 'version' parameter is unclear. What does it mean? Is an oder
>>> defined on versions (1.0b > 1.0)? Why is it an ";" parameter rather than
>>> a normal "&" parameter?
>>>
>>>
>>> On 01/30/2012 12:55 AM, Amir Taaki wrote:
>>> > Matt Corallo posted a modification of BIP 20 in an earlier email and I
>>> > asked him if he wanted to become the champion of that BIP he submitted.
>>> >
>>> > It is a modification of BIP 20 sans the alternative non-decimal number
>>> > stuff.
>>> >
>>> > https://en.bitcoin.it/wiki/BIP_0021
>>> >
>>> > Right now, I will ask the GUI client implementations like MultiBit or
>>> > Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they
>>> > support BIP 20 or BIP 21. Feel free to raise any objections.
>>> >
>>> > More weight will be given to GUIs with actual URI sche me
>>> > implementations and it's good to have a general consensus.
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Try before you buy = See our experts in action!
>>> > 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-dev2
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Bitcoin-development mailing list
>>> > Bitcoin-development at lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120131/6c6c8e64/attachment.html>

2023-06-07 04:59:37 CEST

- reply

📅 Original date posted:2012-01-31
📝 Original message:I also wonder whether the "send to private address" should be part of this
BIP, or a future one.
IMO (but your mileage may vary) this BIP should only define the bare-bones
URL scheme, AND provide room for future extensions such
as send-to-private-address, send-multiple-signers, and so on. These should
be forwards-compatible (as Luke-Jr says) in the sense that older clients
can detect schemes they don't understand and give the user an appropriate
error message.
Maybe we need a send-type parameter to define the scheme?
Good point on the version parameter. How are clients supposed to handle
this? Refuse to handle the request if their URL scheme parser version is
older than in the URL? This should be in the BIP.
Wladimir
On Tue, Jan 31, 2012 at 9:23 AM, Andreas Schildbach
<andreas at schildbach.de>wrote:
> Generally I prefer BIP 21 over BIP 20.
>
> I'm neutral on the 'send' parameter - present in both BIPs - which I
> don't understand. I think a practical usecase should be given in the BIP.
>
> Also, the 'version' parameter is unclear. What does it mean? Is an oder
> defined on versions (1.0b > 1.0)? Why is it an ";" parameter rather than
> a normal "&" parameter?
>
>
> On 01/30/2012 12:55 AM, Amir Taaki wrote:
> > Matt Corallo posted a modification of BIP 20 in an earlier email and I
> > asked him if he wanted to become the champion of that BIP he submitted.
> >
> > It is a modification of BIP 20 sans the alternative non-decimal number
> > stuff.
> >
> > https://en.bitcoin.it/wiki/BIP_0021
> >
> > Right now, I will ask the GUI client implementations like MultiBit or
> > Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they
> > support BIP 20 or BIP 21. Feel free to raise any objections.
> >
> > More weight will be given to GUIs with actual URI sche me
> > implementations and it's good to have a general consensus.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Try before you buy = See our experts in action!
> > 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-dev2
> >
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120131/8214b95c/attachment.html>

2023-06-07 04:59:30 CEST

- reply

📅 Original date posted:2012-01-30
📝 Original message:I agree with BIP 0021
Wladimir
On Mon, Jan 30, 2012 at 12:55 AM, Amir Taaki <zgenjix at yahoo.com> wrote:
> Matt Corallo posted a modification of BIP 20 in an earlier email and I
> asked him if he wanted to become the champion of that BIP he submitted.
>
> It is a modification of BIP 20 sans the alternative non-decimal number
> stuff.
>
> https://en.bitcoin.it/wiki/BIP_0021
>
> Right now, I will ask the GUI client implementations like MultiBit or
> Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they
> support BIP 20 or BIP 21. Feel free to raise any objections.
>
> More weight will be given to GUIs with actual URI scheme implementations
> and it's good to have a general consensus.
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> 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-dev2
> _______________________________________________
> 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/20120130/beed5d9d/attachment.html>

2023-06-07 04:56:08 CEST

- reply

📅 Original date posted:2012-01-16
📝 Original message:On Mon, Jan 16, 2012 at 9:12 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Jan 16, 2012 at 2:35 AM, Wladimir <laanwj at gmail.com> wrote:
> > Internet censorship *is* a threat to bitcoin, if we don't stand up for
> our
> > rights now we deserve anything that is coming. There will be no "long
> run".
>
> Very few people actually care if they can load that particular URL ...
> if you were talking about the forums it might matter more. It also
> might make sense to run some informative popup, except people are
> going to be seeing them all over the internet on higher traffic sites.
>
Agreed, a notice would be enough. No need to make the entire site
inaccessible either.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120116/29739d41/attachment.html>

2023-06-07 04:50:06 CEST

- reply

📅 Original date posted:2011-12-20
🗒️ Summary of this message: Developers should not create their own onion network for Bitcoin, as it is difficult to achieve security and anonymity. Instead, they should use Tor.
📝 Original message:On Mon, Dec 19, 2011 at 10:43 PM, Jordan Mack <jordanmack at parhelic.com>wrote:
> On 12/18/2011 1:19 PM, Stefan Thomas wrote:
> > 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 a very good point. This is needless complication at the protocol
> level. Alternatives, like Tor, could be used to provide the desired
>
Agreed. Please don't roll your own onion network. It is very non-trivial to
get security and anonymity to an acceptable level. Securing cryptocurrency
itself is a big enough challenge already.
Another reason it is better to use Tor is because of the mixing effect. A
bitcoin-specific onion network would be subject to easy traffic analysis if
it only carries Bitcoin messages.
effect. Developers could even choose to integrate Tor functionality into
> the client itself at some point.
>
Yes, good idea. I've thought about making a "bitcoin tor bundle", analogous
to the firefox Tor bundle that is available from the Tor site itself.
Probably would need to package the block chain with it, as downloading that
over Tor takes ages and causes unnecessary load on the network...
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111220/5d6c4c2e/attachment.html>

2023-06-07 04:49:25 CEST

- reply

📅 Original date posted:2011-12-17
🗒️ Summary of this message: Luke-Jr suggests standardizing and supporting public key addresses, despite their length, for better QR code compatibility and shorter transactions in blockchain.
📝 Original message:I don't see reason why not. It could just be another, longer, address type.
The advantage being that it allows for shorter transactions in the block
chain (right?).
Wladimir
On Sat, Dec 17, 2011 at 7:32 AM, Luke-Jr <luke at dashjr.org> wrote:
> IMO, we should standardize and support public key addresses. While not
> ideal
> for humans, because of their length, it's a better fit for large QR Codes
> IMO.
>
>
> ------------------------------------------------------------------------------
> 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/20111217/f67c8cb3/attachment.html>