Justus Ranvier [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-02-11 to 2019-07-24
💬 Posted a total of 127 messages
📚 Participated in the following categories: Bitcoin-development, ANN, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1k2eekmevs6gg60df75qpjw4a2atmy89vx28c8zqq5jxy64tuzrws39qd6m

Profile Code

nprofile1qqst9vumdukgdyyd8k5l2qqe8274w4ajrjkr9rur3qq2frzd247pphgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsfgcd45

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1k2eekmevs6gg60df75qpjw4a2atmy89vx28c8zqq5jxy64tuzrws39qd6m

Show more details

Last Notes

2023-06-07 20:19:36

- reply

📅 Original date posted:2019-07-24
📝 Original message:On 7/23/19 9:47 AM, Andreas Schildbach via bitcoin-dev wrote:
> BIP 157/158 is not an alternative to BIP 37:
They complement each other pretty well though.
Wallets can save the deterministic GCS filters in the same way as
headers, which means blocks can be re-scanned if necessary (importing
new keys, etc) offline.
Bloom filters are good for limiting mempool bandwidth as well as
controlling the fraction of each block that is downloaded.
On the BTC chain that last point doesn't matter as so much, but on
chains with larger blocks I expect that clients will ultimately end up
using both filter schemes for exactly that reason.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9B2D74E2A30A85B9.asc
Type: application/pgp-keys
Size: 29350 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190724/e8fe8f3b/attachment-0001.bin>

2023-06-07 20:19:34

- reply

📅 Original date posted:2019-07-22
📝 Original message:On 7/22/19 12:01 AM, Matt Corallo via bitcoin-dev wrote:
> Finally, regarding alternatives, the filter-generation code for BIP
> 157/158 has been in Bitcoin Core for some time, though the P2P serving
> side of things appears to have lost any champions working on it. I
> presume one of the Lightning folks will eventually, given they appear to
> be requiring their users connect to a handful of their own servers right
> now, but if you really need it, its likely not a ton of work to pipe
> them through.
If you want projects to adopt BIP-157/158, you'd do well to fix the
numerous errors in the specification.
As it stands right now it is impossible to implement the protocol using
the specification because he code examples are broken to the point of
appearing intentionally sabotaged.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9B2D74E2A30A85B9.asc
Type: application/pgp-keys
Size: 29350 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190722/51419c33/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190722/51419c33/attachment-0001.sig>

2023-06-07 19:46:53

- reply

📅 Original date posted:2015-12-19
📝 Original message:On 12/19/2015 10:49 AM, jl2012 via bitcoin-dev wrote:
> I am not convinced that SW softfork should be the *only* short term
> scalability solution
I don't think SW is relevant at all with respect to scalability.
Fraud proofs are extremely important from a security perspective. The
network as it exists now places too much trust in miners. Creating a way
for non-full node clients to reject chains with contain invalid
transactions regardless of how much hashing power produces the invalid
chains is essential for the security of the network.
Adding a fraud proof system into blocks means that other features, like
committed UTXO sets, become less unsafe to deploy.
Solving transaction malleability is a very nice to have feature.
A scalability solution, IMHO, is "how do we buy some time to allow
continue usage growth while working on creating a situation where it
becomes safe to eliminate maximum block size as a consensus rule?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151219/6fc064cf/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151219/6fc064cf/attachment-0001.sig>

2023-06-07 19:46:28

- reply

📅 Original date posted:2015-12-26
📝 Original message:On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:
> I think the shortest reasonable timeframe for an uncontroversial
> hardfork is somewhere in the range between 6 and 12 months.
This argument would hold more weight if it didn't looks like a stalling
tactic in context.
6 months ago, there was a concerted effort to being the process then,
for exactly this reason.
After 6 months of denial, stonewalling, and generally unproductive
fighting, the need for proactivity is being acknowledged with no
reference to the delay.
If the network ever ends up making a hasty forced upgrade to solve a
capacity emergency the responsibility for that difficulty will not fall
on those who did their best to prevent emergency upgrades by planning ahead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/218f1c1b/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/218f1c1b/attachment-0001.sig>

2023-06-07 19:46:28

- reply

📅 Original date posted:2015-12-26
📝 Original message:On 12/26/2015 06:13 PM, Bryan Bishop wrote:
> I think you'll find that there hasn't been stalling regarding an
> uncontroversial hard-fork deployment. You might be confusing an
> uncontroversial hard-fork decision instead with how developers have
> brought up many issues about various (hard-forking) block size
> proposals.... I suspect this is what you're intending to mention
> instead, given your mention of "capacity emergencies" and also the
> subject line.
I think you'll find that writing in that tone makes one come across as a
complete and utter douchebag.
I suspect what you're intending to do is to use faux-polite
condescension to bait me into responding in a way to will justify my
subsequent banning from this mailing list so that the people who aren't
interested in answering certain uncomfortable questions will have a
plausible excuse for preventing them from being asked here.
> There wasn't 6 months of "stonewalling" or "denial" about an
> uncontroversial hard-fork proposal. There has been extensive discussion
> regarding the controversial (flawed?) properties of other (block size)
> proposals. But that's something else. Much of this has been rehashed ad
> nauseum on this mailing list already... thankfully I think your future
> emails could be improved and made more useful if you were to read the
> mailing list archives, try to employ more careful reasoning, etc. Thanks.
Actually there's been 3+ years of stonewalling, deception, conflicts of
interest, and outright crimes, which have been generally ignored by
those who are desperately attempting to assume good faith.
The purpose of my email was to remind everyone that nobody is going to
get away with avoiding ownership of the consequences of their actions.
If the network experiences a painful upgrade because six months of time
that could have been used to prepare a smooth upgrade was lost, the
individuals who squandered that time own the result. They can't get
around it by demanding six additional months, as if they had nothing to
do with the six lost months.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/fc9ad844/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/fc9ad844/attachment-0001.sig>

2023-06-07 19:45:48

- reply

📅 Original date posted:2015-12-21
📝 Original message:On 12/20/2015 10:33 PM, Pieter Wuille via bitcoin-dev wrote:
> Solve several unrelated problems at the same time (fraud proofs, script
> extensibility, malleability, ...).
By "solve" do you mean, "actually implement", or do you mean "make
future implementation theoretically possible?"
In other words, would a deployment of SW involve the creation of new
network message for relaying fraud proofs, a specification that SPV
wallet developers can use to validate these messages and so know when to
ignore the highest (but invalid) PoW chain, and the ability to
automatically generate and broadcast these proofs in Bitcoin Core?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/8a874ec1/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/8a874ec1/attachment-0001.sig>

2023-06-07 19:45:38

- reply

📅 Original date posted:2015-12-08
📝 Original message:On 12/08/2015 11:41 AM, Mark Friedenbach wrote:
> A far better place than the generation transaction (which I assume means
> coinbase transaction?) is the last transaction in the block. That allows
> you to save, on average, half of the hashes in the Merkle tree.
I don't care what color that bikeshed is painted.
In whatever transaction it is placed, the hash should be on the output
side, That way is more future-proof since it does not crowd out other
hashes which might be equally valuable to commit someday.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/fc970ace/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/fc970ace/attachment-0001.sig>

2023-06-07 19:45:37

- reply

📅 Original date posted:2015-12-08
📝 Original message:On 12/08/2015 09:12 AM, Gavin Andresen via bitcoin-dev wrote:
> Stuffing the segwitness merkle tree in the coinbase
If such a change is going to be deployed via a soft fork instead of a
hard fork, then the coinbase is the worst place to put the segwitness
merkle root.
Instead, put it in the first output of the generation transaction as an
OP_RETURN script.
This is a better pattern because coinbase space is limited while output
space is not. The next time there's a good reason to tie another merkle
tree to a block, that proposal can be designated for the second output
of the generation transaction.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/a7f58417/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/a7f58417/attachment-0001.sig>

2023-06-07 19:44:03

- reply

📅 Original date posted:2015-11-02
📝 Original message:On 02/11/15 14:33, Gavin Andresen via bitcoin-dev wrote:
> I like those guidelines, although I'm sure there may be lots of arguing
> over what fits under "protects the integrity of the network" or what
> constitutes "reasonable notice" (publish a BIP at least 30 days before
> rolling out a change? 60 days? a year?)
If Bitcoin were perfect. then it would be the case that any transaction
that was valid at the time it was signed would always remain valid until
spent regardless of any protocol changes which occurred in the interim.
Certainly, that property, if it was possible to achieve, would give
Bitcoin maximum possible utility compared to alternative properties.
There are cases in which that guarantee can be met, and there are some
pathological cases where it can not be met.
It's not possible to know if the pathological cases are actually a real
problem in practice, because the possible existence of unbroadcast
transactions which would trigger them is unknowable.
A possible lazy/optimistic strategy is to implement as much
non-pathological backward compatibility as possible, and treat unhandled
cases as outstanding bugs whose resolution is deferred unless and until
they are actually triggered.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151102/79c74617/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151102/79c74617/attachment-0001.sig>

2023-06-07 19:44:02

- reply

📅 Original date posted:2015-11-02
📝 Original message:On 11/01/2015 07:30 PM, Tier Nolan via bitcoin-dev wrote:
> If at least one year's notice was given, then people aren't going to
> lose their money, since they have notice.
So after realizing that I misread substantial portions of this thread
due to a lack of attention to detail I'd like to point out this:
Bitcoin nodes have the capability to validate blocks going back to the
genesis block, including blocks which would not be valid if mined today
under current rules.
Therefore it must be the case that all the old consensus rules are
preserved somewhere in the current code bases of the various
implementations.
Given that, there shouldn't be any technical barrier to validating input
scripts according to the consensus rules that were in effect at the time
the input being spent was added to the blockchain.
Maybe dealing with output is more difficult.
Had every consensus rule change (deliberate and accidental) been
accompanied by a version number bump, it would have been possible to
phase out old versions without invaliding signed-but-unbroadcast
transactions by saying "as of block height x, transactions with version
y or lower are invalid unless their inputs are exclusively sourced from
blocks with heights < x"
If there already have been rule changes which have retroactively
invalided unbroadcast transactions which were valid at the time they
were signed, those rules could be relaxed to not apply to transactions
which exclusively spend inputs that existed before the rule change.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151102/30e16f8d/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151102/30e16f8d/attachment-0001.sig>

2023-06-07 19:44:02

- reply

📅 Original date posted:2015-11-02
📝 Original message:I guess by "locked transaction" you must mean a P2SH output?
If so, that's a rather bizarre use of terms since outputs and
transactions are very different things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151101/f3ff4eea/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151101/f3ff4eea/attachment-0001.sig>

2023-06-07 19:44:01

- reply

📅 Original date posted:2015-11-01
📝 Original message:On 11/01/2015 05:46 PM, Tier Nolan via bitcoin-dev wrote:
> An OP_CAT script that requires TBs of RAM to validate crosses the
> threshold of reasonableness.
Are there actually any OP_CAT scripts currently in the utxo set?
It's one thing to have a theoretical scripting ability that gets removed
before anyone actually uses it - that doesn't put anyone in the position
of retroactively making decisions about the validity of someone else's
money.
Presently the utxo set is about $5 billion worth of other people's money.
It's a lot easier to justify the position: "nobody has the right to
change the meaning of someone else's outputs", than it is to justify,
"some small group of people gets to decide what's standard and what
isn't, and if you choose to use the network in a valid but nonstandard
way, that group of people might choose to deny you access to your money
in the future"
In other words, how close to the shores of "administrators of a virtual
currency" do Bitcoin developers want to sail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151101/173b3946/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151101/173b3946/attachment-0001.sig>

2023-06-07 19:44:00

- reply

📅 Original date posted:2015-11-01
📝 Original message:On 10/30/2015 10:43 PM, Rusty Russell via bitcoin-dev wrote:
> By that benchmark, we should aim for "reasonable certainty". A
> transaction which would never have been generated by any known software
> is the minimum bar. Adding "...which would have to be deliberately
> stupid with many redundant OP_CHECKSIG etc" surpasses it. The only extra
> safeguard I can think of is clear, widespread notification of the
> change.
If the policy of Bitcoin Core development includes a willingness to
makes the utxos created by software other than Bitcoin Core unspendable,
then it certainly merits clear, widespread notification.
Even if that is actually a good policy, the reasons why should be made
abundantly clear.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151101/1034f016/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151101/1034f016/attachment.sig>

2023-06-07 19:43:51

- reply

📅 Original date posted:2015-10-23
📝 Original message:On 22/10/15 20:22, Peter Todd wrote:
> FWIW multi-push OP_RETURN outputs will be standard in v0.12.0:
>
> https://github.com/bitcoin/bitcoin/pull/6424
>
As I said before, once the prerequisites for a better notification
method are usable in the network, I'd love to define a version 2 payment
code that uses such an better notification system.
In the meantime. every block mined shows very consistent 70% address reuse.
Anything that can bring that number down is a good thing. Even if
version 1 payment codes could only potentially drop that number from 70%
to 30% instead of to 0%, they'd still be worth using while we wait for
version 2.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151023/bcaecfa8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151023/bcaecfa8/attachment.sig>

2023-06-07 19:43:50

- reply

📅 Original date posted:2015-10-22
📝 Original message:On 22/10/15 16:47, Luke Dashjr wrote:
> Well, I strongly disagree with adopting the BIP as it stands.
That's fine. Nobody is required to adopt an informational BIP if they do
not wish to do so.
> No, those are not network-level changes. They are mere software changes that
> can be deployed along with the rest of the proposal.
They are "mere software changes" outside the control of the users and
wallet developers who may wish to use and implement payment codes, so
are indistinguishable from a network-level change.
> "Standard" means defined in a BIP. To date, there are no standard
> transactions using OP_RETURN period. IsStandard is a node policy that should
> have no influence on future BIPs.
Since Bitcoin Core 0.11, 80 byte OP_RETURN transactions are standard, so
that's what payment codes use:
https://github.com/bitcoin/bitcoin/commit/fcf646c
Whether or not it "should" have an influence, it is an absolute fact
that Bitcoin users are affected by it.
A user whose transactions are not relayed or mined doesn't care about
the politics surrounding node policy.
Designing standards without putting the needs of its intended users
first is a great way to see the standard fail.
> Such changes should not be made until there is a standard for them.
Have you ever heard the term "permissionless innovation" by chance?
Particularly in reference to Bitcoin?
If you don't like payment codes, then don't use them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/31d89835/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/31d89835/attachment-0001.sig>

2023-06-07 19:43:49

- reply

📅 Original date posted:2015-10-22
📝 Original message:On 22/10/15 00:53, Luke Dashjr wrote:
> Sorry for the late review. I'm concerned with the "notification address"
> requirement, which entails address reuse and blockchain spam. Since it entails
> address reuse, the recipient is forced to either leave them unspent forever
> (bloating the UTXO set), or spend it which potentially compromises the private
> key, and (combined with the payment code) possibly as much as the entire
> wallet.
>
> Instead, I suggest making it a single zero-value OP_RETURN output with two
> pushes: 1) a hash of the recipient's payment code, and 2) the encrypted
> payment code. This can be searched with standard bloom filters, or indexed
> with whatever other optimised algorithms are desired. At the same time, it
> never uses any space in the UTXO set, and never needs to be
> spent/mixed/dusted.
The notification transaction portion is my least-favorite portion of the
spec, but I don't see any alternatives that provide an unambiguous
improvement, including your suggestion.
One of the most highly-weighted goals of this proposal is to be usable
on as many mobile/light wallets as possible.
I know for sure that all existing platforms for balance querying index
by address. Support for bloom filters or other querying methods is less
comprehensive, meaning the set of wallets that can support payment codes
would be smaller.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/915cb984/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/915cb984/attachment.sig>

2023-06-07 19:43:49

- reply

📅 Original date posted:2015-10-22
📝 Original message:On 22/10/15 15:43, Luke Dashjr wrote:
> BIPs should in general not be
> designed around current software
I strongly disagree with this statement.
There is a version byte in the payment code specification for a reason.
Version 1 payment codes are designed to be deployable by wallet
implementers today, without requiring them to wait on any network-level
changes whatsoever, which includes IsStandard() redefinitions, or
yet-to-be-invented-and-deployed filtering schemes.
As far as I know, multi-push OP_RETURN outputs are not standard
transactions and so wallet users can not rely on transactions containing
them to be relayed through the network, therefore any improvement to the
protocol which requires that feature is not appropriate for version 1.
When additional capabilities are deployed in the network such that
Bitcoin users can rely on their existence, that would be a great time to
specify a version 2 payment code that uses those features and encourage
users to upgrade (which should be a fairly smooth process since their
actual keys don't need to change).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/d079a180/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/d079a180/attachment-0001.sig>

2023-06-07 19:43:36

- reply

📅 Original date posted:2015-10-14
📝 Original message:On 14/10/15 19:02, Jeff Garzik via bitcoin-dev wrote:
> *Disclose potential conflicts*
>
> 1. List discussions often involve interested parties. We expect
> participants to be aware when they are conflicted due to employment or
> other projects they are involved in, and disclose those interests to other
> project members.
> 2. When in doubt, over-disclose. Perceived conflicts of interest are
> important to address, so that the lists’ decisions are credible even when
> unpopular, difficult or favorable to the interests of one group over
> another.
Even if we assume everybody will try to approach that topic in good
faith, I don't think it's that simple.
A term that's become popular recently is "Bitcoin maximalist", and it's
frequently used as a slur or insult.
I honestly find that to be incomprehensible. If somebody at a Ford board
meeting started talking about how Ford needed to make sure Toyota was
able to sell enough cars, they wouldn't get very far by labelling their
critics as "Ford maximalists".
Anyone who works at Ford and who isn't a Ford maximalist is in the wrong
job.
And yet in Bitcoin, a much development is funded by companies who offer
products which compete with Bitcoin, or at least would be in competition
if Bitcoin were to achieve unlimited success.
I expect this is a minority view on this list, but my position is that
anyone who is not a Bitcoin maximalists has a potential conflict of
interest if they're also involved in Bitcoin development.
I also suspect this issue is a cause of much user dissatisfaction with
Bitcoin development. If Bitcoin users and investors don't trust that the
developers are working toward the unlimited success case, they can and
will revolt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/593ed78f/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/593ed78f/attachment-0001.sig>

2023-06-07 19:41:01

- reply

📅 Original date posted:2015-09-21
📝 Original message:On 19/09/15 15:11, Rune K. Svendsen wrote:
> An honest miner is a miner that supports the network by building on top of the best valid chain. A malicious miner is one who wants to disrupt the Bitcoin network, not support it, for example by executing a 51% attack which mines empty blocks on top of the best chain.
This isn't a particularly good definition.
"An honest miner is a miner that supports the network by building on top
of the best valid chain."
What is the "best valid chain"? The one with the most proof of work? The
one that meets some other definition of "best"?
"A malicious miner is one who wants to disrupt the Bitcoin network, not
support it"
This is a tautology, the equivalent of saying "a malicious miner is a
miner that is malicious" A true, but entirely useless, statement.
"for example by executing a 51% attack which mines empty blocks on top
of the best chain."
Again, you're begging the question with the word "attack", because
that's what you're supposed to demonstrate.
Apparently the difference between honest mining and malicious mining is
empty blocks? You've said in both cases the miners are extending the
"best valid chain". Is extending the best valid chain with an empty
block always a malicious act?
What's the significance of 51% in this definition? Is the same empty
block which extended the best valid chain honest if the miner who
produced it has 49% of the network hashing power and malicious if they
add a few more ASIC units?
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150921/1a8e96bd/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150921/1a8e96bd/attachment-0001.sig>

2023-06-07 19:41:00

- reply

📅 Original date posted:2015-09-19
📝 Original message:On 19/09/15 10:45, Rune Kjær Svendsen wrote:
> We need to distinguish between two different things here:
>
> 1) A 51% attack, where the majority of mining power is *malicious* (hence “attack”)
What does "malicious" mean?
In other words, If miner A is mining honestly, and miner B is mining
maliciously, what are some of the possible difference in their behaviour
we would observe?
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/c934b9de/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/c934b9de/attachment-0001.sig>

2023-06-07 19:40:59

- reply

📅 Original date posted:2015-09-18
📝 Original message:On 18/09/15 15:17, Rune Kjær Svendsen via bitcoin-dev wrote:
> Bitcoin does not function if the majority of mining power is dishonest. There is no way around that. It’s how proof-of-work functions.
None of those statements are true.
If a majority of Bitcoin miners are mining invalid blocks, then they
aren't Bitcoin miners any more and are no longer relevant to the Bitcoin
consensus.
There does exist a problem that light clients aren't always able to tell
the difference between chains that are valid and chains that are not
valid, but it's is possible to create simple proofs that would do so:
https://gist.github.com/justusranvier/451616fa4697b5f25f60
If those changes would be implemented, then any node that knew a chain
was invalid could produce a compact proof that anyone else in the
network could verify, regardless of how much proof of work was used to
create the invalid chain.
Committed UTXO sets would need safe to rely upon if a similar set of
proofs that a particular set was invalid existed.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/69ac0ec4/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/69ac0ec4/attachment.sig>

2023-06-07 19:39:32

- reply

📅 Original date posted:2015-09-04
📝 Original message:On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote:
> Since BIP 43 is still a draft, I propose modifying it to refer non-
> Bitcoin purpose codes to the SLIP repository:
> https://doc.satoshilabs.com/slips/
What benefit is created by delegating the BIP-43 namespace management to
that company in particular?
BIP-43 as it is currently composed provides the convenient feature of
purpose codes matching the BIP number. Moving purpose codes to a
separate namespace add complexity to its usage for no discernible benefit.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150904/ade4f0f3/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150904/ade4f0f3/attachment-0001.sig>

2023-06-07 19:39:32

- reply

📅 Original date posted:2015-09-04
📝 Original message:On 09/04/2015 01:21 PM, Luke Dashjr wrote:
> This is not Bitcoin's problem... Polluting the BIP repository with N non-
> Bitcoin related specifications would be.
HD generation of keypairs from a single seed for many non-conflicting
uses is a valuable and useful technique.
Intentionally making a useful technology less useful because assigning
non-colliding numbers is too hard is a strange approach to software
engineering.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150904/ba5265b3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150904/ba5265b3/attachment.sig>

2023-06-07 19:38:48

- reply

📅 Original date posted:2015-09-02
📝 Original message:On 09/01/2015 03:29 PM, Wladimir J. van der Laan wrote:
> On Mon, Aug 31, 2015 at 01:55:43PM -0500, Justus Ranvier via bitcoin-dev wrote:
>
>> * They should own their bitcoins, meaning that they retain exclusive
>> control over their balances. Even more precisely, the network must
>> always honour the conditions of the scripts associated with unspent outputs.
>>
>> * Their fraction of the Bitcoin ledger must not be diluted.
>>
>> * When they decide to spend their coins, they will be able to do so
>> without requiring permission from a third party.
>
> All of these properties are contingent on the system being decentralized.
That is not true, unless you are using a definition of the word
"decentralized" which is so broad as to convey no information whatsoever.
Saying that Bitcoin's security depends on decentralization is like
saying that a bridge's structural integrity depends on good materials.
Statements like that convey zero relevant information. Potential users
of a bridge want to know about the maximum working load of the bridge,
and under which conditions it is safe to use. At what wind speed should
the bridge be closed? Is it ok to keep using it after a magnitude 4
earthquake, or should it be closed for inspection?
Repeatedly asserting that bridges need to be made of good materials as
an alternative to answering those kinds of questions would be easily
recognized as useless in that context, but for some reason people seem
to accept it in this one.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150902/d0a332af/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150902/d0a332af/attachment.sig>

2023-06-07 19:38:40

- reply

📅 Original date posted:2015-08-31
📝 Original message:On 08/31/2015 05:53 PM, Monarch wrote:
>
> Bitcoin is a decentralized currency which allows any person the
> ability to transact in a way that does not require specific trust in
> any particular party. Users can independently verify that
> transactions they receive are valid and confirmed, with strong
> confidence that they can not be reversed or modified. A third party
> does not hold these same properties, there is no reason to believe the
> information they present other than trust they will not lie, cheat, or
> violate privacy at their own will. Given information by a trusted
> third party (such as a balance or existance of transaction), a person
> has no ability to independently validate their claims as you do in a
> decentralized system.
This is on the right track, but still falls short in a few areas.
It's a false dichotomy to say that our choices are: Bitcoin as it exists
today (or in some theoretical perfect state of decentralization), or an
Excel spreadsheet edited by a trusted third party who can change any
number to be any other number they want.
Imagine there was only one miner in the network. In spite of being the
sole entity creating the blockchain there would still be many actions
they could *not* do:
* Falsify ECDSA signatures
* Generate proof of work without expending energy
* Produce blocks that non-mining nodes would recognize as including
invalid transactions (including printing themselves unlimited balances)
* Force other people to purchase the coins they mine so that they can
pay their electric bills
What they *can* do is:
* Defraud recipients of transactions by including a payment transaction
in a block, then orphaning that block with another block that contains a
conflicting transaction (double spend).
There is usually*** a cost to performing this attack, so miners would
only be expected to do it if the benefit exceeds the cost.
* Prevent the inclusion of valid transactions into any block using any
criteria they want.
The worse case scenario for mining monopolization is that the risk of
profitable double spends means that transactions might require more
confirmations to be reliable, and that some entity can censor
transactions at will.
Those aren't exactly end-of-the world failure cases. They are certainly
undesirable and every means of preventing them should be investigated,
but it does mean that it should be possible to dial back on the
catastrophe language when analysing possible failure modes.
The weakest area for Bitcoin to be attacked is via censorship enforced
by miners.
The first line of defence is to improve the privacy features of wallets
to the point at which blacklists are not effective. I'm confident that
this can be achieved.
That leaves the censors with the choice of whether or not to escalate to
whitelisting, which ultimately can be countered by users switching to a
new system which does not have that particular anti-feature.
tl;dr: Bitcoin security does not lie on a one-dimensional "centralized
vs decentralized" axis. Treating it as if it does removes the clarity
that is needed in order to effectively solve problems.
***Exploring the exact conditions under which this is true is an
interesting exercise and relevant to long term discussions vis a vis the
block subsidy and transaction fees in the future.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/93275cff/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/93275cff/attachment-0001.sig>

2023-06-07 19:38:40

- reply

📅 Original date posted:2015-08-31
📝 Original message:On 08/31/2015 04:42 PM, Monarch wrote:
> The justification for the existence of Bitcoins hinges on it. What is
> described in the whitepaper is a system without the trust of third
> parties to process electronic payments, this can not exist without
> decentralization. Absent any unforseen revelations this is a
> requirement rather than a suggestion or fleeting fancy. Below a
> decentralized Bitcoin you are free to make systems as centralized as
> you please without affecting the parent, below a centralized Bitcoin
> there is no room to make it less. We really only have one shot at a
> properly bootstrapped, decentralized currency, and it would be a great
> shame to mess up the one we have with hasty decision making for
> unclear goals.
You keep using the word "decentralized" without explaining (and most
likely, understanding) what it means.
You say:
> a system without the trust of third parties to process electronic payments
What does it mean to use a decentralized network instead of a trusted
third party to process electronic payments? What undesirable actions can
a trusted third party perform that a decentralized network can not perform?
The answer to those questions are the *actual* goals, for which
decentralization is just one portion of a solution.
It might be helpful to organize Bitcoin's various existing, potential,
rejected, and proposed features using the Kano model:
https://en.wikipedia.org/wiki/Kano_model
Example: The ability of one entity to spend another entity's Bitcoins
without their consent is a reverse quality.
It would at least give us something objective to talk about.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/f79e7b35/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/f79e7b35/attachment-0001.sig>

2023-06-07 19:38:39

- reply

📅 Original date posted:2015-08-31
📝 Original message:On 08/31/2015 03:06 PM, Monarch via bitcoin-dev wrote:
> What is Bitcoin if not decentralized?
>
> Bitcoin the most awkward, unprivate and damaging currencies ever
> created. It is terribly slow for general use, and it is very
> difficult for users to get over the technical hurdles required to use
> it safety. It is simultaneously the least private payment system ever
> conceived for general use, yet still manages to consistently help
> terrorists and pedophiles. Over half a gigawatt of power is used to
> power the miners which timestamp the network, causing hundreds of
> millions of tonnes of CO2 and radioactive particles to be spewed into
> the atmosphere.
>
> Perhaps we can justify these damages as the cost of decentralization,
> similar to one justifying the tor anonymity network as having
> significant positive effects outweighing the negative. However if you
> are truly willing to give the goal of absolute decentralization up as
> unachievable or unrealistic, it would be much more sensible to replace
> the entire Bitcoin network with a couple of geographically distributed
> SQL servers and call it a day.
>
> Without decentralization as an ultimate goal, Bitcoin is an
> abomination that is best dismantled.
You don't understand what value proof of work provides, or what features
differentiate good money from poor money, and you can't make a
defensible statement of Bitcoin's value proposition.
Because you can't do these things, you assume nobody else can do them
either and therefore the only way for Bitcoin to survive is to sweep the
problem under the rug and distract users with a word that means nothing
(and therefore means whatever the observer wants it to mean).
This is not a strategy that can be successful in the long term.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/6756f898/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/6756f898/attachment-0001.sig>

2023-06-07 19:38:38

- reply

📅 Original date posted:2015-08-31
📝 Original message:On 08/30/2015 01:38 AM, Adam Ritter via bitcoin-dev wrote:
> Still, it doesn't have anything that is practical for me as an user of
> the Bitcoin network (I use it for storing long-term purchase value, as
> most of the people who I know): it doesn't help me if I still need to
> pay transaction fees after the blocksize limit is gone. My (and other
> users') main concern is about centralization, which has nothing to do
> with transaction fees. I would be OK with $100 transaction fee as
> well, as long as the network is fair and secure (which comes from
> decentralization).
I don't believe that any Bitcoin user actually cares about
decentralization, because none of them I've asked can define that term.
"decentralization" has become a placeholder word for "features or ideas
that I like" and it's long past time to drag the discussion back into
the realm of concrete and achievable goals.
I think there are a few specific things we can surmise about what users
might mean when they say they want Bitcoin to be "decentralized":
* They should own their bitcoins, meaning that they retain exclusive
control over their balances. Even more precisely, the network must
always honour the conditions of the scripts associated with unspent outputs.
* Their fraction of the Bitcoin ledger must not be diluted.
* When they decide to spend their coins, they will be able to do so
without requiring permission from a third party.
A decentralized architecture in certain parts of the network can be
helpful for achieving those goals, but it is not always necessary, nor
is it always sufficient to achieve them.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/f656c9e5/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/f656c9e5/attachment-0001.sig>

2023-06-07 17:41:53

- reply

📅 Original date posted:2015-07-10
📝 Original message:On 07/10/2015 11:31 AM, Jeff Garzik wrote:
> This is a good explanation but it does not address reachability. TX_a, the
> first tx sent out on the network, presumably has insufficient fee to get
> mined - which also means it did not necessarily even reach all miners.
>
> Simply sending out TX_b with added fee does not guarantee that nodes
> suddenly have TX_a, which they may have ignored/dropped before.
I'm not sure why that's actually a problem.
CPFP is initiated by the recipient of the parent transaction, and so if
the recipient is creating this transaction in the first place they must
have a copy of the parent transaction which can/should broadcast at the
same time.
If the child reaches a CPFP miner, then presumably the parents made it
as well (any path between the sender and the miner that doesn't relay
the parent should reject the child as trying to spend non-existent
coins), so both of the transactions can be mined at the same time.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150710/9318baa9/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150710/9318baa9/attachment-0001.sig>

2023-06-07 17:41:46

- reply

📅 Original date posted:2015-07-05
📝 Original message:On 07/05/2015 03:53 PM, Eric Lombrozo wrote:
> Perhaps I didn't write that so well if I gave that impression. Perhaps
> taking a look at some of my work in this space would make you think
> otherwise. (yes, I've implemented an entire SPV stack from scratch...look
> it up.)
I get concerned when I hear statement like "the raison d'etre of bitcoin
is trustlessness" because it implies that Bitcoin promises infinite
security, which has never been the case.
I don't think we can meaningfully discuss Bitcoin security issues if
every proposal is compared to a straw standard of perfection which is
achievable. When everybody expects infinite security then the perfect
turns into the enemy of the good (and the achievable).
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150705/d55e44a6/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150705/d55e44a6/attachment-0001.sig>

2023-06-07 17:41:45

- reply

📅 Original date posted:2015-07-05
📝 Original message:On 07/05/2015 01:50 PM, Eric Lombrozo wrote:
> The only practical way for the network to function at present (and what has
> essentially ended up happening, if often tacitly) is by introducing trust,
> in validators, miners, relayers, explorer websites, online wallets,
> etc...which in and of itself wouldn't be the end of the world were it not
> for the fact that the raison d'etre of bitcoin is trustlessness - and the
> security model is very much based on this idea. Because of this, there's
> been a tendency to deny that bitcoin cannot presently scale without trust.
> This is horrible because our entire security model has gone out the
> window...and has been replaced with something that isn't specified at all!
When I read this, I get the impression that you (and possibly many
others) never actually understood the Bitcoin security model in the
first place.
Bitcoin is a digital cash system that prevents double spending without
using a trusted third party.
More specifically, successful double spending in Bitcoin requires an
attacker to pay a proof of work cost that exceeds the cumulative proof
of work paid by all non-attackers since the original spend.
The security model holds for any user who has access to the complete
blockchain, and currently does not hold for all users who do not. An
attacker can double spend without paying the full PoW cost the security
model requires if users do not have a full copy of the blockchain which
which to verify the attacker's blocks.
That's a problem, but it's not an unfixable problem.
The reason an attacker can fool SPV clients into accepting invalid
blocks is because there exists no mechanism via which honest nodes can
prove the invalidity of blocks.
Implement that mechanism, and the security of SPV clients will far more
closely resemble the security of full nodes.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150705/1fe13a75/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150705/1fe13a75/attachment-0001.sig>

2023-06-07 17:41:40

- reply

📅 Original date posted:2015-07-04
📝 Original message:On 07/04/2015 12:58 PM, Tier Nolan wrote:
> Yes, you can mostly get short proofs for each step, but you have to make
> sure your proofs are also provable.
>
> It means going through everything that needs to be proved for a block to be
> valid.
I think the problem is tractable if some reasonable assumptions are made
about the ability of SPV clients to perform validity checks that don't
involve any state outside a single transaction (or block):
https://gist.github.com/justusranvier/451616fa4697b5f25f60
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/52430715/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/52430715/attachment.sig>

2023-06-07 17:41:40

- reply

📅 Original date posted:2015-07-04
📝 Original message:On 07/04/2015 10:35 AM, Tier Nolan wrote:
> Even that can be handled with UTXO set commitments. If the UTXO tree is
> sorted you can prove that an entry doesn't exist.
How do we know if a committed UTXO set is valid? If a majority of the
hashing power is willing to extend an invalid branch, it's reasonable to
assume they'd be willing to commit an invalid UTXO set as well.
In order for the committed UTXO set to be reliable at a minimum it will
need to contain at a source block reference for each item in the set.
That would enable fraud proof to show that the committed UTXO set
contains invalid entries.
>> If each transaction input identified the block containing the referenced
>> outpoint, then the proof of non-existence is either the block in
>> question, or the list of block headers (to show that the block doesn't
>> exist). That's a significant improvement in proof size over the entire
>> blockchain.
>>
>
> That is reasonable. Unconfirmed transactions can't include that info
> though.
>
> It could be committed in as an extra commitment.
I agree the information should be an extra commitment produced by the
miner, rather than changing the format of the transaction, since the
author of a transaction can't always know the required information ahead
of time.
> One issue is that you need to prove of of these commitments too.
If items in the the proof tree are required to be sorted, then it's easy
to proof that an item is missing.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/fdca1cb1/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/fdca1cb1/attachment-0001.sig>

2023-06-07 17:41:39

- reply

📅 Original date posted:2015-07-04
📝 Original message:On 07/04/2015 12:44 AM, Peter Todd wrote:
> Fact is, SPV means you're trusting other people to check the rules for
> you. In this particular case bitcoinj could have - and should have -
> checked the BIP66 soft-fork rules, but in general there's no easy
> solution to this problem.
In general, the situation can be improved if there existed proofs which
validating full nodes could broadcast which would tell SPV nodes why the
branch it sees with the most proof of work is actually invalid.
As far as I can tell, producing such proofs is reasonably
straightforward for all cases except the case where a block is invalid
because it contains a transaction which references a non-existent output.
The shortest proof that a particular transaction does not exist in the
blockchain is the entire blockchain.
If each transaction input identified the block containing the referenced
outpoint, then the proof of non-existence is either the block in
question, or the list of block headers (to show that the block doesn't
exist). That's a significant improvement in proof size over the entire
blockchain.
Proving the non-existence of a particular transaction in a specific
block could be made easier for future blocks by requiring transactions
to be ordered in the merkle tree by their hashes. Then it would just
require a few nodes in the tree to show that the transaction isn't in
the place where it should be.
--
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/b4ea50d8/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/b4ea50d8/attachment-0001.sig>

2023-06-07 17:41:25

- reply

📅 Original date posted:2015-07-02
📝 Original message:The primary purpose is to allow Bitmessage users to benefit from
eternal key backups by generating their addresses from a seed.
In addition, they can use the same seed for a Bitcoin wallet and a
Bitmessage client.
This method also enables future use cases where senders calculate
Bitmessage addresses based on a recipient's extended public key and
some other index value.
On Wed, Jul 1, 2015 at 12:07 PM, Kristov Atlas
<kristovatlas.lists at gmail.com> wrote:
> Hi Justus,
>
> What are the potential applications for this BIP?
>
> -Kr
>
> On Jun 30, 2015 1:53 PM, "Justus Ranvier" <justus.ranvier at monetas.net>
> wrote:
>>
>> Monetas has developed a Bitmessage address derivation method from an
>> HD seed based on BIP-43.
>>
>>
>> https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki
>>
>>
>> We're proposing this as a BIP per the BIP-43 recommendation in order
>> to reserve a purpose code.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:41:24

- reply

📅 Original date posted:2015-07-01
📝 Original message:On 07/01/2015 03:54 AM, Jeffrey Paul wrote:
> could we please limit ourselves to posting about the research and development of Bitcoin Core?
If that's the purpose of this list, then it is misleadingly named.
If development of Bitcoin Core, the application, is to be considered
independent from development of Bitcoin, the protocol, then Bitcoin Core
development needs its own list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150701/d98bb8f5/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150701/d98bb8f5/attachment-0001.sig>

2023-06-07 17:41:20

- reply

📅 Original date posted:2015-06-30
📝 Original message:On 06/30/2015 02:54 PM, Adam Back wrote:
> Decentralisation is key to Bitcoin's security model, and it's
> differentiating properties.
Continually repeating this statement without defining terms or providing
evidence does not make it true or informative.
"Decentralization" is a popular buzzword these days, but how about
stating the problem description in a way that is more precise and accurate?
One of Bitcoin's differentiating properties is that it prevents double
spending without using a trusted third party.
Now instead of arguing about some nebulous "decentralization" that
nobody can define or measure, we can talk about more helpful questions like:
Under what circumstances will miners and/or nodes behave as a trusted
third party (collusion)?
What incentives exist which increase, and which reduce, any tendencies
that may exist for nodes to collude?
In what ways specifically does MAX_BLOCK_SIZE relate to either of the
following questions?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150630/6fb56178/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150630/6fb56178/attachment-0001.sig>

2023-06-07 17:38:25

- reply

📅 Original date posted:2015-06-16
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015-06-16 23:32, Gregory Maxwell wrote:
> Is there any discussion thats been had relating to the BIP-drafts at:
>
> https://github.com/Open-Transactions/rfc/tree/master/bips
>
> Fellow Traveler has apparently been waiting 9 months for progress on
> these proposals and I'm trying to find out where the breakdown
> happened. While do not doubt that I am somehow at fault, I can't
> figure out how.
>
> Searching my email and this list archive for "Base58 Serialization for
> Transaction-Based Color Descriptors" or "Order-based Smart Property
> Coloring" or the draft names bip-ccids, etc. turn up no hits at all.
> I've asked several other people and there list archives show nothing.
The only two proposals we sent to the mailing list were attached to this
post:
http://sourceforge.net/p/bitcoin/mailman/message/32736455/
The rest of the proposals in that respository, as well as those the fork
here:
https://github.com/Monetas/rfc/tree/master/bips
were never submitted because we decided to use alternative identifiers in
leiu of BIP numbers to serve as the purpose code in the HD path.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVgLRaAAoJECpf2nDq2eYjw7YQAJYrciEZZeasEJRR7XwZ5AWQ
9e/pz1SV2hoRs7TqHgHoXGINLbG9LwlXFmnoG14z+vwKvheJxlC6gOQCRIRwPfrR
zwuQWyoONHn82XL44ABqjnu0fmeh7egx3FIzsgDUxUgiP5dA0BuQvrT1+DptfJ+p
5sM7ZvRqfZJbek4AHk9Y4kERQYsP4HKgC1W3Acr1In9WPSj5TRtYz7tUK+SFcO+m
A3Ny5dUiAmmf5mfLZiWrEmCG34n+cCJZEU2hlQqH5ZuAHPmeTLuar91MLj/1Xltf
OFlMGhmUPy1alTx8o39nwRjfXIVQLk7/D5YB3gB2CUuXd+sWbY+6LUyniOKtQK3C
EmEDOUFSNm4JV1AmM+ea1HUufCJfkg1VHko4hsIyc1e7ztdECIzPQKAy7DAcu1YS
BhbkxNyaUqoF+J/ggrXhT/r5oVpWsifdj4IEzaMvmOxu+p+hTkzzwitLuyknEBZE
b2KWRMWNOheVpDp7RmrcTPqa4S1N8XcfJazDyigIhl0E/Bjk+pC1SHo7IIEMZMQ+
Fz7JaALd8XK0l7HBvvJnZmYwVLnQyB01B6n7z8eTTAneHhSXxa7Z1aFTkYU8Wp9o
L5nb1K7gJtjBFqhLi3PMLRhARao1Q/CK5bDt9Mb3VMy9jAIr9X9/NcL473cbHtQH
/h91bhkL9bvvkeCl5yQk
=NgfK
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/c69bd9f5/attachment.html>

2023-06-07 17:35:25

- reply

📅 Original date posted:2015-05-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Replying to the list because this is a common question.
We rated as many wallets as we could based on the amount of manpower
we had available to perform the ratings.
We will be holding a recruiting drive shortly to solicit additional
volunteers so that we can cover more wallet for the next round of ratings.
On 05/18/2015 11:40 PM, Eric Lombrozo wrote:
> mSIGNA is notably absent from the report despite having some of the
> most advanced security and privacy features and having been on the
> bitcoin.org site longer than some of the other wallets reviewed.
>
> Is there some process to get reviewed I missed? Please add us to
> the report.
- --
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVWmA1AAoJECpf2nDq2eYjXGgP/2CpIYpG49WKAfG/PXmu1zFV
+zzU/7PCz+0ez0mGCz5l3QMc9TCDs6KDx0sPHZngwwLio3C4JMpu+zfnw6gngw/G
6NNtmDZ9xWgWx3kQyBLWBCM/K63rLE1QYJqiIc7QaDuDTk5w0upwkFxLejWeem1j
Z8Zy6ycHNNHE19o5pIYViWaRXojMD70fBFSoU9sAyvnOup7b5Cj4PLx7mbMbaegV
gCHd7zd88AH0f2ilFiVMQJBKf03KzYjarRVrAyvAb/8VLiYMRC8SS3y2tzM+qRKl
ZADAp8FiQ6GOFRssNg+x7tc3DX2ngBljLLKM90kPLR2cvwp8VHi0I0biqM8n2M17
CMjZVRNvXitNnKFc42nk51HsZR5LkDK3Rf9I1E3fBVKJ5feEbDi3tlEg9PCWD2xM
PmSRzXoUBAjpr9xL2kBzlE4aTYZCmmMxAMF1mcSYujdNzQ2IN0gD1urJtCwZ8zZ1
LL2cPimS3GTWEpoQQ/Fu+0NDwiPditDGt+DN16Mi5uioPvaumHMIV6u9ZNdD9ZEv
UTGW8C2Hj+ENzqhpdhlV5YfYUnKo6/ukw+xxTXRxbbLGxA6iRrVnPzsYTZoF0Vrt
T4IsdzPIg5yeF5IQKEV1lLyx+gOIvmDF1RZE36NY8bGn2zusFzUGxiqWa6yw0hfw
l4ytd8pfhIvTkuz1o9aQ
=kWhU
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150518/58a72a8b/attachment.bin>

2023-06-07 17:35:24

- reply

📅 Original date posted:2015-05-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We're produced the first in what we hope to be a long series of
reviews of Bitcoin wallet privacy features, available here:
http://www.openbitcoinprivacyproject.org/2015/05/spring-2015-wallet-privacy-rating-report/
https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/raw/master/2015-1/OBPP%20Bitcoin%20Wallet%20Privacy%20Rating%20Report%20-%20Spring%202015.pdf
Specifically from the readers of this list, we are very interested in
feedback regarding our privacy threat model and the rating criteria we
derive from it.
Threat model:
https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/2015-1/threat%20model.wiki
Please send any suggestions or corrections via a GitHub issue to the
wallet-ratings repository so that we can incorporate it into future
reports.
- --
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVWhBvAAoJECpf2nDq2eYj3JEP/jw/Xkgq4yZRE4FK8a8kPBqn
3ULyS74KtNyPDdpTK0bdH7//0d1ep+LvNpIkFhWCJ/WQ7T/Ft3iQl1HJvXGC0ZzM
XKd7ptXLpBrKElARAORgUlFPOeKzOrOyP4uvvGAMZ+CXEnKeyxDzK+WzfYnWyDEU
Q4XQ/ndwPqbZm9Nb+GeF186TXcA/KqcQEuOIw7/jFGHfFT6QBKVz1SraVrgdcMky
8KKYOsYJt8lTUjVN1INmLFoRZ0cGUd+IFKweSCibyAu9TdvVQfQSPfSnfZtDLk6X
g1oPYaxX6r9+/1zm2v5ISk97nKrvNslPjeQbuW3vWlROSxGZ9lV+MVNvkqm1jSpF
ip0Il+VJb8hhh9LRJV6euhLQyR+xnLIVJvslJt883rhKIBi3M/OipMuhipIeAbnV
0WQmnpQ9ZgagPoFRxGp86Cz7PWTfj7zllB3yk/M3tA8e64VQFhEnoyJO8hPqfEQh
wPZP3UQ+K3PM/2oe4W5ZkfkqD6tIzGTQeMkGFeCvTsMmsW9+Ml8j4YTwKA0z5vr5
IebJ51Vpaq1noVEl46q8utpLp1wATI8SG5sBwSaR4/REUGkSWjSCeZeLcK8WzdEa
SaZ8t5Rqr1AcwtD6n9rVvYoF26285120jM/YX8XgMldWi0RXrlWD4B4lA1i7eVfZ
hINSIR+QsJsw7yq7Ox3/
=NMNo
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150518/fd9f9a2c/attachment.bin>

2023-06-07 17:33:31

- reply

📅 Original date posted:2015-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/07/2015 05:47 PM, Jeff Garzik wrote:
> Bitcoin needs to be the best it can be (Layer 1), but all solutions
> cannot and should not be implemented at Layer 1.
I can provisionally agree with that statement as long as "all
solutions cannot and should not be implemented at Layer 1" it taken to
be a hypothesis to be tested in the context of each proposed solution
rather than a law of nature.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVS4nOAAoJECpf2nDq2eYjZGEP/jvk+RNQO+Zoyp0jc6aup5Aa
USUFk1TYBqbu47vvc3jFHc4V3/BjiwkUKp5bZ4iIxr3xWIA35CcjfpSJEIlEj0zM
OHS2j+eS0WkNWCmWgj+3sJpQBNnqLmdBOG1q6z0aBLGwG7uabo+YAhJjlP8isfcn
cBQPGjeTW82ZZLdkNaThbFr53oTYiVPNqMIIq6orUe5vetQS/zfTyowi7Y9+OT+b
FMXOEmXQTzF415LImJNXOcGFx51YkLe3SuEPEqqIX/+gOcT4HMPuKbqyAu6xXRQK
O7uI+6AjN1mX7Cvt19wYkUggJ7ddVKrHINSzOfsZ+pdF8mdY4TrdwJJhfN0+fnvo
KYW+pmEAFRMveV8SVGJpHQ/pWECKbFiz1SRnDfjlbX/C5mHiHM4EmqCxC1pVDxOU
uDukt+ZIIiP7GwPYxqSknR4lcuwsdFFJf9ldxD+ZRNsmz1l+PkaUUpdkCc9u9rUW
2IyfvPmeeVUPLP9N675kfiM3aKNO7LHN8GhSUe+1Nt/zcXg6xg0QWKdXjC8nykCa
eH9gn0QoQZaZbfKnb8DLwLjCO5LiOzQTgqdo0ZSJtV/CipqyGcBJtFYW2olG/BvO
Ns6qJKG6Ck76Tv31cu3YGpVbBjCxsIovchLh72KjQ9LscYg8y29evcFlnyagsewY
5CQJsAY8apmvNvmxAhRf
=oRV/
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/57fe1c6f/attachment.bin>

2023-06-07 17:33:30

- reply

📅 Original date posted:2015-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/07/2015 03:27 PM, Jeff Garzik wrote:
> On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier
> <justusranvier at riseup.net> wrote:
>
>> To be extremely specific: should Bitcoin development
>> intenionally limit the network's capabilities to leave room for
>> other projects, or should Bitcoin attempt to be the best system
>> possible and let the other projects try to keep up as best they
>> can?
>>
>
>
> Avoid such narrow, binary thinking.
On 05/07/2015 03:25 PM, Peter Todd wrote:
> Altcoins and non-Bitcoin-blockchain tx systems? Assuming anything
> other than honest intent isn't productive in this forum.
>
In summary, I asked a question neither you, nor Peter Todd, want to
answer and want to actively discourage people from even asking at all.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVS4XZAAoJECpf2nDq2eYjwZcP/j4ypIBctC4Wt71KJCx4eJ3u
u8DQAJKKr8BfL/zDu5bwVz0qbIX1+Wv9EwkBSYuYQaLDozDCnlttptr7qNWm62QI
d5Z6HUU+g/Zbk2DSgVK57Hf3G7pzcodRq+fp6O/kNgtdE9OyZnv9giApd6F1Yy7l
wgZxjlpKGMA+qKigHSHIQyu1L2JfWjw7eEiirnDtFaCgTpJqPErigX+2eMdpj8/r
jTP3mEN2qStWYydWfYxfcM68gOZsvFiVBfT7qTkFXSeOdigC4bHMDMew9nqP1hlB
9uo/JESNQ4Z0/WHgDSn9fLbc/UX6SIPVn7vDAj7mZAeyaXYBrXhbHpdqhnOGhDmt
R9aUopGHleY44RujES1rQWSo6D8SWlbmpXThgHU5rlRFKKSCu9/s99s7kVdLFqpS
bGg42qs1LwxDiq2TuMV/9TuP10ibB4mSnKwaglcAHcrbo26ZdMF4T9YwKcEmHIrv
0hCUA0qyvKP3fqfQUVzcssJfWdvjx7/bnwLadrxSOur1IZj+2jJdzPYsT1tSiwL/
XChSN5a00LJWW5+b0ka155sEg8XcBdUECXIQtRpFedCURjeinGuMnEf6gM8NbcNS
yVm5Kptf8BO11r154J93nkc3gU4VFcxudg8smaDcq3amPDkyaNBXQm+rcwIApchL
SOzHWwxtA1q+pLHvxnlk
=Fcdg
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18399 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/9cfc7eb5/attachment.bin>

2023-06-07 17:33:30

- reply

📅 Original date posted:2015-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/07/2015 05:04 PM, Jeff Garzik wrote:
> heh - I tend to think people here want bitcoin to succeed. My
> statement refers to picking winners and losers from within the
> existing bitcoin community & stakeholders.
"Success" is not a sufficiently precise term in this context.
There is a large contingent of people for whom the definition of
Bitcoin "success" means serving as a stable backend which can meet the
needs of their non-Bitcoin platform - and nothing more.
To be extremely specific: should Bitcoin development intenionally
limit the network's capabilities to leave room for other projects, or
should Bitcoin attempt to be the best system possible and let the
other projects try to keep up as best they can?
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVS4HiAAoJECpf2nDq2eYj23wP/j4ksm2dgzDkccMRbqFM8Pm8
oV6ImxM26bG3DJB+Rh6ttTY4DrUnZJmzQUUxfZUd3TmH/xOM4Lu35gKKhpvHTdR8
vMQz76CaTba6PzzFKC+GYyHueXLtwJxEHEZjR8m5ijPMfZoImfMbduggDaPLv/sz
AUcTDtYWBoPZ9Matms4NZIOsH1S1pHw5YjcFYgxmY6ErHZPqZjoKzcc4wZnrOU+Q
HCmiHOJ1U87jEge4QEJCXidCJFakyMTWt5P6hjdOFfky3VYmcoivYRA1ZemgyV2Y
YyLtmHBcK7k67Tczep8rjggvK2C2oJArFGPLWHZH9bxXILaNXSpZX5G5rXZjp1vm
1voc6JDaK/slXIlfG+BZ56WyprKkiFbN6u4Wd8LG5W8gKiuCyLYr2IGKz9O3fvor
NYtk6ELPfX1+0JBD0ureI7kV85D/ybNnnmMp/NyfmBKzzmqnANRrrqL5zgILuUP4
YaokcVdPpTqkN0vuAXchehEemF5MtJIYf9BayZ86ck68aMjvVJi0nX3n63f1MulP
IbRbYY/8eu1891lNIPiSzbmT0zjjplo8jYEOTg32mIvEDZAy8sWwTPYS25tPd37l
3kxRCxqS1ALbAqLZprmxQ375PigE2esXZlpBHzyY4Kf+3UD/k/X8D92vdNiF7mkS
HSA+TX4lf310Eq6Mb4LR
=5vaU
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/93fd7d2d/attachment.bin>

2023-06-07 17:33:29

- reply

📅 Original date posted:2015-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/07/2015 04:04 PM, Jeff Garzik wrote:
> - This is a major change to the economics of a $3.2B system. This
> change picks winners and losers. There is attendant moral hazard.
This is exactly true.
There are a number of projects which aren't Bitcoin that benefit from
filling in the gap left by Bitcoin's restricted transaction rate
capability.
If Bitcoin fills that gap, Bitcoin wins and those other projects lose.
Should decisions about Bitcoin development take into account the
desires of competing projects?
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVS3jeAAoJECpf2nDq2eYj3hMP/0yk8HxypEfNa4vZo0IcKD+p
bn2dftQsOEeOenBh8QT48vS3AhcjNkUsw722YwbKz6Znkyi2iU7njaUM9DV+QHwg
Oytmh8XVZtviLgg3854ujdj4oAWyP4DpppVTRxTDyRdSpRj+D9y6+sGFls6z0q3/
XRcKOY23zx6/qN1k5fqUncpIpYEDhpmE7cGy26Yz0G4MtuYeceHT4LdJAHHr0iFL
OY0WVM32b4F3HfkfJtt8rE0yeB7u5dbeu8KmLB0yqZQkY87sLxtT6qeoyHO6CG+N
8Iu9OWaRIZHfrZK2XlDzDKQIkTnlSxFtj4wY7/Yb4NIDO6mhMjYTSz8lWqN4ofKg
9fFHlwGS3QXXDTB+5d1IzZS5C0qF92n1NJiJjkLqhKqYuVn4U74oslZhVLxHBGHH
ZAvW09obZXi5DVzhuxPzlFkpYaB+XLdmBUPEr5hx5K4I2qiL/Nvu0h031UDcMeLm
x9mEHO5ZODlF9tWAVnM/b0VtwT9h6Q88NWe/OUQQZKp6D/Etcd3JE55GBNtNPDnE
2UubyHkNO4mbrEMluh24TvhZK3BB/lieq+kkHZCP7eC58eRY078lSF8R36XGdbn4
Pili15bYSrRrfmjDz24zhJX8759LPt2Zsf/Irc8Za4SoaEaYAqQU4vAmYlZyCNxj
EvxXAasffnjR2K3cnZxr
=YkTz
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/08be2d04/attachment.bin>

2023-06-07 17:33:29

- reply

📅 Original date posted:2015-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/07/2015 04:49 PM, Peter Todd wrote:
>
> I think we'll find an basic assumption of civility to be more
> productive, until proven otherwise. (e.g. NSA ties)
I'm not sure why you'd construe my post as having anything to do with
accusations like NSA ties.
By "non-Bitcoin" projects I mean any altcoin or off-chain processing
solution.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVS4EeAAoJECpf2nDq2eYj/vcQAIUrD+ejUKHQb0k/pcPyzmvy
rl3spbbdLSFN9cBhBOgh5LaVFkCrv4/gW2X4Ih6GGYG3siXjZ2HPDXt+Zbs+bfQE
nrw+IpGTYlbnJ26cFVhZWehr45qY1kMO+DVdnKufEgfVKUdYeq/d3bwL1uru4RU6
UfWihvgGGQkjEb/5ZIpRbWmb7XRP9piZCHi0pgFSa8tNDVjbb9ucKjIfrRuRe+DK
GMhIAQLvIQK4M30SxOnMQLIe3upsQ6JzY+5M28HkcBNKgd0dpZbwByHIJh6/ELTO
Iaf08S0mCySKoZAJFEkeQ3YOgdIlZvwYsflxiEs62Mz9Mz8uuxTo6E21XyFr6iN/
XndXCzlAZBIQuiayEUL4fUM2cmeHcvhHpGNyYjBuLibuiaIzKMBzFQqEZHGA0QzH
QhptbHjTwXLxIEZy94ELH2FbQnTrnOBxOdYfmxGvlmJ0328hThW6N181L3fPHK0v
6zTChZziMhlIoZPX8AGNNsUYJFKBJs/khlbse/tQhXmm5zuIyq+Lt0nKjbhHkWJw
n9y4PHxLVtmmOvptPMm00l5/w6yb8Qmxo81d6kq75ZEupjxupHH6YwjHWTehT/x2
Pt8iMX2NWVnVwVdsaqE/rH+JrgH1Pvl7TMqXMr8d7tuSWTeTBWlrcmZbS1rl0Z3T
f8K2rBX6sBqmrD1xKDsn
=5pB6
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/4f43f1c8/attachment.bin>

2023-06-07 17:33:17

- reply

📅 Original date posted:2015-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/07/2015 09:54 PM, Jeff Garzik wrote:
> By the time we get to fee pressure, in your scenario, our network
> node count is tiny and highly centralized.
Again, this assertion requires proof.
Simply saying things is not the same as them being true.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVS8QWAAoJECpf2nDq2eYj+/4P/2JXxo2RDAg0ptd9aUYVvzp9
KhL33cdmK8kbKBFOVcOuIrlQRzZn9iydIPC165Y40Y6Wrtgw2PoXctuqdQdXaSZI
M3bHuM7mweHyb3xBHNaNHIxfwrMjQQAdOTGO7PZusghDYz2QEj44dhIcNOzO7uTD
fXkhzgJfwu0l0Wqn3v/R9amRUWLE5nlM566xJ2sVtlfBMEyzR5L1GwX1lKNhxeO8
qvkgegsF2Usjz9pIUMSGFxSWZQuTSjHbhbh28JaT/wi6DI3pcTV0FPw95IPImqUh
rbIqcPh43omXrHKEHV/FB+XMItD3VvR9dxogYaFZLv1EU2gnF2IM0cw5a/oyHr+L
C920uEbXrvrMEJw1ftvxQyu6NY5c3/5iVMqz773oQSjOihkZ8P1JvxQnldU6mcoU
RaKM13cxgjSkCqJ5R1iIldFQPCLLWUKJDkPEnGlwdLPF/vwhnCt1PZJTB5hqoCgC
ab5yBVLpLgo7sbizOeX/R3WGp3NjGXDQC93Af/Vr37uiu1ZT+1P1Ow86hsZTRx6b
4d25tSGg7Tw3Bs/YOhJ9AKtlN092Y8/WBMscQu6MaFt6I/1OMX9OVH+veEj/VjwB
L/dxWTRdC0HEKiYv+EuESIRoyTLlCHKBUDBgKbYSMjetg6WW64hYrpxNX7TH20o6
00bWPVV2PcEWuCc230UF
=1bK6
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/a275c96e/attachment.bin>

2023-06-07 17:33:12

- reply

📅 Original date posted:2015-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/07/2015 03:35 PM, Jeff Garzik wrote:
> Raising the block size limit then becomes a *human decision* to
> favor some users over others, a *human decision* to prevent an
> active and competitive free fee market developing at 1MB, a *human
> decision* to keep transaction fees low to incentivize bitcoin
> adoption, a *human decision* to value adoption over
> decentralization.
At the moment none of the following assertions have been proven true,
yet are constantly cited as if they have been:
* A competitive fee market will develop when the transaction rate
becomes constrained by the block size limit
* More users of Bitcoin means less decentralization
Furthermore, the term "decentralization" is frequently used without
being precisely defined in a way that would allow for such proofs to
be debated.
If there's going to be a debate on those points, then the people
presenting points on both sides should take the time to show their
work and explain the methodology they used to reach their conclusions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVS5BXAAoJECpf2nDq2eYjC3kQAKQ0Jj8r1gjwpl813NiuatjA
nwXJ+Zn7E+cS8bYsXbaPK1uUgcSdpi/g2jgW+VuUPlqCaNo08Pbp/O7pG5ady9st
o7xJnPxttg7NO3IB7GODCJKK85uBO3dOwPp+pfs8KYCAo5PFTflpeOi4Idbd4w/R
+tvLynpSX9LIZTQaJH2KEbrYUibYHZrr8hj0net9lJP8KeqMnCuiesYzjJ4pUXyE
zN0SQ1v9QnpltbTVxRu1TdRBMjAxEHTJPg1jsv0hhGqIOQGHdwNavGq7+LJBen4T
CvT8ooTmuq0IdihOTttl9ody6Eh0tyGPlbVHiI3c2Emm0HTxz8hN9Rl4lvPgcGdi
EUW12h8ailKLg5uJL53Zp1PO6fgl0Z/WCx/zqIKRPg4lJMf5Rk5Ow86xAeIZrsbr
d/+cJZEhqzPnObxkxgTIzqtG8NHcg9dhKw1xkGAkVpMXMM7Bzdku8WCntIYU4+xI
btQQZlbc5h/S+X9Vcu0rJWmmQp2Q8xeEVGRh4hhA8LZLc1P+1eyESjAMWvsuq+rk
Wd1kPopekhOgK0zw2j55Ov+kJXVa2pDFA7TOpcqxbdLU4eauKC4D+YQlTM4qj285
vyRq+c/AwMCPiEhBeEbppgdgwrIQP9fJ7s+2TAHaWICYlTJWkLitUjN9EBwqv3Yp
LRBrgV7giz8UIrJr3hQZ
=+Qmg
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18399 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/94cff866/attachment.bin>

2023-06-07 17:33:04

- reply

📅 Original date posted:2015-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/07/2015 03:49 AM, Peter Todd wrote:
> I'm not sure if you've seen this, but a good paper on this topic
> was published recently: "The Economics of Bitcoin Transaction
> Fees"
..for some very strange definitions of "good".
That paper may present valid game theory, yet game theory has a
well-known limitation when it comes to predicting real world behavior
in that the predictions are only as good as the simplified model those
predictions are based on is accurate.
At the very least, we should wait to draw any conclusions from that
paper until it has been sanity checked by a praxeological review.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVStYTAAoJECpf2nDq2eYjqzAQAJkLwVq3cJxaP5MirS6j+SkN
NuRIQS8EzJkvojZvHCSRz3xPZpl9Cx2T6/hsLjIfzvMuDHKsaOkkLlL0q95ekv4T
acfami64326DFAxiO0ptspPjCRipagmjSEwZGZwC/QZtTdnt+N9LsH0SFDP6hxbY
Kf11LRd11Ap4v/VnBg/zb4daZnVm0k0nfZxK4rG1zN14r5JEu6eiodUBZc6e4qih
LmopoddIwJS4MY1GoR2kCehAbJseZZyQQmHFEX1Vhc74ETGXWApfgF0tpo6ZMutd
OT0WGhCpj4yG1u5bRaiNnsOy9WcBTKzDOLZUVVh/GhUGHWUulZu8ujYrX7Q6GR5S
VPvOOL6Ts/RGEAE1UWKzHfPjrLZAHKgLAzBjm6o1ZXdBcnV+FsThNvd7fxHvaJsO
pWGSu8qDmN/wH657Tphbthb4T/awnuf4rO6oBP+OGu+ydPIlIlt6rM2E4Bq366yy
CJbzSR3x/P7fRmT2bbSg4rxTDyLFJpNIWOcNaMRBeO69OdNZxlranvFvEl/6FfqK
GO/LPQiYCe/+yhXgUJzzlYpayPiPFWCg0FxwQ+xl1josTsrfPE4BUivkZvIlqOIY
LX1fDHt/IIUNp8OUkY2eERxeB//dlY55nP7VGUEJLNnBkXuoBd70lMtGXxtgvw2M
Wy5VER9CiEOUMMwzWi3Q
=8mit
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/7528c1aa/attachment.bin>

2023-06-07 17:32:47

- reply

📅 Original date posted:2015-04-24
📝 Original message:Taking the hash of the secret would then require an extra step to make sure
the hash is valid for secp256k1.
Using the x value directly avoids the need for that check.
On Fri, Apr 24, 2015 at 10:35 PM, Patrick Mccorry (PGR) <
patrick.mccorry at newcastle.ac.uk> wrote:
> When computing the diffie Hellman secret - why do you choose the x
> co-ordinate instead of the hash of the secret which is standard practice
> for stealth addresses
>
> Sent from my iPhone
>
> On 24 Apr 2015, at 21:27, Justus Ranvier <justus.ranvier at monetas.net>
> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Hash: SHA1
>
>
>
> https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
>
>
> This link contains an RFC for a new type of Bitcoin address called a
> "payment code"
>
>
> Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
> addresses which provide useful features such as positively identifying
> senders to recipients and automatically providing for transaction refunds.
>
>
> Payment codes can be publicly advertised and associated with a real-life
> identity without causing a loss of financial privacy.
>
>
> Compared to stealth addresses, payment codes require less blockchain
> data storage.
>
>
> Payment codes require 65 bytes of OP_RETURN data per sender-recipient
> pair, while stealth addresses require 40 bytes per transaction.
>
>
> -----BEGIN PGP SIGNATURE-----
>
> Version: GnuPG v1
>
>
> iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd
>
> JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa
>
> Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz
>
> QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG
>
> NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR
>
> o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo
>
> 2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h
>
> /wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9
>
> EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET
>
> n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI
>
> OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+
>
> SGApMBd4Q89fKzL2djae
>
> =Dypr
>
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
> _______________________________________________
> 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/20150425/40b3ed26/attachment.html>

2023-06-07 17:32:47

- reply

📅 Original date posted:2015-04-24
📝 Original message:On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier
> <justus.ranvier at monetas.net> wrote:
> > Taking the hash of the secret would then require an extra step to make
> sure
> > the hash is valid for secp256k1.
>
> The x value may not be a valid member of the group, effectively the
> same as with a hash. Its also very unequally distributed, as only
> about half the possible values are points on the curve.
ack
> > With 97 byte standard OP_RETURN values the ephemeral public
> > key could be appended to the chain code, but that's undesirable for
> other reasons.
>
> Can you elaborate? Storing a ~33 byte (deterministically generated)
> ephemeral key should be all that is required. Everything else,
> including the chain code could be derived from it. What reason do you
> have to include additional data?
>
The goal of the notification transaction is to send the same payment code
to every recipient, but obscure the identity of the sender of the
notification transaction from third party blockchain observers.
The shared secret is used for that purpose, and the sender's public key
used for ECDH can't be one derived from the payment code since the
recipient doesn't yet know the payment code.
The notification transaction needs to communicate the 65 byte payment code
along with one ephemeral public key used for ECDH. If that ephemeral key is
not located in a signature script, it has to be somewhere else (such as in
the same OP_RETURN output as the payment code.)
> > Taking the SHA512 of something less than 512 bits seemed wrong.
>
> Why should it? Adding the Y does not increase the entropy at all. As
> an aside, I think this can be reformulated to only need 256 bits of
> output, and then the need for yet-another-hash-function could be
> avoided in some cases.
>
Already fixed in
https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521
but it would be good to get confirmation of whether the way I fixed it is
valid.
> In this proposal I optimized for non-reliance on third party services
>
> The requirement for inputs is a guaranteed dependency on third party
> services; so if thats whats being optimized for here it must go (well,
> I think it must go for the reason of avoiding blocking users from
> using other schemes to control their coins too..).
>
I'm not sure what you mean by "the requirement for inputs is a guaranteed
dependency on third party
services"
At the proposal currently stands, an SPV wallet will have no trouble
sending or receiving notification transactions without access to a third
party service. The recipient just needs to see the transactions associated
with its notification address.
The point about restricting the types of scripts used as inputs is valid,
but I think workarounds are available. If nothing else, the sender can make
a suitable input using it's own (suitably mixed) coins first.
> I agree. I could not find a straightforward way to express a
> multisignature payment code in less than 80 bytes.
>
> A prior stealth address proposal here handled them fine with only a
> single ephemeral point in the op_return. It does result in a longer
> address (is that what you're referring to with '80 bytes'?)
>
I considered defining an additional path level for deterministic m-of-n
multisig and adding a few bytes to the payment code to express those
parameters, but thought it would be too limiting since it would preclude
multisig with truly independent keys. It is a thing that could be done,
however.
> Exchanges could restrict bitcoin withdrawals to a single payment code
> known to be associated with their identified customer.
> > In some jurisdictions the ability to prove that withdrawals are sent to
> a positively-identified party, rather than arbitrary third parties, might
> move some Bitcoin businesses out of money transmitter territory into less
> onerous regulatory situations.
>
> But this mandates horrible key management practices, reliance on a
> single "hardcoded" private key which you cannot change; even if it
> might be compromised or lost to the wind. It's less horrible than
> sticking to a single address because it doesn't wedge privacy, I
> agree; but care should be taken that a tortured dance for confused
> regulatory cargo-cult reasons doesn't mandate people not engage in
> sound practices like periodic key rotation. :)
>
Cold storage is still available (if admittedly less convenient than in
traditional wallets).
I would expect exchanges in practice to allow for payment codes to be
changed, just with non-trivial waiting periods and plenty of human
overview. It would be an infrequent event compared to the frequency of
withdrawals.
Various schemes which use public key authentication instead of passwords
for web site authentication could be used to continually verify that the
user hasn't lost access to the key.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150425/acb86657/attachment.html>

2023-06-07 17:32:47

- reply

📅 Original date posted:2015-04-24
📝 Original message:I have pushed an updated version of the proposal which incorporates some of
the received feedback and adds a note about the consequences of sharing a
payment code-enabled walled on multiple devices:
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521
On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier <justus.ranvier at monetas.net
> wrote:
>
>
> On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>
>> So this requires making dust payments to a constantly reused address
>> in order to (ab)use the blockchain as a messaging layer.
>>
>> Indeed, this is more SPV compatible; but it seems likely to me that
>> _in practice_ it would almost completely undermine the privacy the
>> idea hoped to provide; because you'd have an observable linkage to a
>> highly reused address.
>>
>
> I agree that the output associated with notification transactions would
> require special handling to avoid privacy leaks. At a minimum they'd
> require mixing or being donated to miners as a transaction fee.
>
>
>>
>> It would also more than double the data sent for the application where
>> 'stealth addresses' are most important: one-time anonymous donations
>> (in other contexts; you have two way communication between the
>> participants, and so you can just given them a one off address without
>> singling in the public network.)
>>
>
> Communication is only one way, except for the case in which the recipient
> wants to send a refund. Assuming no refund and only a single anonymous
> donation in the lifetime of the sender's identity, payment codes would
> require 65 bytes vs 40 bytes for stealth addresses.
>
> As soon as the sender sends more than one donation to the same recipient,
> payment codes show an space advantage over stealth addresses.
>
> This kind of binding was intentionally designed out of the stealth
>>
> address proposal; I think this scheme can be made to work without any
>> increase in size by reusing the payment code as the ephemeral public
>> key (or actually being substantially smaller e.g. use the shared
>> secret as the chain code, but I should give it more thought)
>>
>
> With 97 byte standard OP_RETURN values the ephemeral public
> key could be appended to the chain code, but that's undesirable for other
> reasons.
>
> This is fundamentally more expensive to compute; please don't specify
>> "uncompressed".
>>
>
> Taking the SHA512 of something less than 512 bits seemed wrong.
>
>
>> This appears incompatible with multisignature; which is unfortunate.
>>
>
> I agree. I could not find a straightforward way to express a
> multisignature payment code in less than 80 bytes.
>
>
>> I'm disappointed that there isn't any thought given to solving the
>> scanning privacy without forcing non-private pure-overhead messaging
>> transactions on heavily reused addresses. Are you aware of the IBE
>> approach that allows someone to request a third party scan for them
>> with block by block control over their delegation of scanning?
>>
>
> I suspect this is a case where we just can't have all the features we want.
>
> In this proposal I optimized for non-reliance on third party services and
> a guaranteed ability to recover spendable funds from a seed backup.
>
> Gaining those two features resulted in some tradeoffs as you noted, but I
> think there are enough benefits to make them worthwhile.
>
> In particular, payment codes could be the basis for a Heartbleed-free
> payment protocol that can positively identify customers and automatically
> provide refund capabilities in a merchant-customer relationship. A merchant
> only requires one payment code which they can safely use for all their
> customers, meaning they only ever need to associate 65 bytes with their
> identity to allow customers to make sure they are paying the right entity.
>
> Exchanges could restrict bitcoin withdrawals to a single payment code
> known to be associated with their identified customer. This would make
> thefts easier (without involving address reuse as in locking withdrawals to
> a single P2PKH address).
>
> In some jurisdictions the ability to prove that withdrawals are sent to a
> positively-identified party, rather than arbitrary third parties, might
> move some Bitcoin businesses out of money transmitter territory into less
> onerous regulatory situations.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150425/1536c9c0/attachment.html>

2023-06-07 17:32:46

- reply

📅 Original date posted:2015-04-29
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/27/2015 02:53 PM, Brian Deery wrote:
> 1. There will be a 1:1 relationship between a payment code owner
> and their identity. Presumably the payment code would be strongly
> and publicly tied to the identity. This makes the notification
> address strongly tied to the user. An SPV client connecting to a
> full node who has a list of notification address can tie an
> identity to a bloom filter and connecting IP.
I've updated the proposal to provide for alternate methods of
notification that can be used *in addition to* notification transactions.
This frees the sender from constantly monitoring an address known to
be associated with their identity, although they should check it
periodically since not all senders will be capable of using every type
of alternate notification method.
I defined a Bitmessage notification method as an example; more can be
added if required.
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVQWzPAAoJECpf2nDq2eYj8uAP/RsP050K9z8oDGy0KO+zjFwM
iNzlsQaPY8kmR2k2oLXJp1n4QZIQAZly+vxjBZnOWXwAhrBcvnhNBvqdigwZYg3B
oGyvGvArzkve86Ke1WF1hZEAvml3cmQ5jxYKMlwhzRPcHq2kwznw+5jRuTbf1JbE
PxY5pOfnZ9ADVF5FkLR2KwBNvGA83Cle01hKd0eB6Omlb6azKDBXUqfzPPpB4lmp
A8D0P3zkayzBYIiybUExfPJHUthd5wXL/TLwFkysPV7SnJE64C6Q2StD4wUtNQRS
LDOw37RwhMx2Oz2YH3Ywi6w5tqYQP4LEWBuFb+LOqqphpV/FpFDl/Uznos00pz61
V9x2wrfg+MQnYk5/VIjPQxqvRsiu8yg4c2x0v+KIIMsuXKEPRFxaSS3DoaWUa1Jy
+WDobHndIDw1TDqctP8LIiZ7zbWNYKJ4HgUaacHvTiA7TrJXi1KHo2b1pmnTbKhv
fdHbjzd8UiMED6qeyrz1gGhjC2uSTwjZAmbBkCJccOGsrILoV1fifUW+de8qsBMH
6w6RiDwfeY2fHJHBS6O2Nhfk3OE5JaCWvy727ZXEq8lQ6dW0GOZvXg7INaktLagC
tqvg85J5eCm7X8xQ33vgx8q2xt+IriMI2UnTILtb2H8XSiMRQSP7XfWDMfVGu4pb
xbGZKbNS4WS+2FFKM4DK
=6l99
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18399 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150429/878dfe29/attachment.bin>

2023-06-07 17:32:46

- reply

📅 Original date posted:2015-04-24
📝 Original message:On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell at gmail.com>
wrote:
> So this requires making dust payments to a constantly reused address
> in order to (ab)use the blockchain as a messaging layer.
>
> Indeed, this is more SPV compatible; but it seems likely to me that
> _in practice_ it would almost completely undermine the privacy the
> idea hoped to provide; because you'd have an observable linkage to a
> highly reused address.
>
I agree that the output associated with notification transactions would
require special handling to avoid privacy leaks. At a minimum they'd
require mixing or being donated to miners as a transaction fee.
>
> It would also more than double the data sent for the application where
> 'stealth addresses' are most important: one-time anonymous donations
> (in other contexts; you have two way communication between the
> participants, and so you can just given them a one off address without
> singling in the public network.)
>
Communication is only one way, except for the case in which the recipient
wants to send a refund. Assuming no refund and only a single anonymous
donation in the lifetime of the sender's identity, payment codes would
require 65 bytes vs 40 bytes for stealth addresses.
As soon as the sender sends more than one donation to the same recipient,
payment codes show an space advantage over stealth addresses.
This kind of binding was intentionally designed out of the stealth
>
address proposal; I think this scheme can be made to work without any
> increase in size by reusing the payment code as the ephemeral public
> key (or actually being substantially smaller e.g. use the shared
> secret as the chain code, but I should give it more thought)
>
With 97 byte standard OP_RETURN values the ephemeral public
key could be appended to the chain code, but that's undesirable for other
reasons.
This is fundamentally more expensive to compute; please don't specify
> "uncompressed".
>
Taking the SHA512 of something less than 512 bits seemed wrong.
> This appears incompatible with multisignature; which is unfortunate.
>
I agree. I could not find a straightforward way to express a multisignature
payment code in less than 80 bytes.
> I'm disappointed that there isn't any thought given to solving the
> scanning privacy without forcing non-private pure-overhead messaging
> transactions on heavily reused addresses. Are you aware of the IBE
> approach that allows someone to request a third party scan for them
> with block by block control over their delegation of scanning?
>
I suspect this is a case where we just can't have all the features we want.
In this proposal I optimized for non-reliance on third party services and a
guaranteed ability to recover spendable funds from a seed backup.
Gaining those two features resulted in some tradeoffs as you noted, but I
think there are enough benefits to make them worthwhile.
In particular, payment codes could be the basis for a Heartbleed-free
payment protocol that can positively identify customers and automatically
provide refund capabilities in a merchant-customer relationship. A merchant
only requires one payment code which they can safely use for all their
customers, meaning they only ever need to associate 65 bytes with their
identity to allow customers to make sure they are paying the right entity.
Exchanges could restrict bitcoin withdrawals to a single payment code known
to be associated with their identified customer. This would make thefts
easier (without involving address reuse as in locking withdrawals to a
single P2PKH address).
In some jurisdictions the ability to prove that withdrawals are sent to a
positively-identified party, rather than arbitrary third parties, might
move some Bitcoin businesses out of money transmitter territory into less
onerous regulatory situations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150425/c29abbbd/attachment.html>

2023-06-07 17:32:45

- reply

📅 Original date posted:2015-04-27
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/27/2015 02:53 PM, Brian Deery wrote:
> 1. There will be a 1:1 relationship between a payment code owner
> and their identity. Presumably the payment code would be strongly
> and publicly tied to the identity. This makes the notification
> address strongly tied to the user. An SPV client connecting to a
> full node who has a list of notification address can tie an
> identity to a bloom filter and connecting IP.
SPV clients that connect exclusively to hidden services through Tor
could mitigate this, especially if those clients broadcast their
transactions through different peers than the ones they use for
checking their balance.
Maybe they should even go the opposite way in terms of the false
positive rate.
A client could create a filter that *only* matches their notification
address and use that filter with a selected peer.
All the rest of their addresses would be contained in a different
filter that is never sent to the same full node which is watching
their notification address.
> 2. The client can use a bloom filter with a higher false positive
> rate. An active attacker can counter that by sending several
> payment codes to an individual user. The user would then add to
> their bloom filter all the shared addresses between them and the
> attacker. Even with a high false positive filter, always matching
> all the attacker's payment codes would strongly tie the user to the
> filter.
I'm not sure this problem is solvable in general.
Any entity which has sent bitcoins to a known user could use that
knowledge to attempt to find their bloom filter (if they use one).
I think that for SPV to have any privacy at all clients need to get a
lot smarter about how they use bloom filters overall, such as by
connecting to more than one peer, only putting a subset of their
addresses in a single filter, and temporally varying the addresses
which they watch.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVPlu8AAoJECpf2nDq2eYj/cAP/iL9qlIkk/jz2N3mT4dIdrSn
rQ+m7dHOSeucUhePrjdM79VzDUQWGmewdi5a1e8wCL2PCBeq/7mapEpHrvWu3xUU
g0qtCa6CbSceW5pO1/BGnKpt298wrBIueeweR3/BPum90RrXT+T/ssQvjGvlY4Jg
ADFeH4axalmCkc87OsJhsEbAAbP9i/u96rItV9ECpOET9pRxp4PzNT/7nz/x5n+q
Lm/vuWy1yoWLUjXiAmXWJVzPs8+Pzf1liy3SEzkam156kUwTj/CqjI/uhf7heSx2
FYSswBc/R1fga7eu++Bm449KUTmyTnnEIT4109A1w18fidY2Dg6PpKYp5CGug96t
aHit1hqLfc8HpNUVWLrBrHsC7riy+QGta4Ie7fAl9SvFcNturkXBFxZLO8f34WMb
HFuWkcCAgZcS3hb1ShmyodMjnOWvHQo/dXAoUc+zI8yuiH9wAD6T4LOTkSwCjvvv
9y4Ia4Mr6v6oHQpUM8ddCMU4AyAYvZXFb68SsnWMZCCio3Ff9wqp2d690oSq36G7
jdjmxot7LrPMnJjNKwTl2jndDTB9Huh9sjWyE9gGBkkIib1purOYtucDsY3h6z7i
5ppG1KTph+xaOLMEvyJZyDNvPhrQGk1ll1kMoD2k7P/5OGV7QwQ0IxpoAqZ1uxJG
44rCXd7P+2R+Bza9qHSH
=d2l3
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18399 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150427/5ec2884a/attachment.bin>

2023-06-07 17:32:45

- reply

📅 Original date posted:2015-04-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The notification transactions are a pain point when it comes to
privacy, and yet they must exist in order to to ensure that nobody can
lose their money as long as they back up their wallet seed.
They could be treated as a backup, however, that clients would not
normally rely upon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVP5DDAAoJECpf2nDq2eYjdLsQAJ/nZKFavcJnCMUQ8hKp6dRq
2+7bAVIWYHuOV6sv/hvG2NaP3u24NYZ/Ji0oD3UAmkJxw9lsZuowwBBs+YAs6JAW
KHTl3QtwBh0IP/V90JOZ5Yn72YWXDsNbqy7R3JhEDKOu2wVeiLqWZ2EDgGwiZ0/k
aXFJbcVZEKttWYCNoZi0yRMH+S9gbi0LgOwvK9mRzF9IRz07SM1iKQeKPsW1X1UM
KNeikFROMS7dHTO5HRGyFcTSwhUf8RJq2kea+4sJtj8Vlb5rURuJanL3Fav+ZZjr
RWYubLp9EUrDMm9bciygL8+MKPas8hedHSW2JhjkshWYC/NoCXLBT6SGrrbj2SKL
zGGeLYknjwgLTCstKSQlXW3J/xcSFwBztr//o95SwRoIKI7jpuOE6cPfUZVEuTsU
Zm7IWuRw/1MMDF89gCtDkBJcX2mTARjiii1Hg0+7vCv6Q/fVgTNUvWEKeNtCNZjh
wOiwd4eP1gY4CwX68c+8CfF+NOSXImJTspZJvDQcTge1/bQJNOBn+cMYxjBcJsqL
ZUOvkWJqwiFERW7vjMhOVpqIyO38UluwsWgp7nlMl/npfv0ZDIrOqZrswHSTqfdc
P8gSaqvpc6cMaLL/ijvOtORkVB9ZlLmlTv6mIYWHeKEf6PjIOZEb2B75zPHFAvrz
TKLxjvWgvSJ4l5PrkCFA
=1Id2
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18399 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150428/c1551c94/attachment.bin>

2023-06-07 17:32:45

- reply

📅 Original date posted:2015-04-27
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/27/2015 04:46 PM, Mike Hearn wrote:
> So that's not quite what is meant normally by identity. It's not a
> government / real name identity or an email address or phone number
> kind of identity.
I expect that mappings would begin to develop between payment codes
and government / real name identities, at least as far as that
businesses which are required to collect that kind of information
would associate it with the payment code(s) known to be used by their
customers for their own use.
I proposed payment codes in this form because I'd rather see that kind
of mapping be limited to the application layer and kept away from the
blockchain/network layer.
Even if it makes certain kind of application-layer distasteful
behavior easier, it's a good trade if doing so can simultaneously
provide resistance to graph analysis and make transaction-level
censorship more difficult.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVPmusAAoJECpf2nDq2eYjhxIP/3Jw9f6kcEsdFTXouQ5+D5gb
MjM8AW7EEA6KXj2PqrPv/H/brorW9/Ugcc8KweCjEdJAKOJV/Bl6sP5ydSZT6pmj
A0IFIkbdxKLY9JC3BbmVHuiAFrsL1u2EX5arUC3WNAWeWlVEmAL92cSlAka4BBxy
P/wh8xN0b4hsgA602Y4Btkv2fBHLQI9NMxW3AsujP3/S78mSxwKQZz4lYAMCowu8
NL/3toaFhrUsdHsH301jNAnxEEOodMVGmgjg/ZSdvWeHwdsE2J8Q9AJqiFDswjU5
q2kZuKmuJ6EXcGDlhelUuUpfHO34qS3/dyTydcqFrYB6eynZ8nV6S1SHaSlDEM10
b95+EpfIENtYdgAqJxwfbqpibpSEIW7cxCAopF0sSbQ2qv8rwRrcIah7KeARCrc0
e+HDcyLhYkrWrlK28vVmIxkEiQ/nmkTu9dOfoVJgXxcVl9AkiHGjo7QICOZHqfRB
TOupk9UUHMmdfZC5vpj9rd+VSXJJEF19ZbGF1QsFSMuxjKTb9jAy7Dk6U/9/xK9Q
+mH6QHhKzNKb8GsiowZJq3bF2mEYqmh/BPyQ06gfDLM4yvlTb+k4R6brFzm7tkWG
49hREmHK9w/wZXnH0lMCqMHRY/YqQF5bR3ujq7pB0WHLvbvDoSvyWvGQ9cVrRA24
ASb47sR77R1LlZntoSyy
=b7HG
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18399 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150427/4683ab4b/attachment.bin>

2023-06-07 17:32:44

- reply

📅 Original date posted:2015-04-24
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
This link contains an RFC for a new type of Bitcoin address called a
"payment code"
Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
addresses which provide useful features such as positively identifying
senders to recipients and automatically providing for transaction refunds.
Payment codes can be publicly advertised and associated with a real-life
identity without causing a loss of financial privacy.
Compared to stealth addresses, payment codes require less blockchain data
storage.
Payment codes require 65 bytes of OP_RETURN data per sender-recipient pair,
while stealth addresses require 40 bytes per transaction.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd
JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa
Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz
QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG
NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR
o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo
2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h
/wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9
EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET
n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI
OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+
SGApMBd4Q89fKzL2djae
=Dypr
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150424/4954b46c/attachment.html>

2023-06-07 17:32:11

- reply

📅 Original date posted:2015-03-20
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -------- Forwarded Message --------
Subject: re [Bitcoin-development] Improving resistance to transaction
origination harvesting
Date: Fri, 20 Mar 2015 14:06:59 +0100
From: Arne Bab. <Arne_Bab at web.de>
To: justus.ranvier at monetas.net
Hi Justus,
I read your proposal for a bitcoin darknet (friend-to-friend), but I’m
not on that list, so it would be nice if you could relay my message.
Wladimir J. van der Laan wrote:
> Experience with other networks such as Retroshare shows that … in
> practice most people are easily tricked into adding someone as
'friend'
This argumentation does not apply to the friend-to-friend connections
in Freenet, though, because in Retroshare you need friends to be
connected at all, while in Freenet adding Friends is optional. They
were made optional in direct response to seeing people exchange
friend-references with strangers.
An important aspect of friend-to-friend connections is that they have
to provide additional value for the communication with real-life
friends. I had few darknet contacts in Freenet until I started using
messages to friends for confidential communication (in which freenet
traffic provides a cover for the direct communication with friends).
For details on confidential messaging as additional value see “Let us
talk over Freenet, so I can speak freely again”:
- - http://draketo.de/english/freenet/connect-speak-freely
And for a description of capabilities freenet builds on top of the
friend-to-friend connections, see “Freenet: The forgotten cryptopunk
paradise”:
- - http://draketo.de/english/freenet/forgotten-cryptopunk-paradise
Best wishes,
Arne
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVDDnjAAoJECpf2nDq2eYjgwUP/3fRjH25OcGmG5AS3UE/wTvf
z8DrPieF4wtX4ABZTC6X/Ls9JnWeEhL3jN70SfGLzx2Exat620DVeR7nMHuQhLQj
6vWJSKLX8a0W47LmlAveagKeLMyQdOa1jZWZWJOUwxpoH0sHJwhBvRSiZeoHub2H
PI+WyivRy3aUhhAc4EkFlaFbJVl7JMjdaqEaoHV2l96fKkvuJOYfzKWuxYd0noTI
mgfDrXtm1zTH6H9C+B+AhXlDlaAnBoVr/EC7r4nKGeXGvOBw/UrAd/OHEySQJm6b
Quo8jPBOT8mwZVanJaAbRBDnOYXP4lIxkGaH5aXCWCReiepCPtUqbGF7hHXlAwGQ
LjpLr81Uxd/1TKk709FnSKtprSf6WdYmkzXCNjjPWLfd1bR7Yj71wtmDwPdy5IOS
W9TSD9gszD0BmiZFncD4lyKBFletfGlZaVirXNhwgEKBgRcS48AYc71IjWfjbq0B
P2wzevfdHJqda3Wr04H08pGNO9YeYVqJAvr7sqHaZdn7DyDdDhRehpzbgkphNU3c
Pr1XBTheFqZZTZSya1ufVR4y9c1qFeVx1T5pqVyfUt1nNA0oaHNm0tcCOKafNAyq
+9r9p08IXsjR44STpw/DHMERZ+W/XCJsACwWNo3BK7UumHlvaLoevmdmswghjblb
MQKLKZaKAZA56lvPymbC
=7CQT
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150320/88c95533/attachment.bin>

2023-06-07 17:32:10

- reply

📅 Original date posted:2015-03-17
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The ability of entities with large numbers of nodes to track the
origination of Bitcoin transactions is very similar to an attack on
the Freenet project.
The Freenet project addressed this weakness by via a technique they
called "Darket" - which means that nodes would only connected to a
defined set of trusted peers instead of being open to all connections
(Opennet) An individual Freenet node can operate in Opennet mode, or
Darknet mode, or mixed mode. [1]
This approach would be beneficial to Bitcoin as well to reduce privacy
leaks due to harvesting attacks.
Proposal:
Allow Bitcoin nodes to create authenticated connections with trusted
peers via CurveCP [2]. Nodes that have at least one CurveCP peer only
broadcast their transactions to those peers.
Use of CurveCP requires both sides of the connection to know each
other's long term public key. This key can be packaged in a structure
similar in concept to a Freenet node reference.
A Bitcoin node reference consists of a JSON structure containing one
or more "externalip" elements followed by one "pubkey" element. The
structure is then clearsigned by the long term CurveCP public key
contained in the "pubkey" element.
Users who wish to set up a secure connection between their nodes would
first use an API command to generate their node references, exchange
these files, and copy them to the ~/.bitcoin/curvecp directory with a
.ref extension. The node only accepts CurveCP connections from, and
attempts CurveCP connection to, peers whose references are present in
that directory.
Instead of listening both for regular TCP and CurveCP connections on
the same port, CurveCP connections would take place on a separate
port, designated by -bind_curvecp, -port_curvecp, and -externalip_curvecp
If -bind_curvecp is specified, the node will always listen for
incoming CurveCP connections, -listen=0 can be set to disallow
non-authenticated incoming connections.
Relationship with Tor:
This proposal would work along with, or independently of Tor usage.
The same network monitoring techniques which can track an originating
transaction to a particular IP address could do the same thing for a
node which is listening as a hidden service, and any technique for
deanonymising hidden services could then identify the point of origin.
Currently the only way to configure a node to submit its transactions
anonymously to the network is to make the node non-listening, which
means it can not contribute to the network.
This proposal would allow nodes to contribute to the network as
listening nodes, while retaining privacy with regards to transactions
originating from themselves.
SPV peers:
CurveCP connections also can be created between full nodes and SPV
nodes, in which case transactions originating from the SPV peers would
be routed as if they originated from the full node.
[1] https://wiki.freenetproject.org/Darknet
[2] http://curvecp.org
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVCFWiAAoJECpf2nDq2eYjsqIP/2Ri7gmJ1ULqRKh6k0BZskTh
zW2T+Bm+QgoTqiaoLSB61kX6IjwMdTTeVmzCn8ciRIUzvn+RD4843qG0vYKAU3BZ
o+7kMzfAn+KK/Y7j9S++FLteCs21GxsQfARwkKlJxvluoqxlIL50K5H1SySpmZMs
UKppgAIUpHv8H+5T4hwRlgM2vnZv7YyMqEpCDAsVWtQfyOg/WsftVP2UI4zsM3ei
KU36ztJYVUDqmnu3gg0mIW+lv/DqHk59d3Mo/gveRUUUTGzYXy7kKkubCzJQ5t7s
AgEdm5OmlKDEhZt/gFt6AA1FEjoQY+TzDSspFCJMiXmWQU7xu+wJwP7TBINXUbXr
7TNPC0KWHkBCa0ccKvP4O72dToPQM8LQl42My8ye0sUkfqAcOldRoqYBsnpqAdVv
ddvjSyr1wn1ek8bC7tjL1eRdjYz9PFeNayDv5vyur067DI5yjgpTXLjKVHxZe5TO
zA8MC8gp/mHDexO9+zmi+mFdPD/HiFl2liiLMsSg7pxGxMCy6cB8sUXHNPm6+vow
HHGgRWAVWVkTZNHc7n50+ugbtrudQaDOehVSH3NRLZC4pnRAg+pzZz/5Z/WWjr/M
mE1M3nbitCwznFpBm/Zgg7DUZq+MMTlUwsiNdGhyqYfadW7L5/vlp4d7otNoIhOz
V8zOgdC3ZwMfbf/g26PM
=u2MW
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150317/ec52079c/attachment.bin>

2023-06-07 17:31:55

- reply

📅 Original date posted:2015-03-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/13/2015 05:08 PM, Mike Hearn wrote:
>
> That definition would include all SPV clients?
Don't SPV clients announce their intentions by the act of uploading a
filter?
> I get what you are trying to do. It just seems extremely tricky.
Certainly the protocol could be designed in a way that provides
finer-grained access controls and connection limits, which would make
the situation more clear.
What I'd actually like to see is for network users to pay for the node
resources that they consume, so that anyone who wants to place
increased load on the network would compensate node operators for the
burden:
http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
Absent that kind of comprehensive solution, problems like this will
continue to recur.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVA2HLAAoJECpf2nDq2eYjcvYP/iqYBxboMmTPLp9Kx3GlBdR/
IPtCxVoaZQkqrAHlbbED1YHoI7QqaufdPMb9mw8bErFX7E89u4gD93jvx2x+skqW
KtqIyc5fHe4MgbtGypvE5GjSiqZZIqn7EYzLGVE5ydmO4SKpfodXIIRuQRkZ1fTG
j0ovFc/bmigS7Cvf3gsMT5oW26IcEaH6mAZ/YU5oVEi1LGff8hUTq90uddOCpoqp
mIj8MHMdd0yvtihjLwyJPdfT0qTOkbAxHJqwPLoOWzmrN0z1PbU9qcf0aHdDnMlT
+jWHqHzSxjwyB1bmUhi6vZKVFfd1moOTI3BBj+Jqjc+xaOmXCcyAtpfzq97VITZw
qhAnYM4unsC0A1GH3fQEJPvoOy0kwyNNtI7z5YOrRJtihCpFSbtULqN9DUmxwgKL
/0cmOc2SyjgflTiCejazBIJk4Ie+WcV2cbgepdX8USb0tusQs+jn2HMFGUfxywTz
riy9Ex8Wftl12LAYXSbMQl7GnADYG9t0HIY3JqPAhAzEdPynXUduveatiQyNc6SH
IqXraTgHj6IFFWB7eLjWuIleyxcFC81qTFNUYxEajGDLbCX00emKiR3RUpVZ/wP7
8CXcV4zco1y1+va1eD/7eNhTW/Xuf3+KdqJs2reLq23fLV01HA92sRYbgLIxb0Yz
yBsE+PpY06vrHqoVD/4l
=Ofbb
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/f9526c56/attachment.bin>

2023-06-07 17:31:55

- reply

📅 Original date posted:2015-03-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/13/2015 05:24 PM, Mike Hearn wrote:
> Well they don't set NODE_NETWORK, so they don't claim to be
> providing network services. But then I guess the Chainalysis nodes
> could easily just clear that bit flag too.
If a peer claims to provide network services, and does not do so while
consuming another node's resources, that might be considered exceeding
authorized access.
bitcoind should probably have more fine-grained control over how it
allocates connection resources between peers vs clients.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVA2bPAAoJECpf2nDq2eYjm/UP/0MZmdEBameT6tnLnebkru5d
UeHsX6Qikv3qF+i936SkoDylg08PJNWlpApuXC5t52x262V763y9tGV8qqh3vTSf
LeLeKY1M4mYCjHjegpz3JXzzF9i9OqgWl+0OxGOHDHyp8COfzKzC9FEUP3XBqitb
swyeS2t0LkzJnXYV8z8pDOxn4pZN0cUaKPvBIRKEUs4PgA4JVpRTM5Rvzi7oOItz
GHknxH++ja7kfFpgRSJMh3gHu4xhRiHfzGPaszrrrznpubNr42+4ouBy+QDr2XYr
1AtklROYLySeUtd0yNxeWdeaLIBSTiiDisNkD62MOTr0Zmdnc6M7IefSCqLN4fD9
wPu5a5h4HI/N/4/+kUhGmW+g5vagKMkCVlUIsG7gpGQJk4HyLElAdmgDToPJTrvr
htrd7k5HjjZu8oAt/vYcx15myuQ7VXc7v193g7m3kRRx4rnZ5XCu5BJd92uaOW1e
9ARhN7hfNQbfVkZw0f+qfG0fzMSAk3aHxpao7topwKARQfYJ++Mry5qAzFfxWred
IHXHbd4JqafsUJxTqDvm7oVP+l+XqlFkZTGi5u6NjPSeJL0IMFI5NqOepqAqwi0P
n9tePxN19+TmK2TSGtuzWBNZXcbwujSmvzRnDouxpcTyhRXc5YBbetI4/s0xcAyK
sQ2dm0SKF4S8MclylelW
=IpAp
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/e4196caf/attachment.bin>

2023-06-07 17:31:54

- reply

📅 Original date posted:2015-03-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/13/2015 04:48 PM, Mike Hearn wrote:
> That would be rather new and tricky legal territory.
>
> But even putting the legal issues to one side, there are
> definitional issues.
>
> For instance if the Chainalysis nodes started following the
> protocol specs better and became just regular nodes that happen to
> keep logs, would that still be a violation? If so, what about
> blockchain.info? It'd be shooting ourselves in the foot to try and
> forbid block explorers given how useful they are.
I'm not talking about keeping logs, I mean purporting to be a network
peer in order to gain a connection slot and then not behaving as one
(not relaying transactions), thereby depriving the peers to which
operator actually intends to offer service of the ability to connect.
That someone wants to run a large number of nodes in order to make
their own logs more saleable, does not mean they are entitled to break
the protocol to make other node operators subsidize their log collection.
Especially if a data collection company is deploying nodes that do not
relay and aggressively reconnect after a ban, it seems like they'd
have a hard time arguing that they were not knowingly exceeding
authorized access.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVA16sAAoJECpf2nDq2eYjxsUP/3ASGcsdGR8IEO7Fk8VghuVp
jwIIM8Bu/WsoWKG76GhuPKs/qC0VC6GXKpGUBVy7bF8uwdhfdSXcyld9MIzIENJF
I0wMX6B3SjqQG/g0rNZ91Dh3xKIF39/TQdDERM3yiQi1oavAc5TPLReN9ZbyRcVw
vCfPWorTvrad5INCn/krcEopbI013aW2ryWnkN6sFGinF5Yf4xhrNQbQeGbhlH15
/XUIBva6/PbUs4HaC+wqJPSUfB4OmcP1ZfXMuPDEmKEWdI+3WqUYF4sNAVOke560
+RL5qMJIxSUMYMAb3p+025Fn6WOc2wupQzpH/ISkuaI+5+ne54Mx/ZHJg7Z7inov
WMKfiUS6R8EHrY8IoNpO9uNqsgC+y0vlU3ELqu+gOhFTpMK7pVX2aAek8Qe7hSHy
GwtG5U6AFubLqyzP9/pBJHnmDG71brsKffAXOePDjXWfLfhy78aeQ3HOnzVhv9QK
snmE2C6Ex/tQDUwT9MKTdw59Hy7E7GdQlSPH+MYQKUBlkpWLDGpi7oriBRwvEy4/
NJCJU9+x7jijD7vrjBE+LSYdIQoZqE240N6teWqVc2wRPM8g+e+kSQqfjdKQdiQY
waeKHBKerqRq2EGffeJWV1RIEFtFND1l8zw/5ZQF4w959zLvhk/QPHzxKyTbCM2f
3DOgEWCJFLsNzpPQ8es2
=MV9D
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/dafc843f/attachment.bin>

2023-06-07 17:31:54

- reply

📅 Original date posted:2015-03-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Given the recent news about Chainanalysis
(https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/),
and other companies who are disrupting the Bitcoin network
(https://www.reddit.com/r/Bitcoin/comments/2we0d9/in_an_unrelated_thread_a_bitcoin_dev_claimed/copzt3x)
it might be worth reviewing the terms of the Computer Fraud and Abuse
Act and similar legislation in other countries.
Although it's not possible to stop network attacks by making them
illegal, it's certainly possible to stop traditionally funded
companies from engaging in that activity. Note there exist no
VC-funded DDoS as a service companies operating openly.
It's also worth discussing ways to make the responsibilities of
network peers more explicit in the protocol, so that when an entity
decides to access the network for purposes other than for what full
node operators made connection slots available that behavior will be a
more obvious violation of various anti-hacking laws.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJVA0IFAAoJECpf2nDq2eYjp0IP+wVsW69xOpFIX4yRTHrEQYh7
MCPM7OTkIay/O13TSewbxTRPww9Z6vOpmrDkFlWGYKyrLWyqUGwcKqOscE8r3P3U
xdV5ACppol5HXra/bykxuaXJWF/yTM7PybFNQ2Ary0X41CFrOUITsO8SwWDl8jBu
GtRgbWdALA6IQeeRLVQmMo3zC/uShOplOh/HrS2z9ZtXSm3rNkLzhnUWfznbixb0
9C1yvIM5VOwoNcRKt7uoX6cl4mFsBO3Gfjz4rr5gABerTltBlRk4c3jnUDUlQiFC
cppX9eaEYMLR7y0gHWnmzWcFW7LFwMR2isyJ79O2cpUpYNzbfp0fWetM1WVAMFSK
7hyUlwVx4WgaVRT5hDb6QPHHvzCYjYq+19+9/uChh9P3s3QkKuFJUVYwHQ+wnruK
hPS3/vb7Tmt1eLTUeno4RRyJJ7likHsNA2bxWSG9rDezTownkSVZe2BQh3GIZOBg
H8Nu2IDWK4pHJaCiswW4jfDsucuYiP7978p8ZFbZbymeflsXz1qyUHSVm9kngfZn
sYUK4rgRsdrPpong0nqlmWcQW3VgmNO1tw5gmUqWTxQLnrCxgqnSdT7srzAw1ZaS
YIAaB1rBy8k7QyDCOyIsIV+n1H26ZBa8PrqdRExlz6PuWcywjuEbcIfEl9QSURA+
pLuNJ+uQN+JBjKokmaSQ
=ZO1/
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/0fe22b36/attachment.bin>

2023-06-07 17:30:55

- reply

📅 Original date posted:2015-02-22
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/22/2015 10:17 AM, Natanael wrote:
> The problem with this approach is that it is worthless as a
> predictor. We aren't dealing with traffic safety and road design -
> we are dealing with adaptive attackers and malicious miners and
> pools.
>
> Anything which does not invalidate blocks carrying doublespends
> WILL allow malicious miners and pools to conspire with thieves to
> steal money. The probability of being hit will then be (their
> proliferation in your business area) * (their fraction of the
> mining power).
>
> That might seem to give small numbers for most sets of reasonable
> assumptions. But the problem is that's only an average, and the
> people being hit might have small profit margins - one successful
> attack can place hundreds of merchants in red numbers and force
> them to shut down.
>
> You should never expose yourself to attacks which you can't defend
> against and which can be fatal. In particular not if there's
> nothing in the environment that is capable of limiting the size or
> numbers of any attacks. And there's no such thing today in
> Bitcoin.
>
> This is why I sketched out the multisignature notary approach, and
> why some decided to extend that approach with collateral
> (NoRiskWallet) to further reduce trust in the notary. This is the
> single most practical approach I know of today to achieve ACTUAL
> SECURITY for unconfirmed transactions.
>
> Don't like it? See if you can do better!
>
> Just don't rely on zero-confirmation transactions!
You just disproved your own argument.
It is possible to predict risk, and therefore to price the risk.
You also noted that for some Bitcoin users, the price of that risk is
too high for the types of transactions in which wish to engage.
In what way does that translated into a universal requirement for
everybody to use multisignature notaries?
Surely the users who can afford the risk can use zero conf if they
like, and those who can't can use multisig notaries?
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJU6gLmAAoJECpf2nDq2eYj8/AQAJfMtBqjo1Z2Z0A7OhE9iaYD
PqWXdRaCFwyV49RSDrRROrB9Vc7CENQsweHBSnNEmSj6la/YfjyobmaR5BMtTq73
ZaXOFYSGVa9S0j+1qTvz2MorBd6ocxckdunfN7N/uVb4NQRYTHUT8N7AyJgRFYO9
ElQU/8TcNCSRqSQc3z8rnUc8eN1+DgqkMDHM754huOgA0fz0OlxnLCddcCvLr0t7
ZPCtZI94FWQSWhzTK2oa41hh01xG+Eg5GhqGzM7WBqM6+d/CgNcUVeMnVOkkhgav
AmlE81Km9R4AlrsGT/CcGgaC+FvBhqmDYHAGOUG3hLP+MXMe4qA5TRoRKHFvq4Gw
nF6q+leI7z/TkKeiDcyEKKen5cU01SnZlVRnncccIxsjzNjCiBdXOTP6o0pTd34j
5VJQ04mF4sla5AaaSDtsbkZuMdqIZDMn1tWxbmXRQ2cUbCGoi4yYiUlqjetrs4e1
i7NopccLNVDwjGRRnaSs4KkpuW7s23XwKm6WVehrP7S9s1Bqc+84C/rL1G4IF3Ul
vOz+dfxpS+yeGdEDOxb92voKo+fvL/N1sH2+cqTemuYWArDOn1kK/qKdaEfnl9p2
VcPJWuik6Ywomg4fCWmTQWcDxbWiUT/Gb/niONOYQ6iJG7mU4SH9LFBDd8qV+ljN
RqUYrOBf/PaMneNxwJp+
=w36r
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 17528 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/1008c914/attachment.bin>

2023-06-07 17:30:54

- reply

📅 Original date posted:2015-02-22
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/22/2015 07:50 AM, Matt Whitlock wrote:
> This happened to one of the merchants at the Bitcoin 2013
> conference in San Jose. They sold some T-shirts and accepted
> zero-confirmation transactions. The transactions depended on other
> unconfirmed transactions, which never confirmed, so this merchant
> never got their money.
>
> I keep telling people not to accept transactions with zero
> confirmations, but no one listens.
A better solution is to track the failure rate of zero confirmation
transactions, and adjust prices accordingly to cover the expected loss.
This is what every merchant *already does* since no payment method has
a 0% fraud rate.
Even physical cash has a probability of being counterfeit, and the
prices you pay for things at a convenience store already have that
risk priced in.
The idea that zero confirmation transactions require a 100% guarantee
is a strawman, especially since there exists no number of
confirmations the actually produce a 100% irreversibility guarantee.
Zero confirmation transactions can work as long as the risk of
reversal is measurable and reasonably stable.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJU6f0FAAoJECpf2nDq2eYjWJsP/3I6b9KL2tr7wEGUyiUJvn95
wR/DQw3jRoC6rP1OqZAHpePksboEtd1yTxhtnH9UEMzvzFrGeQwKaSgM0s6zbIIm
38BXH6uiTzxI2PUWxv8HDNsPvwAlj0l4EkV9E8DthK9MTDVAk5E/SFUlwgc4tdYB
QinntAYknjIJd7dKVXlIaBrXg0UmTaXDKq9yoQIBTl9SE8xYbbRM154XAjVmqVrZ
h88ZGkaIbpHbBEjbUpqVpPIKM/Ts4b6NwLSfloY7W+Mmvgn3p6EB4V6rt3HuV/wN
L5A0RPbAESGsg0MpRcIprpAq4aiO6Qt0p6wMrZ9x6a+cx1w/RuJx7Sb3zflDjBgk
FmEwqIKJJqWoTEtR2nCEkmDvwx48RJQQppEHJgdUCmxjELpJMKkvtz9Oc4CRP0ty
6JUnBmxNTHRJLL+0nn1sq5WAhTLIQaH3RcVn/SjNk2zjoUXUdx+1pIEyBaZnOckW
e54SraX0KEEZNpTXHA3xJV0d2gA068CChG/TFqMO9uhohWz9jz6NZl7jFLwdBjgb
Wmbid/V/bl6W/ehCiOwLDM/sOer/BDoZPqGt/j2cJZO9gP+wVdiRkojl3f97vd9k
qhGV3QUsc8uiseZNxeIv2hty34KzUPz2ISPM25ZnQMavIevg3Yg0l4O7Hwnk49oK
1nhyoqk+scfLpo7vd6Ke
=fVAx
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 17528 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/8dc7c47e/attachment.bin>

2023-06-07 17:30:17

- reply

📅 Original date posted:2015-02-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/12/2015 07:47 PM, Allen Piscitello wrote:
> Nothing will stop that. Bitcoin needs to deal with those issues,
> not stick our heads in the sand and pretend they don't exist out of
> benevolence. This isn't a pet solution, but the rules of the
> protocol and what is realistically possible given the nature of
> distributed consensus. Relying on altruism is a recipe for
> failure.
If there's a risk of fire burning down wooden buildings, pass out fire
extinguishers and smoke detectors, not matches.
The latter makes one an arsonist.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU3QRrAAoJECpf2nDq2eYjLtwP/3t0uplMwjpt6MP0wrPwOfkJ
tRRyAaSkEsZi3+XjU2GVThG7kAlP2oIGFnoHc1QldhlEeWEJgPZyn7qq+mPx+I5+
OKb0PhSwRpTe0lh+r1dGyVqN+sSfbasJ9RSXYPmw1OW9ud4WOsgOh+oBTQWfuhvc
p32Fxxx5JKjc4AnCVajSzNlPlXrBy3pFfL5F1ek4Wu+H0haz39VE/EYAWlXjyWxT
vhUzv+9bcy3r8pe3eYUAmsXYLZAKb/9hWJdht6SKd509BlV6LVSrUh8Y2SJ3PYKt
z3l4WmiUXkkdk1blqtLDyfUTEZSnBK8X4esj8Sp53WfOXNkgBKe1vr4EhTXaEQMU
KD1e5s12xspPYgJdW9TWacIYKp3Ft3yBODJOTNZL3j0ryzYA+KU5ZumdHIm10J3S
J1IDQBraONESinHybGPKYtUCikTkl6TemW/CpfjRhQONov4708FIg+KQAo6ui56N
otfDGEwqH1qKgbt5DugdEBtxDmYmcYdFjID2+ZLwK6ngat8UAw2dQoCnUtkZ7w+i
Oxz4cm1vIRjv+BYipQjg4IRRZNvpEXSolz6u91qqj8SlXXdY7sZ3B5HwtGSOVX5y
l3NxYVOazA/NA/zcCG9ZPjr/O5sKJ40IjcLbTHvE1POuiF167xF2+U2Sdf/43d9d
cE68utrIaurfJsDA/L/+
=pTe/
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 14416 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/c63d0ce4/attachment.bin>

2023-06-07 17:30:16

- reply

📅 Original date posted:2015-02-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/12/2015 07:15 PM, Alan Reiner wrote:
> I'll add fuel to the fire here, and express that I believe that
> replace-by-fee is good in the long-term. Peter is not breaking
> the zero-conf, it was already broken, and not admitting it creates
> a false sense of security. I don't want to see systems that are
> built on the assumption that zero-conf tx are safe solely because
> it has always appeared safe. You can argue about rational miner
> behaviors all day, but in a decentralized system you have no idea
> what miners consider rational, or speculate about their incentives.
>
As noted elsewhere in the thread, there are two problems with this
analysis:
1. It asserts that zero-confirmation transactions are in a binary
state of safe/broken instead of recognizing that relying on them is a
non-binary risk analysis on the part of a merchant.
2. Assumptions about what is profitable for miners are based on all
miners having short time horizons for calculating profits.
In addition, I'll add that there is an assumption that honest actors
can not alter their behavior in response to changing conditions.
Since scorched-earth solutions to problems are apparently acceptable
now, what would stop more honest node operators from patching their
nodes to blacklist any peer that relays replace-by-fee transactions,
and maybe even publish an IP address list of those peers?
Punishing Bitcoin users for not adopting somebody's pet solution to a
problem neither responsible nor ethical.
Child-pays-for-parent allows for stuck transactions to be cleared from
the mempool, and allows recipients of zero-conf transactions to adjust
their risk exposure as much or as little as they like.
It's a solution that gives Bitcoin users more freedom, instead of
trying to coerce them into pre-determined directions.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt
vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO
hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99
kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/
F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt
P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh
pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5
sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f
b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd
j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL
LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0
F9dKdL5zCGofvU/U5BVq
=kEMr
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 14416 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/3b3f9a5d/attachment.bin>

2023-06-07 17:30:16

- reply

📅 Original date posted:2015-02-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/12/2015 07:45 PM, Peter Todd wrote:
> None of those solutions are compatible with decentralized networks
> for a lot of reasons. Given the inability to prevent sybil attacks
> your suggestions lead to people being unfairly punished for poor
> connectivity that may be entirely out of their control. They also
> make maintaining a Bitcoin node and mining the blockchain require a
> significant amount of hands on maintenance, again incompatible with
> a decentralized system.
So maybe scorched-earth solutions aren't a good idea after all.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU3QO8AAoJECpf2nDq2eYj4bUP/R8Lwjpdvc8Wu573+cGVRI88
/J8fURgYTxS9yvNNGRRHDYkHiqAcGI4sHIQQkqGs+A6mdDTbq6bJ04RjHoznlYbj
TcpaKQkEynVSD5AjMnZ7Z/zLsc+qjFChNGNgxC3k4AW5UdBgo3VTE8HR1rVXM5C3
JLCSKv8uCRkHJxRlXZwE9/sZTZAAuLFVdTQb6sfi4Kb4Ztn8P2K2IsEnOlFwv1cZ
ZNByxa56iBbNrVQa7hbbNXauIGOkj0fM3MB75JUQK/dHnW5d19bNHRIG0vnTtczH
eoVvEdMtpSF/e7S6Kzx5xfcmCQsBRX7JIHyuZpBYAgr1HxjXOrdvqgWQCWDSUtNO
ybzYwNKUbSCgbp6tbVTQuskm0QKVRcrrqMPZepPcgjQ/FLB8EALqarROkJTop/3p
8YatD3iq77SdnOfmFMZCFGHzn4UaxturRdEYIfeqz2Ia0YyyH3GWs1juhazyH+CM
u6HbXXrq6AJmKWLYbSK1ycUBo9OhFObT9X3XswsWa0uNtSwLveqlvaI77UHkJbnr
U9Ek9V0WznV1H9hn6qJpKyS/d+M64dfGjBSo79b50IxvlKrHKBPZkdHfSUyjnMFW
rl9uE0jB6oLFUcqchypJ89HUeso7fD/8l36w0Z4TkMrcAy9V0RIj6P5nBYBU1U1s
cLblEvdmUqmt4t+D1o4K
=YnGT
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 14416 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/f016c8f4/attachment.bin>

2023-06-07 17:30:15

- reply

📅 Original date posted:2015-02-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/12/2015 05:24 PM, Oleg Andreev wrote:
>
>> I think that is a misdirection on your part. The point of
>> replace-by-fee is to make 0-confirms reliably unreliable.
>> Currently people can "get away" with 0-confirms but it's only
>> because most people arent actively double spending, and when they
>> do it is for higher value targets. Double spend attacks are
>> happening a lot more frequently than is being admitted here,
>> according to Peter from work with various clients.
>>
>> Like single address reuse, people have gotten used to something
>> which is bad. Generally accepting 0-conf is also a bad idea(tm)
>> and instant confirmation solutions should be sought elsewhere.
>> There are already interesting solutions and concepts:
>> greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment
>> channels for example. Rather than supporting and promoting risky
>> 0-confirms, we need to spend time on better alternative solutions
>> that will work for everyone and not during the honeymoon phase
>> where attackers are fewer.
>
> Here's value-free assessment of the issue here:
>
> 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer
> instant payments solution if possible. 3. As a social artifact,
> today zeroconf txs happen to work for some people in some
> situations. 4. Replace-by-fee will break #3 and probably hasten
> development of #2.
>
> The discussion boils down to whether we should make #2 happen
> sooner by breaking remnants of #3 sooner.
>
> I personally would rather not break anything, but work as fast as
> possible on #2 so no matter when and how #3 becomes utterly broken,
> we have a better solution. This implies that I also don't want to
> waste time debating with Peter Todd and others. I want to be ready
> with a working tool when zeroconf completely fails (with that patch
> or for some other reasons).
>
> TL;DR: those who are against the patch are better off building a
> decentralized clearing network rather than wasting time on debates.
> When we have such network, we might all want this patch to be used
> for all the reasons Peter has already outlined.
You've left out of the discussion that many (or all) proposed
solutions for 2 either reduce privacy, or security, or both.
That fact should not be ignored or swept under the rug.
There's also no mention of the degree to which child-pays-for-parent
achieves the stated aims of the original proposal (clearing mempool of
stuck transactions, increasing payee assurance of conformation)
without introducing incentives to double spend or forcing people into
privacy/security sacrifices.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5
6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM
HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4
bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF
2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45
RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap
V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232
FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs
G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF
n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM
7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8
XjbkwrkFIuKfUJyfIuR+
=ony0
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 14416 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/d4df7cc6/attachment.bin>

2023-06-07 17:30:10

- reply

📅 Original date posted:2015-02-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/12/2015 03:20 PM, Natanael wrote:
> Multisignature notaries need to convince people to select them.
> They want to know that even with collateral, their funds won't be
> temporarily locked up and unspendable for days at a time.
>
> What services would miners provide here, do you think?
>
>> Well, sure. It's the same model governments use and is why being
>> a money
> transmitter in the USA is so difficult: you need to put up large
> sums of money as collateral and have your fingerprints taken 48
> times. Then you can start advertising to get customers!
>
> Obviously you need to have collateral to provide collateral. Can't
> make cryptographic verifiable guarantees if you don't have the
> resources to back them.
tl;dr: Bitcoin users aren't getting very excited about somebody's pet
hub-and-spoke project, so they decide to distribute a patch that will
change Bitcoin's behavior such that people are forced to adopt them.
Scorched earth, indeed.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU3McnAAoJECpf2nDq2eYjxI8P/iClVQKNhGPr0K4D8KktUDUS
CB8Gu6Rg4VqgjzwhSd1AD1CAhSkxRRgNfHOkxeu2n1wA/fs9V/x66W9G33OyHvf4
1M+BwkiNszxvfxvZVkXyPa/eqa8/alIs1jEhb19dBRn6sJ6EQyca93PG00wDhhRU
JbHeYj2pYYMuu+xRpJWhRdUOpJOsLu5E9XMocS12wun7+zQCs4QfoLVcGhMv3+Ug
iS3/H1NNQJegIFMQzgi5hr7CxClZ+MrsLDO7MBEZknjr0toEJXe7c5Logwc3oF8h
klhFeSnhexCHNeDSGKDhG89hrgWPSDDuuyMRa3e3L4xsT2zAFcsmw0ScCmyNSto4
gUCy1gQsShDJSvsYvqjJkOcL5UfP2WLQiVJecpblf1R/tgjC0SsBoPeRMT/DeSjV
xpcjUrAUzkIBuEcunFarkt7wBvL/4pvGnbYcx3uW2YX50oO7LjCcgwJLMW4ecsvn
zAoc+aXqeORo2SAI3tTJKqpnn5K2k7DVTiFt1vzHVR7OxnKa/+sXk+bCkQi9/dAL
bWjiBUV8hXBVIt0UBgj7Q5wgQSoAXI0D816GIA2Qb9XQfmpRb8QTmf9kQ1DrcV68
Qt1KOHPY1yCynqLMxN3ONWu4JMF+YYwrxx47Gg7wSJr5q70mHNlLljfnfb5PNLtS
J6t2/QfPTMmyN3V6xkbU
=hna5
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 14416 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/ce7feef2/attachment.bin>

2023-06-07 17:29:36

- reply

📅 Original date posted:2015-02-06
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/06/2015 03:08 PM, Jeff Garzik wrote:
> Yes. You can certainly add additional inputs and outputs -- and as
> such you can increase privacy and defrag your wallet at the same
> time.
A lot could be done to make regular spends resemble CoinJoin
transactions and vice verse.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU1P7iAAoJECpf2nDq2eYjeXwQAJGdVdYta5CddfL+xyFNG2+l
RMxkSABfgWQF6mDus6ul+EhRhOYEveuuukbK2ibcnY2U4H9ecb8Gttno9+Wi0YfM
zcu1Wt/j5cJyUFjO9owZO5gse5mTCt+1njgNIGMlXHHbFEHc5OavXEgkvh8YcL/j
E8Kk4YNM5Ovp47vh1ihkB4Zo+ihu5oMuY4vbBO7So4BIe8KaSLOTsOAccT17bWGo
jtd6KdjfqsLSjhQoVtuQAsx9AGUS+jfjBRWSnwkeAdd4G4BE87/7DCdYnczFKhds
kVwnHODA0+5dwEwZ/ChipKVzAVLVZ2a7BXUenax70P1QgfG8WwL0tueoKviRBLfc
6Xa80GHGo84qeGEkiste1qnG4XZWwi6pnTSTwP1f5CtVvGvfYRysHsMCm82Mr7vA
pwrQULv6fkhI63xB+kfcXBPr0WIVrilVrEtGcypzIbPbQgRQ6k3Wg66zLoQTc8vA
w2pOZYrEU1Rmfiv27/MLdvSuWzR0kF+nidwCBxUYBuKAA4K0Y8GBH0FApp9JmCEo
LXIY4RU3sCCbP3C1qloN8k99q8+CDTwrZpzi2zi3r0zRorg/1tTXqavicE9KPC2j
ymk+eFFJhqG51o/d6irzA5R+hK/T2JatDhneEwTBetsrbXq0D9jiN3+KB+vME0wf
KJhXhGbElNyz7eA4EOMt
=zcqb
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 14416 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150206/31effa21/attachment.bin>

2023-06-07 17:29:35

- reply

📅 Original date posted:2015-02-06
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/04/2015 02:23 PM, Isidor Zeuner wrote:
> Hi there,
>
> traditionally, the Bitcoin client strives to hide which output
> addresses are change addresses going back to the payer. However,
> especially with today's dynamically calculated miner fees, this may
> often be ineffective:
>
> A user sending a payment using the Bitcoin client will usually
> enter the payment amount only up to the number of digits which are
> considered to be significant enough. So, the least significant
> digits will often be zero for the payment. With dynamically
> calculated miner fees, this will often not be the case for the
> change amount, making it easy for an observer to classify the
> output addresses.
>
> A possible approach to handle this issue would be to add a
> randomized offset amount to the payment amount. This offset amount
> can be small in comparison to the payment amount.
Another possible approach is to randomize the number of change outputs
from transaction to transaction.
Doing this, it would be possible to make change outputs that mimic
real spends (low number of s.d.)
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU1DH9AAoJECpf2nDq2eYjt2gP/3gpojJey2URkWWk0sg9dpHU
OsD37TCbrwUaS/K8UMKsuc45FSJU/EeYpaVz9r1Ifm/IeaFYPIX0tEm17n3hkcAG
QPmt/xAZn9GVyPWYKjmVDmx574pqiJLeZh8bP788sZsGc4Gk7NNJniVGLtsmvFCb
ZOtwS8v7UuJZx6awydrpNhw/+SsQn9Xdb8fcLqmFKWDpG2Mlrv+ds34NMlGbfO2r
PqCMw1Y12J0HXLisOCGQNZNdG9mVjKw3MP0GGjUlOM+ibrrorqoO5Ifo2RGuElgw
LZkzzDzg6kO8iuNOV7Jg1lz5WftRjgLRSCcMq4V+793zGJW9BeISeDcKQ2ZlWMXB
Hu83m4vCYOJeECdKGWlhyTmKNNHshsiPz3SBDLxP8uR80UkS3waDIXwLxGX9Pa63
uleaZ2qHQ/0UdC9opN3Snn33M701dHNJH9iXfhf/MVnUZ0FjzsLXaJ0F0208ZxCX
qGCAv5y1ijrDlCLTvakZJRIruXgxNPqtErzP9GtgXeGeDc8tRv00WiM9Olpu0EXd
yjhAZGydcE3Ec2cNo+teWjeDt4Ga4OYDb7i08eegaDuj5MCDcDtlgfwNjdKbre1x
S7pKKDn8V03/WST1x9fWjM04NxeSjJ0yRjOAxkLV/mlDX6lQEYJL/W+MJLvpOnTC
LtZrkSmSTJ7ZR0tMgpAe
=8EVe
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 14416 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150206/52b645a3/attachment.bin>

2023-06-07 17:28:49

- reply

📅 Original date posted:2015-01-20
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/20/2015 12:48 PM, Tamas Blummer wrote:
> The legal hurdle to force confiscation through a wallet provider
> might also be lower if the target user is not domestic.
Depending on the threat model, the incentive to force confiscation
might also be lower.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJUvq0CAAoJECpf2nDq2eYjr9kP/RWEg8Az43T+7qMFnrk37+y/
0pyEQ/zisao1d0LouxyGFu704U8Qayk96hUu+2GAQpS8hHVA0CmDW8E1hqKG2nGl
MTTQYp7932NY2NysIvNaQDhVErZZFqMpPYCnsSrnwUrygh+QjWAI8nvrrcgprG5/
zybzs5IJjFQ7QwYJ92D01shkqQJLYYspp2ME3z97AwPCBanN8eG4Iji/V8/aJqcZ
ZqF7yUjAySVUOUzR+Vju1C7N1i9MHzIG9vZA/jkaCiqZ8bvyQTm9LwSK3quoxGAB
lTplIwKjWsEvs0nm0RyurcPIWq1ppfPiWCaMCNDA5Byz3mJbSrRW5ErFgBtpYkgw
CF+WqoWU8fajQjqd8xcsKJmVyQqk4dUWXJQLGnd6pC3DCZGOPhr+6674vgmEQG5A
bXoBAtJfAJkxkDGEsngs4EBGc08iy+t6tJUh7+wI/La8xulM5BgJkQRTnL4Hn6KS
pcgYV9JP1BWMB4fkdL81mKnG98BJ98pj019C0nuPYQtSA0rUsWG9d3NYDPe87I+K
7UJ6NlNxTLxnS7nhr8Wk9UdqkFMsCQxF/RFR6I9vCQ/FMSD+i1786I72kkyf4cWJ
4ZssTX3yo6pN/faU2cBk84PQlA2ziARXqO+jzbxVR7AFpT2BESUtBdirh1CPEMfR
piBBTr6I86R2bpZYv046
=pJvU
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 17528 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150120/e0e51275/attachment.bin>

2023-06-07 17:28:48

- reply

📅 Original date posted:2015-01-20
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/20/2015 03:46 PM, Peter Todd wrote:
> But ultimately we're not going to know until court cases start
> happening. In the meantime probably the best advice - other than
> getting out of the wallet business! - is to do everything you can
> to prevent losses through malicious auto-updates. Create systems
> where as many people as possible have to sign off and review an
> update before it has the opportunity to spend user funds. Not
> having auto-updates at all is a (legally) safe way to achieve that
> goal; if you do have them make sure the process by which an update
> happens is controlled by more than one person and there are
> mechanisms in place to create good audit logs of how exactly an
> update happened.
>
> Finally keep in mind that one of the consequences of a custodial
> relationship is that some legal authority might try to *force* you
> to seize user funds. StrongCoin made it 100% clear to authorities
> that they and sites like them are able to seize funds at will - I
> won't be surprised if authorities use that power in the future. The
> more automatic and less transparent an update is, the higher the
> chance some authority will lean on you to seize funds. So don't
> make it easy for yourself to meet those demands.
One suggestion you didn't mention was jurisdictional arbitrage - don't
be located in the same country as the majority of your users.
Or, from the other perspective, users should be strongly encouraged to
get their wallet software from companies/organizations not located in
the same country as them.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJUvpSqAAoJECpf2nDq2eYj0oQQAI62vLPzFrkLZoRw3bIw5GWt
6L8dpLUviRS7ZaQlNB49TT4L4Ky+MJ1PxaHwb4YPxrVcCWDLiJb51CtODduF/9rR
8N4xoQuf/6DhsBHWJE8NDwP+9JUOlY23xdSe/BlLz9N1Ql/EV0HTCu28A9xbhK1L
QHgwX3p5/ZCJo7PCARF3o+EZOif5MsA4MdQ11HhyFWN/fgww9AVOIg/0m+tIqkjR
yoOzFww4AejC7nxi+Q+elljpvp2Q/Nv8cVOVlp9l4+f9P7sg0em9YUCE+iAxoZTT
7b9soUXFUjWlxFITR5RnjlDUnmra9QhBIhogBQbLelt/vdoRInz+kXxroR2x3uKh
EJoet2czRB1oiRKHE4iSAv+1pnavQJDVo5/mUMzeM15zCnQ16Mfu9aOpqvijK0cw
u67E4IAPJ2PmUy4sPPJ/4H4FPLmJrSUkLxxzq/4prmLLmeZZvPwjavnULHir4jyG
aaxFqMkbeJSeK3hLk7hnlrwpQRAEq7om+EpQ7fAx1lmEoA3eOHaeclh7/XzDwIB4
AK/jX+1ylhGvfuKNzwTQVX8dEzaHRwLAfLfHUNnP80WhBzH5ODicwcOwwOanL6/A
qgqwDSSB/Q5aj3VsThQ+PR81u/wA5t/Av9+Wn/g+AEMyzCnJcnHxDe41ZEn4UzYY
+RAX1P8yzF/M2ZQUeMLh
=G0GE
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 17528 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150120/7edc7d91/attachment.bin>

2023-06-07 17:28:35

- reply

📅 Original date posted:2015-01-22
📝 Original message:On 01/17/2015 08:45 PM, Rune Kjær Svendsen wrote:
> Hi list
>
> Found this on reddit: http://impulse.is/
>
> PDF: http://impulse.is/impulse.pdf
>
> I'd love to hear this list's thoughts.
>
> /runeks
I'm concerned about the silence that always erupts whenever
privacy-hostile products are proposed.
--
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

2023-06-07 17:28:17

- reply

📅 Original date posted:2014-12-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 12/30/2014 10:47 AM, Jorge Timón wrote:
> What services? I must be missing something obvious about the
> motivation. I understand the difference between "paying to myself
> only when I mine the next block" and "offering fees to whoever
> mines this tx". But how does allowing miners to pay to themselves
> in this way help with security and future lower subsidies at all?
I don't know what Sergio Lernet meant about miners paying themselves
and future network security.
If miners wanted to offer value-added services, especially if those
services involved adding specific scripts to the outputs of the
generation transaction, the most natural way for their customers to
pay them is to allow inputs to the generation transaction.
It could also be done with pay-to-fee transactions, but that would
make the services more expensive due to risk premium.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJUoqXIAAoJEMP3uyY4RQ21OZUH/iI9N9bQ3TLPnmCVW6bkIitD
WT6uBUhBREls2NMjyDQ//UN9F9nt+aU7jN/I0AMrdB8ngFb4r1gfxSpld9KVp6Yw
k3jW8Lo3WhTnCCE0a1MbBqomsAfIwDdksZoH73QW+sGYD+cShgFC55QWfE6gy3OF
pge1dsWNPlMSHmWn9+g7g3+FjkhKeZFNSb0MKzIvEBE7iJOf85etJpMs9a/425sx
UcJX33bVdhG51Au3PSs+0jUljoFby28EM717otq8Tkjei2hw1yNNmtws4/NcQlh3
W6TGBZLb188hUrOOH52p2Cckm8gGgw9hTc9nSLSjQS2pPjVRpTRR4smxMTKND9E=
=QBYE
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14542 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141230/ae058422/attachment.bin>

2023-06-07 17:28:17

- reply

📅 Original date posted:2014-12-29
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 12/29/2014 09:10 PM, Mike Hearn wrote:
> How does adding inputs to a coinbase differ from just having
> pay-to-fee transactions in the block?
If a miner includes pay-to-fee transactions in a block, those fees
could be claimed by another miner in the case the first miner's block
is orphaned.
Inputs to a generation transaction can not be similarly poached.
That difference makes some services possible that would can not be
safely achieved with pay-to-fee transactions.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJUocjPAAoJEMP3uyY4RQ21zrMH/1f3vjac9XqOZbDItjiD6XXU
EkpRUROjyQAs6/tO6dwWAIcXgulYREAJsU/udQNkTYteIDFlDzwkYL+NLXpYtwHs
BiZJEEwmAEHFgOD3QmmqhTx867zIbEYIB/dpHlMOppE6fhTKFr9z6JdqAKlNcHHW
tkW5sq8q9uq7StiUs3/mmZ0XXeEb84N+bPiJ9S7kuTm9QWnrF1oMLhAk4M6yX8hn
7MUowmfc9RZ4uIFkqxk6gkWJSRx7dlnCRP2TRhyABpZwAcZANuPhqBOZ6eJ6T9Fs
DOJ14c5JYachXW5z8GqR+abeq0JPE76kEQt145B4degJ4DTQLLhlfdvjbuJvzy4=
=Kfe2
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14542 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141229/66a61d85/attachment.bin>

2023-06-07 17:27:52

- reply

📅 Original date posted:2014-12-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 12/12/2014 01:41 PM, odinn wrote:
> I think the Mastercoin devs are doing fine work
I wonder if all the Mastercoin devs would agree with that statement.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJUivkLAAoJEMP3uyY4RQ21r5cIANvabja0i5j79a6KSkKOgEyR
LhBz4mugzTc8Zej2NBeyEtv0pzO4fs5wvQo4N/1BW7aHXuFJsgJpGlV8thkuFhek
UhoPC23i7u3jCPQ30PintqvCBCimse+PJa60KE2QL2DZn7WgRGKrEuo41AROxeit
vfVMcFULc6bB9hxIEBpcU4RuwKJHVgzSHMkO75/uHHtPLJ9TbCfqcxT146cZvSjc
Tc62ukuX1xBj5PhQM8GaUGzkQcfcZ+7d3DD1X22Gk1U6w+zat52dapy/qYgn9oA5
ubk/p/7Kywd8D44rPsr/pbdlDZxG0w77yRJIMboXhFMV7rY3sMRHHQmAUz+I8FY=
=R4pR
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14542 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141212/3302f4a2/attachment.bin>

2023-06-07 17:27:16

- reply

📅 Original date posted:2014-11-06
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/06/2014 05:26 PM, Peter Todd wrote:> For the same reason we
don't do hard-forking upgrades of basically every
> protocol on the planet on a regular basis, even when we don't have
> consensus problems to worry about.
>
> Flag days are really rare in engineering, and for good reason.
This explanation is completely incoherent.
Because Bitcoin has a extra consensus requirements, requirements which
are really rare in engineering, the necessity of fixing bugs is even
greater.
There are two general ways to fix bugs: either as part of a
controlled, planned, and managed process, or as a response to an
immediate disaster.
The alternative to scheduling and planning the upgrades which are
necessary to fix the bugs in the protocol, where such fixes can be
written, tested, and documented at leisure, is to wait for some crisis
and slap on another bandaid when the network breaks again (like it did
March of last year).
Who benefits from not fixing bugs in Bitcoin?
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJUXAYVAAoJEMP3uyY4RQ21YxMH/3O+vFK2jDXV5V8IIsJnU/u1
D4gYyVm89E0zmGTyLAUYCJGj0eg5tMyUUzu62hOECOeQuKdVi+mbkLi4TiF0sHIb
8k25MgqJgzH/021eoI2g2w1FrDlZut02LNX/V09+owd1yhp+SEXZ3/+HlqsZXhsv
/u9u5OayzhGlzS6apQtrosl5P+KIquHqIbtwBtPOb2rvlL0miJ6sRcAH2JCXCBDT
HMcswMtIGZbgqL/K7e/6vH7dUWdp0866RZXvt7aWGNUgvxHbGMs+zsnxp4nNslxM
wqL71gTmtMnLcw0GtqmXPjcjo+adrPnqp45xc9lSt23PGjxxfR0FKYIPb2uZdq8=
=9GOY
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141106/d0dd1f4d/attachment.bin>

2023-06-07 17:27:16

- reply

📅 Original date posted:2014-11-06
📝 Original message:On 11/06/2014 04:11 PM, Jeff Garzik wrote:
> RE soft fork vs. hard fork: It's about this time at Mike Hearn will
> chime in, on the side of hard forks. Hard forks are in a sense much
> cleaner, and permit solving problems not otherwise solvable with a
> hard fork. However, hard forks clearly have risks, notably the Big
> Risk akin to a US Constitutional Convention: once you open the door,
> anything can happen, any rule no matter how "sacred" can be changed.
Yes, there are risks, but those risks could be managed with appropriate
effort. Major players could publicly commit to a set of ground rules vis
a vis what categories of changes are and are not acceptable.
Maybe at some point there could even be something that resembles project
management for the Bitcoin protocol.
Why not schedule protocol upgrades every two years for the foreseeable
future?
Spend one year achieving broad consensus regarding what changes to make
in the next upgrade, then spend one year in feature freeze (all future
proposals postponed for the next cycle) then execute the upgrade.
The top priority should be fixing bugs that make specifying and
re-implementing the protocol nearly impossible. Those kinds of changes
should have little difficulty achieving near-unanimous consensus.
There shouldn't be any problems separating obviously-needed changes from
the ones that let third parties blacklist coins, or a majority of miners
vote to confiscate block rewards from minority, tamper with the issuance
schedule, etc.
--
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141106/d327ba11/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141106/d327ba11/attachment.sig>

2023-06-07 17:26:38

- reply

📅 Original date posted:2014-10-22
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 10/20/2014 12:50 PM, Mike Hearn wrote:
> One thing this brings up is the never-resolved issue of whether
> BIPs should document how we'd *like* things to work, or how things
> *actually do* work. BIP32 is an example of the former - it was new
> technology and the spec was finalised before any wallets actually
> implemented it. BIP 44 is an example of the latter, it basically
> documents how myTREZOR works and as such there was minimal or no
> scope for changes to it. Of course both kinds of document are
> valuable.
You also have things like BIP43 that encourage people to reserve BIP
numbers to avoid namespace collisions even if their work does not
affect any other project.
There should be an efficient process for informational BIPs of this type.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJUR9T1AAoJEMP3uyY4RQ21ADgH/0JUnkrAzKiBrtFcoXNTEkNl
7npCPY90zQDXk0RN0sV49ralMg/j71azHKmdeH3XHPF2BG3mC4+7TejhJkDEoCoB
fzVyQ/a7MSz3Hnxh0iwx/4p+8A3v6oI6h3yDJeCrwdMudGYA2OfyQuFdrSuchHp6
j0yJpdxxEwtc9A/7SKk5R7yrLqeeLs4OCk2Ep8mZfCQyWssXvlJzd0IDvYZiUHrM
jwLgDCAUNIotEqF4sPzxUMCUkQH3okeVhND/WvoDh8EIrE6l48I19CfDax3gJUU+
4eI5Ooba3SRu5a8cf3V/lgtdbpJJ4i1UdpcjeWNAz1w/P1NVrWN4uJgzUilh6zU=
=OWdW
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14542 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141022/b7b1a4d0/attachment.bin>

2023-06-07 17:26:21

- reply

📅 Original date posted:2014-10-10
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 10/10/2014 05:26 PM, Mike Hearn wrote:
> I'm sure this suggestion will go down like a lead balloon, but
> Bitcoin Core is not the first project that's had issues with Linux
> distros silently modifying their software as they package it. In
> this case Luke has changed things to be closer to what users
> expect, which is good to see, but I expect to see the same issue
> crop up with other Linux distributions in future. The temptation to
> "improve" things when you're a middleman is just too great.
>
> The usual approach to fixing it is trademark the project name and
> use that to enforce "clean" packaging. Firefox and Chrome both take
> this approach. I'll probably do the same with Lighthouse (need to
> figure out the trademarking process first).
>
> The goal here is not to remove choice, rather to ensure people know
> what they're getting. It's reasonable to assume if you do "emerge
> bitcoin" then you're getting Bitcoin Core as distributed by
> bitcoin.org, not a highly opinionated fork of it. Renaming a
> project and creating a package under the new name is not only
> better for end users, but lets the fork grow into something else
> and be more usable to people on other distros too.
>
> In this case "Bitcoin" is already a trademark, though I lost track
> of who owns it at the moment (the foundation?) but I guess Bitcoin
> Core is not.
Regardless of whether this is a good idea or not in general, it won't
work in the case of Gentoo (and similar source-based distributions)
because Gentoo doesn't distribute software - they distribute
instructions which allow end users to download, compile, and install
software (ebuilds).
On my system I can compile a modified Firefox that still calls itself
"Firefox" by setting USE="-bindist". This would put Gentoo in
violation of Mozilla's trademarks if they were distributing that
modified version, but they aren't, so they're not. They just
distribute the instructions that tells my copy of Portage how to
compile the modified version. As long as I don't distribute the
modified binaries I compiled, then neither am I violating Mozilla's
trademarks.
tl;dr: The trademarking approach is only effective with regards to
binary distributions, not source-based distributions.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJUOChPAAoJEMP3uyY4RQ21DNoH/0Yb3GpF230UGfQQ7Y2qQ4Sr
QTNW6hwMaLSwRvdnkAxmQf1S2I3da6AJkXcyyUavJuqw+m6lxdiA3OwUQOZblEUS
HkZqajS3gpCCmYJGbHD+DT3YnvDaeIQmuacsxMTXpVWK5QleH6mSdpbomc2TCS+D
JulZuSQJSB997uNKqYvQmwe0b3ImgND6omoOZABjFrLESeYgQWLFBthl9vwBLtFB
DqRbyvrl6+vFzX9yObAt0+iSDkoHHkPbg2/KeUCKuJaIqvFyBo0t9dvx/tvQJupk
TY39a/0MW8z524e2s2SwsZbmYXSBLTlDhkTbWR0lPQH5OOcrmH7cpEG1vsZH9yY=
=tfaE
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141010/58be4aa9/attachment.bin>

2023-06-07 17:25:56

- reply

📅 Original date posted:2014-09-25
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 09/26/2014 01:53 AM, Gregory Maxwell wrote:
> On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier
> <justus at monetas.net> wrote:
>> Two draft information BIPs are attached.
>
> I've pinged some people privately but also pinging the list… no
> commentary on this proposal?
>
Regarding the BIP process itself, I rather think it's broken in the
case of informational BIPs.
Proposals that require explicit action on the part of others do not
logically belong in the same process as purely information proposals
that do not require any explicit action by others are going to be
carried out regardless.
The only reason we proposed these as BIPs at all was to support the
intent of BIP43.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJUJMrzAAoJEMP3uyY4RQ217DMH/1oGHayVo4smLM/OKeu1qqXC
Xex4NNh6g7Jsu2ulfJ5ow3g7jHEDzTBp33THhUv6cnV7CpDvTC+Y24LDRrYwOBQo
YuQ9u0NNtrcgoi+6vs8NuGO+yZyTyBYs1emOipsICsg42H8yhEHlrMyfOTJsO6r/
nAiqR+QH6isNOjQerd9Fs0nYQ6VANs8IksL41L8ch9YAvgKx7C8WxdcQrk/S2pNL
JwD7Q729J34x34HPnOb5j5Rfm1gvQInYELBu0YBaCy7D05PZd5nPSYqUC3n35hUA
AMvVf65jdQVBjvjlcqDPAPdBTQ3qjhQ+7EAWKJrwlrzhGXaWA3HpipRDUSyqzBg=
=OhH8
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140926/ac776cd5/attachment.bin>

2023-06-07 17:25:52

- reply

📅 Original date posted:2014-09-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 09/23/2014 04:48 PM, Alan Reiner wrote:
> Please recap/link it here so that it can be part of this
> discussion.
http://sourceforge.net/p/bitcoin/mailman/message/32736455/
http://opentransactions.org/wiki/index.php/Deposit_Address_(voting_pools)
Currently being implemented here:
https://github.com/monetas/btcwallet/commits/vp
- --
Really what's so annoying is how the BIP numbering process is handled in
such a way that proposals can be silently pigeonholed.
Especially so in the case of an *informational* BIP which requires no
action on anyone's part (except for not using the same BIP43 purpose
code).
We resolved this by changing the naming scheme for our proposals, and
their associated purpose codes, to not rely on centrally-allocated
numbers.
https://github.com/Open-Transactions/rfc/tree/master/bips
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJUIajuAAoJEMP3uyY4RQ215dQH/1GNOmZd19/e2Ys7MNFx0gqz
rDmTFBylU3lhJrMY4CDd4Duq5+2U7HgaovqgX8UqxquHWLQUwEzZLqdEPCifLg0c
d/u90cRlClFAaOxPh4HV2/3aZoS2R27N+ZjOfziW7RZySBP/2fMt4/ra+SPbkcAQ
oeplYgqMRDqW52C/o2zm4y4yb0TJPS+lzSNM+JfxHSPRyY55l0KzLJfUNz1RSOze
A8UAwdsLiJROKPKiSrQcqFOejPV7uqSPh10ukm/AI0k8TbvX8ffGQ083394M9IuE
DB/1eyeLQVP5+lQMWNrTHk3BQ75XBEDJoSukaRENcqxtHV2m1JzTWoS2CQBXi2M=
=TwI3
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140923/c8cf6cc2/attachment.bin>

2023-06-07 17:25:52

- reply

📅 Original date posted:2014-09-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 09/23/2014 04:16 PM, Alan Reiner wrote:
> P.S. -- "No-Collision Mode" is not a great name. Happy to take
> suggestions for changing it.
I'd call it a "voting pool wallet", since that was the original
application for this arrangement.
Would be nice if you'd at least mention our work, since we did share
it with you back in January and have been publicly documenting it ever
since.
Or does the fact that we're implementing it in btcwallet mean what
we're working on is unmentionable here?
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJUIaHAAAoJEMP3uyY4RQ21nwoH/3MYi9JibblZYmSOvCT1vJrN
Ih+Q2WNumIAI+Y9bh4bBgLuhnG5lXyHedhYEUW+mfuwGiX+92Uc47nwaWED2/Lte
4Zk/KZnwLifdWCgKLdGpW6mzksRiOaVyU4vV5JchVOrGZZ2zYNIq+NcChtCph7Y5
L202ReAG+1dfSpp4rFckuv7pTVjNcrq89UN1tJFDNQdxzIRd7bwoeCuvyFurZagB
88bNiOl0BI3e090WC+CWmbC6BfqJiicn/d0gp/agW01wy7CVbLypPPTKmYqt3+54
msLUgaRHcbjuyKqu8HMHpYtgYVSNFg2q+U4SgmEepzPAkQ97khbduqA6i1B0ULM=
=t/xp
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140923/691a56c9/attachment.bin>

2023-06-07 17:25:49

- reply

📅 Original date posted:2014-09-15
📝 Original message:On 09/15/2014 03:08 PM, Jeff Garzik wrote:
> Such guidelines are a perfect example of why PGP WoT is useless and
> stupid geek wanking.
>
> A person's behavioural signature is what is relevant. We know how
> Satoshi coded and wrote. It was the online Satoshi with which we
> interacted. The online Satoshi's PGP signature would be fine...
> assuming he established a pattern of use.
I wrote up an example of how the WoT and the behavior signature might be
combined via a game:
http://bitcoinism.blogspot.ch/2013/09/building-pgp-web-of-trust-that-people.html
tl;dr: "Identity" is not a name - it's a set of shared experiences with
other people. Identity systems that want to be successful should focus
on those shared experiences rather than names.
--
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140915/571a6599/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140915/571a6599/attachment.sig>

2023-06-07 17:25:34

- reply

📅 Original date posted:2014-08-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
We'd like to reserve two purpose codes for the HD multisig structure
that will be used for the Bitcoin wallets used for voting pools, so
we've documented the structure in the form of two BIPs. One is used
for the wallets suitable for storing bulk bitcoin deposits, the other
is used for storing colored coin deposits.
The primary difference is that bulk deposit wallets use cold storage
and are allowed to incur significant administrative overhead, where as
colored coin wallets do not use cold storage because they must be
capable of being generated on the fly.
Two draft information BIPs are attached.
- --
Justus Ranvier | Monetas <http://monetas.net/>
<mailto:justus at monetas.net> | Public key ID : C3F7BB2638450DB5
| BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJT84VCAAoJEMP3uyY4RQ21LZcH/RYN5dUc5TjOI6Z72I4aNqDL
cZMzIo1WTK6OHsO2GUo+3L4avf+dCb2om/hDJgoLz/Oh9BMY77vF3UTIPIzGmN9X
2Oeyjg+wJG9z2L/B1f7oo4MX9c2ppUNfp2x5zDaURvME9CLkY7hLCBWp/OxU1HHb
MhLn0ICtpw3FnHddVWFwhvBxcCzJm6t2pBlM8mmTr4t52/08gklY1LVdUW0zmf9W
eFe50Y2KQ+uhVZfAga1wmFwY1pJBUmf6fAVqeK6AGDPkLVHDvN8P+mco+Qks++VZ
mTENKXWAmskGViTjd0pb8EdoSoMsDIa1eRHbpwAbbb2PEoc9pdccgwH6CscgN1I=
=R/HX
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140819/3aeeae9a/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140819/3aeeae9a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140819/3aeeae9a/attachment.bin>

2023-06-07 17:25:24

- reply

📅 Original date posted:2014-08-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 08/23/2014 04:17 PM, xor wrote:
> On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote:
>> Encryption is of little value if you may deduce the same
>> information by observing packet sizes and timings.
>
> Instead of spawning a discussion whether this aspect is a reason to
> NOT encrypt, you should do the obvious:
>
> Fix that as well. X being broken is not a reason for not fixing Y.
> Pad the then encrypted packets with random bytes. The fact that
> they are encrypted makes them look like random data already, so the
> padding will not be distinguishable from the rest. Also, add some
> random bias to their timing.
The packet size and timing issue will become less of an issue as the
network grows anyway.
One transaction inserted into a 3 transaction-per-second encrypted
stream is more obvious than the same transaction inserted into a 100
or 1000 TPS stream.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJT+MZWAAoJEMP3uyY4RQ21tDoH/0SPYQcUkYJcuDhTkJCFWdyx
ob3H7ITEcqD0UZ3n3QHdxHfCDlP2srL0EcfjbNceRX5inP47jdoGj7uIkY/NRHQ0
4J2WCIrcu1Bj3ZxXG59PtfUzMjxhMGDMSk5eE+6BjVQILrkxxrqSpVjykfoq5s6Y
EBdT2Pf4djQ5k2fQ2PX1dTt5iCvFh0ufq3McrYsciRzguRwlelw1W34tPBqGSv0n
LScgvqYUTGC7otUdA5K/3WBq6SSo7E13hJxiLKQZMQ4CPpSlsiAhI5fuhl0OBljC
hCtS+eugFmvMICQt0ELds++nnA5WN/Yjx1WIrnLA1EmNiAkS9RSEVMcyab0TtdI=
=0sjO
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140823/61589972/attachment.bin>

2023-06-07 17:25:23

- reply

📅 Original date posted:2014-08-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 08/20/2014 12:16 AM, Peter Todd wrote:
> The easiest way to do this would be to make the Debian/Ubuntu
> packages depend on Tor, and include a install-time script to setup
> the hidden service. I've verified with the Tor devs that they would
> welcome the additional load on the Tor network that Bitcoin would
> add.
The easiest way for the people who operates nodes would be to compile
Tor into Bitcoin Core as a library so that it "just works" when turned on.
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJT8/B9AAoJEMP3uyY4RQ21YbcH/1golU27alo57cfCqjMei6uD
iJ69NMQ6wO4U9r8VX8Rwkd/8IVK+gP4eJNRj4FlUNU0eXFcXj3zaCpnHnO30OEPV
tdx/dyd/sq/gn5WL3m29MsP5ZVX8pIIH8aQ6jjLWC0SsE6KUJeK6f48o/XST4kMn
a5w1YkUW1Mo/1lLmIlTnmapNrMYq1VppOi0F8AaRgMjTkoX/aGOgu6yIlGJXjAbA
E8zlIvmLBcMq3aGNrlpE5WJBG1UQr84GYxjSQ1evL1PsllkxrSH3MODtESLYTMqB
77ZpGNbm3Ndgxvr03pXhXPGbrug3qX92fbKI42XkSC7n/pWLe5YKUiAukDN4NjU=
=ttua
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140820/a3243a2a/attachment.bin>

2023-06-07 17:25:21

- reply

📅 Original date posted:2014-08-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 08/19/2014 11:38 PM, J Ross Nicoll wrote:
> That's not great, certainly, but how many nodes actually require
> that level of security
All of them.
While the rest of the 'net is busy deprecating HTTP and all other
unencrypted transport methods, why is it(*) even a debate?
Security should be on by default. Make users who don't want it jump
through hoops to turn it off instead of the other way around.
(*) where "it" is the desirability of blocking passive surveillance,
not the particular algorithm to use.
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJT8+AdAAoJEMP3uyY4RQ21kv8IANDkveCGJX5b5c+waXTHcEf0
MgrGlkUZgZaP+fNNME32MEeQMywkyHohZly1KKYyqf+Qi2YkZ7rFiZj5e16EtGVK
zBQCrvOyMZVv/tWPfRxrZV+jC5dUBPryaCV3XwyK3w8u5WpDhpC1be6uBjY6qtTB
58MzdMBEEwceUwDezAIpGxsr5fKw+by4WyL23HQybSgUSHWh9S9hSp4dY1L8sDdr
atdFOvjiwY7zQe9V4mrtSv2pwmWIfOJE3RBhwSdPBtsMqO0PAnUEmxKYANQjh8qV
W147aQT97DYkWb3TucY+gVbsfKSzvNoiXwvWMpmXT1Kz8wia0vX7MoPBtO6+uOk=
=6tJk
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140819/f42213ca/attachment.bin>

2023-06-07 17:25:19

- reply

📅 Original date posted:2014-08-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 08/19/2014 03:30 PM, Richard Moore wrote:
> Oh, I see. I misread, thinking you wanted the dev team to have a
> private key and share the public key, similar to alerts. But each
> peer would have a public/private key pair and use something akin to
> ECDH for a symmetric key and transport using a block cipher?
>
> How would you share the public key? If I were a man-in-the-middle,
> I could intercept the public key, generate my own and pass that
> along and then decouple the pipe when the other side shares their
> public key.
>
> Also, you should not ignore your SSH fingerprint, as you exactly
> open yourself to mitm attacks.
http://curvecp.org
If that's not acceptable, even using TLS with self-signed certificates
would be an improvement.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJT83Y1AAoJEMP3uyY4RQ21aqUH/3rGvgz3J6UYY2Qb2qzNoucB
QqIj4fByZncX7Fhx5YK6fc6QoLr4Oqxd+zgbJ3ghrLtAJ7dm61iLmmib8MuDz2K1
kQj8xmZhWuUFI26bjK54RlKoWg46XFKNKcaVub6JmVg9dH8mX86mF746KnR5ZqdX
BuehWoEqcHlY3JkrTgOGpHjT/EGScZQxzJHzsBOfUJuX12lFtzcWzBTZyo5K8fD+
6eub3i6Fc4qn/c788UVFsmHeWV+NCeB1/y94V1+peIPWYhrZO+FVm+xEflG4U81Q
MRejqNjFT8ztT5vRHx1qJsmIgnzT0SXfh+FRt0hdqJizjlmyntMmCXjFmtnIeT8=
=9qWl
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140819/b2be03df/attachment.bin>

2023-06-07 17:24:37

- reply

📅 Original date posted:2014-07-31
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/30/2014 09:50 PM, Alan Reiner wrote:
> (though, in the future, we hope to provide an optional service to
> help synchronize the data between parties)
Before rolling your own service, it might be a good idea to add
Bitmessage integration to provide the P2P communication layer.
Even if you resolved to create such a service without creating any
negative privacy or confidentially side effects, I'd be more inclined
to trust Bitmessage to get that right in the long term, because the
service you'd create isn't your primary product or core competency.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJT2ovhAAoJEMP3uyY4RQ21zw4H/3vjcZXP6e0/5IG745PDy/AC
Br1ChlyQjBpU7X9CQfrxDmUUGs7HDrwLjd/SZAV1/PUUXXfE3nDr24hsF8+PlGex
AiZhO7k92xfwRMWxMmcVVt/kuaOldHZUqHDUenT3drJ/bPnV+R3FJ9O6Ougu/YVy
H2BRjpdPGrZx9NP/hE/7evA7rPF8pcshpMBiwq6RiHFdu/+2jcThFZoMIaJsAcif
1vZOzP6vTUKkr3E7tRt5ZQrdb4vvGxX+xMomm8fzPmV3GkpJ/Kyyypx+ovaH74V5
oXXg62XRz4lSziWV5Sp4p/18VjRyUkxwvfXXMt9sW6vNvRDxtJNP8/ZKpkMjO3s=
=ClEd
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 14046 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140731/9bde8224/attachment.bin>

2023-06-07 17:23:12

- reply

📅 Original date posted:2014-06-24
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/24/2014 09:07 AM, Wladimir wrote:
> My main argument for the split is that full nodes and wallets have
> completely different usage scenarios:
>
> - A wallet should be online as little as possible, ideally only
> when you do transactions or want to check for them.
>
> - A full node should be online 24/7 or it is virtually useless to
> the network.
I think btcd has done this right.
A wallet is a daemon that runs constantly in the background, just like
the full node.
The GUI (which is distinct from the wallet) runs as little as
possible. Presumably there's no need for a 1:1 relationship between
wallets and GUIs.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJTqZpVAAoJEMP3uyY4RQ21E48H/0XNYBzR8QZjfku/MeL5IbwL
A56jrlWe2EZTabwfKdGx12L5oeBXe3DOeLsTizqIu0vijcl7qQryU49AjrVe91Rx
OdEi4lmaiXdkM3lWeWUxLoLLHR1B+1f8T18Mrnzo+yasyrywPb+6H79VN5KERdA2
5yHYCZyHXdNoXpzyf38GC2PdYJmAZdrRfAGyC5+OXSwE3XLhpRBrSBh/mrx0ct5M
ghkCKtsmJCJJ6sR2TbFxaj71kPp0J0tp8JVvjVEqC2uB4Ih0NY+79kz8L81TaNmw
ol1o6p7TypIk7QRQ4ES3Fq0ALh2aQ/tX4rc0GC0ed+xLi+dHJ2wGBI37HoyGIyg=
=Nn9X
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 12464 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140624/67dda293/attachment.bin>

2023-06-07 17:23:08

- reply

📅 Original date posted:2014-06-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/19/2014 05:11 PM, Kevin wrote:
> Why do you want to punish pools?
It's part of a general trend wherein people look at all the things
that can be accomplished in an economy that has a division of labor*,
and see some misbehavior at the edges, and decide that rather than
fixing the misbehavior we should throw out the entire concept of labor
specialization.
Hating on labor specialization as a concept, rather than simply
finding solutions for specialist misbehavior, was the basis for scrypt
mining, PoS, and MaidSafe.
(*) http://www.econlib.org/library/Essays/rdPncl1.html
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJTox/JAAoJEMP3uyY4RQ216F0IAKo26MEK/IrIlHMw4UYsWBWK
LWWLe4mfUb+I74ZHPzC2ZE7u6Lf6vAeeG/mLe8K/ls1qBJk9ae7bsA+DVvRn8LfW
Ir/seYtCCnLpxhHGbVtYOeWaS+WyOWMKBz1moOTJcgWwPPiL5BLk9SvaLqgy2GDV
fJeniqtkZ96Vzif1DNdQtiLfn9aJRL2Er0EO7VL4ojmaM3Bv6Z6l+e0eLVVh8DKe
u1Sp4UOpqJmVHJq+9EeMhdfmOqNWGUA5wFRiDsWfzUDHLkAlISM+sFFSD0CzO0RK
P5whGxo58bSMigbQYOfoTZqgKQefQeXAqtlnrLOLq9/EOZ/34cJET5Z0S/K/F5E=
=3KMH
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 12464 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140619/3a80b41e/attachment.bin>

2023-06-07 17:22:56

- reply

📅 Original date posted:2014-06-16
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/16/2014 07:00 PM, Justus Ranvier wrote:
> There can be multiple independent transport networks for Bitcoin.
>
> There already is: ipv4, ipv6, Tor, and native_i2p (out of tree
> patch).
>
> As long as multihomed hosts that act as bridges then information
> will propagate across all of them. -- Justus Ranvier
> ----------------- sent with R2Mail2
>
> ----- Original Message ----- From: Matt Whitlock
> <bip at mattwhitlock.name>
>> Now another concern: won't this proposal increase the likelihood
>> of a network split? The free-market capitalist nodes will want to
>> charge their peers and will kick and ban peers that don't pay up
>> (and will pay their peers to avoid being kicked and banned
>> themselves), whereas the socialist nodes will want all of their
>> peers to feed them transactions out of the goodness of their
>> hearts and will thus necessarily be relegated to connecting only
>> to other altrustic peers. Thus, the network will comprise two
>> incompatible ideological camps, whose nodes won't interconnect.
Also consider that currently there are many people have already
demonstrated a willingness to donate bandwidth and resources to the
public by running nodes, so those people aren't going to disappear.
They could operate mixed-mode nodes, with a fraction of the allowed
incoming connections reserved for free peer, with free connections
might be limited in terms of time duration. Bitcoin-accepting
brick-and-mortars would probably allow free access to anyone connected
to their internal wifi to facilitate people wanting to pay.
Crowdfunded free bridges, assurance contracts, etc are all other ways
to let people get into the network with no upfront cost.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJTn1mwAAoJEMP3uyY4RQ21ePwIALpMV/GDpAyD4SeL6hWi32vQ
197YD1LPuLWrEbUs/+gl1Sk2gIsWWlq/o86KcP7Cn4fZdBAKEiF5RpQ6iPsO2+bj
JR0W/EbgUyzIhYaxFysCzQ1HPzQx+0a2vHn/6FsB7YMha8gvxviF7InDEwcfxbok
o0QS5SeYWryp5mH7IokC6fLYsAPmiueugPVRSD/l8IRFYWVFS9nB+XAR1PWAdYSQ
Xyzu9oyPwlKAjYKxl4XHYB4DofacS89DpWMVbWHviYiZ7UufmzMgwPtfMCsQAxSb
q3OMAkcSGJZL8pcy9/9NWpOGAHY2DRtGtu8oSqXcBSW/IQCubmUNmzopt8O/H74=
=9hrW
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 12464 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/d36e6db3/attachment.bin>

2023-06-07 17:22:55

- reply

📅 Original date posted:2014-06-16
📝 Original message:There can be multiple independent transport networks for Bitcoin.
There already is: ipv4, ipv6, Tor, and native_i2p (out of tree patch).
As long as multihomed hosts that act as bridges then information will propagate across all of them.
--
Justus Ranvier
-----------------
sent with R2Mail2
----- Original Message -----
From: Matt Whitlock <bip at mattwhitlock.name>
Sent: 2014/06/16 - 13:10
To: Mike Hearn <mike at plan99.net>, Justus Ranvier <justusranvier at gmail.com>
Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes
> On Monday, 16 June 2014, at 7:59 pm, Mike Hearn wrote:
>> >
>> > This is a cool idea, but doesn't it generate some perverse incentives? If
>> > I'm running a full node and I want to pay CheapAir for some plane tickets,
>> > I'll want to pay in the greatest number of individual transactions possible
>>
>> Peers can calculate rewards based on number of inputs or total kb used:
>> you're paying for kilobytes with either coin age or fees no matter what. So
>> I think in practice it's not a big deal.
>
> So effectively, if you pay for your bandwidth/storage usage via fees, then the reward system is constrained by proof of burn, and if you pay for your usage via coin age, then the reward system is constrained by proof of stake.
>
> Now another concern: won't this proposal increase the likelihood of a network split? The free-market capitalist nodes will want to charge their peers and will kick and ban peers that don't pay up (and will pay their peers to avoid being kicked and banned themselves), whereas the socialist nodes will want all of their peers to feed them transactions out of the goodness of their hearts and will thus necessarily be relegated to connecting only to other altrustic peers. Thus, the network will comprise two incompatible ideological camps, whose nodes won't interconnect.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 532 bytes
Desc: PGP/MIME digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/b09ddd18/attachment.sig>

2023-06-07 17:22:54

- reply

📅 Original date posted:2014-06-16
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/16/2014 04:25 PM, Matt Whitlock wrote:
> How can there be any kind of lottery that doesn't involve proof of
> work or proof of stake? Without some resource-limiting factor,
> there is no way to limit the number of "lottery tickets" any given
> individual could acquire. The very process of Bitcoin mining was
> invented specifically to overcome the Sybil problem, which had
> plagued computer scientists for decades, and now you're proposing a
> system that suffers from the same problem. Or am I wrong about
> this?
If you allow the solution set to include pay-to-play networks, and not
just free P2P networks, then it's easier to find a solution
Imagine every node is competing with its peers in terms of relevancy.
Relevancy is established by delivering newly-seen transactions first.
Each node keeps track of which of its peers send it transactions that
it hadn't seen and forwarded to them yet (making sure that the
transactions do make it into a block) and uses that information to
determine whether or not it should be paying that peer, or if that
peer should be paying it, or if they are equal relevancy and no net
payment is required.
Once any given pair of nodes can establish who, if anyone, should be
paying they could use micropayment channels to handle payments.
Nodes that are well connected, and with high uptimes would end up
being net recipients of payments. Mobile nodes and other low-uptime
nodes would be net payers.
Now that you've established a market for the service of delivering
transaction information, you can rely on price signals to properly
match supply and demand.
People who hate market-based solutions could always run these nodes
and configure them to refuse to pay anyone, and to charge nothing to
their peers, if that's what they wanted.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJTnyRMAAoJEMP3uyY4RQ21XwgH/RPlhgR63XF9/Sm+z0EBxVtO
0hzDngD0iTO1v5LRmas9P5ZuQ97j8169pui+EJO8clXjV41yEu96jc0BiOQTnfMR
rzPfgeZqfnVNDvIfJnLRMeVCJMiu9Tjdqx83S28Tz9sx/sgy1uw9INX7M7wOIHFR
7GLA16k4g8qcmnX89XXM3Uf7/3fhL2kiN/E59V2n6qYJAnYTUEb+uehclzR+T4v4
93oAF3TjgLU6J0VleDrvgFcyLriGBjOmkTAvmOJQF1H/s4gzHol5kbOb9vqQ7BJX
QQ/mEYHEdCHTxU59FdZ5CmFYZrINHj+mNnu1RorYYF1FLbBDTDpq4zjrJpngayI=
=9qQJ
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 12464 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/7a64d188/attachment.bin>

2023-06-07 17:21:43

- reply

📅 Original date posted:2014-05-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/19/2014 09:11 AM, Jeff Garzik wrote:
> Meh. I like example configs, perhaps tuned by the distro. If the
> distro (_not_ Bitcoin Core upstream) chooses to install a
> bitcoin.conf in the proper location, that's up to them.
>
>
>> - bitcoind and Bitcoin Core should be in Linux repos:
>
> Agreed with conditions: 1) The distro MUST let bitcoin devs dictate
> which dependent libs are shipped with / built statically into the
> bitcoin binaries/libs. 2) The distro MUST permit fresh updates even
> to older stable distros. 2) The maintainer(s) MUST be active, and
> follow bitcoin development, release status, etc. on a near-daily
> basis, be able to respond quickly if security issues arise, etc.
If we're talking about making bitcoind behave like a proper daemon,
then syslog support should be on the list.
Also, the option to store things in FHS-compliant directories (not
somewhere/.bitcoin)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTebHTAAoJEMP3uyY4RQ2170IIAMDcx5rj/ZlCTJTOJ2sFttFM
miK9t7oewJ73UpgvFniCUngfjk9Tt5knmskQYEMQ5C9Do/P3Deh1gF6MBBuuai5G
kDNDv51zMEqhwGcqGrPYFMV3NEnBEjullTMgJFvKJf1kZRo7uplwp+eUhILjgSY5
mZjLIUK8iKDNn+Pi8/2UetAvyaRibHAsAnkJnEeOoKAhxUbtzjgZsj08loCCmJrs
RleOTLgArdc33e1bwTTwsS9DDvF18RNTACglsc75Oz0ohHyc5U1A1hBfaRuyu6Fv
8BK+0KPg/zdBCnM1m3aueVukg9p3kIfB2VUVFBHBTo4CPMi91k6oldbfRHy8dXw=
=SjxO
-----END PGP SIGNATURE-----

2023-06-07 17:19:41

- reply

📅 Original date posted:2014-04-29
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/29/2014 02:13 PM, Mike Hearn wrote:
> I do think we need to move beyond this idea of Bitcoin being some
> kind of elegant embodiment of natural mathematical law. It just
> ain't so.
>
I think everybody understands that Bitcoin has a positive net present
value exactly because it, unlike every other digital currency which
came before, does not include a feature that allows for balances to be
confiscated. Implementing any such feature, to any degree at all,
would render Bitcoin completely valueless.
There are two possibilities here:
If you understand this, then your proposal is a malicious attempt to
undermine Bitcoin.
If you don't understand this then you suffer from a very serious case
of economic illiteracy, a case so bad that your continued
participation in Bitcoin represents a clear and present danger to all
Bitcoin users. If you can't even get the easy questions right, then
god help us all if you're ever faced with a difficult one.
I don't have enough evidence to distinguish between the incompetence
hypothesis and the malice hypothesis, but it doesn't matter.
Regardless of your abilities or motives your proposal is unacceptable.
If you want a currency where miners can vote to steal from other
miners then implement it in Hearncoin and leave Bitcoin alone.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTX/2dAAoJECoisBQbQ4v0jAoH/R1oNZ1tVp6DJ5BuPg0ZTav0
Dvzq8EfX/uRbRgmxotCHMwY6FJCoXqJTLyOnl2p670t7l5ZXqd91MdKKP2z7jYPY
GsVbqfGreF0dWKCd0mKTG5DM8pxndNWteGIsw9/sYvY/3p2Vopzp6N7fpl8TEf6p
2nyIzEqTD4aK5QkhM+sNnP1Cyh/l5AjJTES23GqSQIMG6vzLgqE8kyze+ANFVg1U
yka6bz4DX7DO7meyJyyOFaMJu6mgY+m6dSVaR7j/QmQMu22SwlSiPgqe6iO//os3
zcmwe/x4+5CmqJOO/PL5Or28iw/Qdf6vNePiaEIFtBzoKnHBhS2nAtL6jnOL928=
=4yIu
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x1B438BF4.asc
Type: application/pgp-keys
Size: 21678 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140429/b00469ee/attachment.bin>

2023-06-07 17:19:36

- reply

📅 Original date posted:2014-04-24
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/24/2014 03:37 PM, Jorge Timón wrote:
The 21 million bitcoin limit is not important because of its exact
value, nor is it important because Satoshi picked it.
The 21 million limit is important because users hold bitcoin based on
the promise that the block reward will never be adjusted ex post
facto. The behavior users are relying on is "The bitcoins you hold are
forever a calculable fraction of all the bitcoins that will ever be
issued."
That's what bitcoin holders agreed to, and that's what can never be
changed.
The fact that the number is arbitrary is not relevant. We can agree to
meet for lunch at some arbitrarily chosen time, and the fact that the
time was chosen arbitrary in no way means that one party arbitrarily
choosing not to show up doesn't break the agreement.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTWUTWAAoJECoisBQbQ4v0JiwIALQtf4GrNaIdEidJr+f3z8G3
smDgU5xXhN4+1Eo5xU/ZmQy03tU5E00/PRiMTHz1RNXeO+w/iu4PlAJN7pk5oy75
QzDtaCzDjKMCN+1PCQ5VNCL04ws8JifU6QLxSgXgsShBnv19FlxiejgvjNWg+Lzc
uHxyP0PlvfF5BWTiEV68KYcfQPbamOH7Vb8v4tQ4/j/ioA7mYso+Q0jX0Y4ae1FN
XNs4KnTsIFTsXWzBIYFlFPwQ5d+mdG84W7FpmwwcXaRWQxMwdJq8QjlUuFng439B
6OgQqtq4wmvwoPjKS5nOesfdrdH9Scx2zg6uwhaY0zKMtPW/CEzzLFUfq+cZ6q0=
=r+t0
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x1B438BF4.asc
Type: application/pgp-keys
Size: 21191 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/6283c3e0/attachment.bin>