<unnamed>

Public Key

npub1k2eekmevs6gg60df75qpjw4a2atmy89vx28c8zqq5jxy64tuzrws39qd6m

Profile Code

nprofile1qqst9vumdukgdyyd8k5l2qqe8274w4ajrjkr9rur3qq2frzd247pphgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsfgcd45

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:45:38 CEST

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

- 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:02 CEST

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

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

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

- 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:41:00 CEST

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

- 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:38:40 CEST

- 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:40 CEST

- 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:38 CEST

- 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:33:12 CEST

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

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

- 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:10 CEST

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

- 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:54 CEST

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

- 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:17 CEST

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

- 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:16 CEST

- 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:15 CEST

- 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:28:48 CEST

- 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:25:19 CEST

- 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:22:54 CEST

- 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:47 CEST

- reply

📅 Original date posted:2014-05-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/19/2014 10:06 PM, Mike Hearn wrote:
> Sorry. I will never agree to the concept of a relevant idea so
> dangerous it cannot be discussed. That's medieval thinking. If you
> would like to create a parallel development forum where people have
> to swear an oath not to think bad thoughts, go right ahead and do
> so.
>
> But I'm glad to see you correctly identified yourself as one of the
> people causing problems on this list. Your vicious attacks are one
> of the reasons we're now seeing threads that start with "I hope I
> don't get flamed or laughed at for this idea but ...." which is
> totally unacceptable. I would prefer you just unsubscribe, in the
> hope we get a second chance from some of the potential developers
> we've lost.
>
I'm glad to see you correctly identified yourself as well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTemXNAAoJEMP3uyY4RQ21KNUH/12vTPOPNjQQIunTkNCSqV6P
hub7mrW/hS4NSlK7P3Laq5qj+qB9ou/uIRCPP6uIhk6scicbukn31nw1p/er0YoQ
XGFE+SmF+Z5Ysz/5uA1OP9VdjBKggbI6rFVZKbt5DwrFK0gCDMtgcxO2y6CFGR+U
mFhD9ORf/NdAozFanXSEk81p5OfZqhhnxaPPpPnwQeojtLwE20reLrEcCKy6XMEs
Mtfan+qgPJYTmWiWmDHsrFsz+5HwpkR5giDf4hzW5J1F8Vj+LTPXjGz9Txldk89t
0dRmYFAtE74QgXsIRvWny9ho4YL/Nn+WHf0Qf3HKh31wrzSea0KFKpPaa32xpKA=
=jIov
-----END PGP SIGNATURE-----

2023-06-07 17:21:46 CEST

- reply

📅 Original date posted:2014-05-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/19/2014 09:41 PM, Gavin Andresen wrote:
> Now I'm really confused.
>
> Why would Mike or I have the authority to write a "social contract"
> to promise anything about future-Bitcoin?
YOU can make promises about YOUR future behavior. So can everyone else.
The rest of the community can keep track of which developers will and
will not make promises about what changes they will and will not
attempt to implement in Bitcoin, and they can use that information to
make informed decisions about which software they will choose to support.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTemMNAAoJEMP3uyY4RQ21KJMH/1MbnPxZ42sjVjEiGSQBkGfE
E3jt8aAf2DTza8xtybSmT/pHVhx/VUT4UNj9oBZayqJ1eUNr6YMgGCP8J+DxBtN+
mYH4lTnCiR4+hjO9aux0AWFV+hfZSq7A41QH6wymLa5CyywOtc+i7i3qU5ZGrbtX
9yBrQpFilvMIlrAOBDlXUwb06FDK17ZHHX4V5sI8PSRYJvoiWCrk12Vqj1Z95UOy
ayzWGwbO30ky6lGirBXfpu2e2WJADE9sc43ecNCDplUMR4D4n9jwAUldEiMSBKg2
pwUNcfj1gaKkscj4QmGKMbq6yug+lrSa8qq/jFsbQq+2pqT4VjlQlrN52wz7Yeg=
=Jafe
-----END PGP SIGNATURE-----

2023-06-07 17:21:43 CEST

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

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

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

2023-06-07 17:19:31 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/23/2014 06:15 PM, Peter Todd wrote:
> But I also agree with Gavin that the bitcoin-development email list
> is a perfectly good place to have these types of discussions. I
> myself have used it repeatedly to publish ideas specifically due to
> wide readership and multiple independent archives.
A development list is a great place to decide how to implement a
technical feature, one that feature has been deemed desirable.
The chief scientist has a platform via which he can publicly announce
proposed protocol changes. Anyone else could do the same.
There are conference happening all the time where people can announce
ideas like this, to give time for the community to hear the idea and
generate feedback.
There is absolutely nothing so urgent about this attack that requires
the consensus process to start here, in a place that most Bitcoin
users don't even know about and wouldn't even know which search terms
to apply to look for such a discussion if they did.
>> PS: We don't even know who runs BitUndo. They seem to have lots
>> of money to spend on web design - I wonder where it came from?
>
> Actually we do: Eric Springer
>
> See
>
> http://www.coindesk.com/double-spending-unconfirmed-transactions-concern-bitcoin/
>
> https://github.com/espringe - joined Feb 11 2010
>
> Anyway that's just twitter bootstrap or something; I hear the
> wizards can pump out a site like that in a few hours.
>
I stand corrected.
- --
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/
iQEcBAEBAgAGBQJTWARRAAoJECoisBQbQ4v08kkIAKMSSCn9mBCMj6RwWHK6abud
UlaKOAh4LNAaJ+pIQD103EGH3JE9pzeaDouupTbdIHqb8CxVO3dn9UFXdfkDW1cf
YsOOfE0N5crfaODd+NU6jjaf5jXOgmT2ibCU3sSjmphDBMstZfrSaCljtyaj290Y
urnW1pdL5ZA0zLAUjNO2kXSbuHaE3CTz72s4dWsiRBsQLVAD8j5C5o8gxFVeZd7s
Ba4yGtGAsd0HWikUjE2L4G/J8RzbxUrm5w31A4lawkF+SqtJcFiwoxrXX+FVdi/8
rfAY/l0EBoRrkW+cajcj29eq1eOOIER0Zcu2FzpPc45Xywh9RCh8C3zgWitOvcI=
=IR+Y
-----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/20140423/bf90e17d/attachment.bin>

2023-06-07 17:19:31 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/23/2014 06:37 PM, Mike Hearn wrote:
> If you want to try and argue that the development list is the wrong
> place to discuss development, please do so on another thread (or
> your blog). Let's keep this thread for discussion of the original
> proposal - ideally, discussed with the dryness that a topic as
> nerdy as distributed consensus algorithms deserves ;)
>
Is that what you say to yourself to quiet your conscience at night
(assuming you're one of the non-sociopathic humans who does indeed
have one)? It's "just a nerdy distributed consensus problem"?
The things you're talking about fucking around with have real life
implications for quite a few people and your casual dismissal of this
is precisely why I responded in the way that I did.
What you're doing is reckless endangerment and you're not got to get
away with brushing it off as a mere technical detail.
Sunlight is the best disinfectant, and this episode is demonstrating
to the world exactly how averse you are do that kind of transparency.
- --
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/
iQEcBAEBAgAGBQJTWAsmAAoJECoisBQbQ4v0XTcIAL70+EAkSMUgvGeTN+mROkkd
3ap5NhUYehfW33gEEEyO3a6ofrb6k1a8EbHlzDyq7qPZ925kdvbnwqXDQm7auAh1
V8IPAwp+JfCgVDVAxtHuUBUvTuuCn1Mrxnf6ppwzFywBxU6l6KYK9zac1HoX3EVY
QxME15zrBmtJfo9/ed9yWz8ZXl6nsx47D3r0VE8FiENJRgxLfZ7Odsr/sGvgL71N
aYPv7vMxRBNXDvrMhEuYKa3L83W5kv4JJxzueUyO/0bww/aaeZMZr850u/hUjMgU
ui37M+kiFHug3semWGKs1yJiKsEPsEPaU4j6WSDrd0bNbc73bBjvHm9SGYRHzDQ=
=L5nX
-----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/20140423/a3c7daac/attachment.bin>

2023-06-07 17:19:30 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/23/2014 05:57 PM, Mike Hearn wrote:
> I'm not going to bother arguing in replies to a blog post. Suffice
> it to say, miners are already handsomely compensated via both
> inflation and fees for doing their job of preventing double spends.
> Your suggestion is people should pay them EVEN MORE for simply not
> being corrupt. My proposal is simpler - how about we find the ones
> that are claiming people's money via coinbases yet not doing their
> jobs correctly, and take the money back (or destroy it). I think I
> prefer that one. Miners that are maliciously double spending cannot
> justify their existence, they offer no useful service and do not
> deserve compensation as a result.
>
The integrity of Bitcoin is more important than you and your personal
preferences.
You don't have the right to decide which valid scripts in the
blockchain will be disregarded, and neither does anyone else.
If you don't like what's in the blockchain, you and everybody else can
work within the protocol to orphan the offending block.
But if you fail, then what's written in the blockchain is final and
the sole purpose of the network is to enforce it - deal with it.
PS: We don't even know who runs BitUndo. They seem to have lots of
money to spend on web design - I wonder where it came from?
- --
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/
iQEcBAEBAgAGBQJTWADBAAoJECoisBQbQ4v0A/0H/25j9bvZaEqfyLJSHNh7PGwC
TpMu0s8D94nX/ipwaOjeY1QMtnWnX9b2H/lDZSnk1rm7IXJTq1c+R/50Uqx5U9QI
oYnsKX1TiB+T5Uv0C5PaIptEMgPkcNyHwsdXyaaUcu2djB0/YhFRlWR7WCH2QyNG
3LR5XWLGJz7v6rDxwvMXEHJWO5950bASP1xCVLc/N0PI7BoEUmeRzAoDa1mGJ9yw
XkVUVDV03B85uTSEriBuQ49ASvv9faAhcehwRwvFFp2krVz6Ov5Jxrv7UN+B61R2
sgZhI3vaTsyRf+8+pkp0dvSpbwwJ7ESBm+BRMPGTnV1AlwJKqjzDYHgowSe01Nw=
=COsH
-----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/20140423/22a72186/attachment.bin>

2023-06-07 17:19:29 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/23/2014 03:07 PM, Mike Hearn wrote:
> On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier
> <justusranvier at gmail.com>wrote:
>
>> If enough miners don't like a block that has been mined, they can
>> all work to orphan it without any change to the protocol
>> whatsoever.
>>
>
> As was already pointed out, yes. However this requires them to
> immediate establish a majority consensus and be absolutely sure it
> really is the majority. You suggest an out of band mechanism for
> that, but why is this better than using the actual consensus
> mechanism you're trying to measure?
>
>
>> Once you've changed the network such that it is no longer a
>> machine that faithfully processes scripts
>
>
> Bitcoin imposes far more rules than just execution of the
> scripting language, many of which are entirely arbitrary and the
> result of (controversial) human judgement, like the inflation
> schedule. You can't claim Bitcoin implements only some kind of
> natural law.
>
I've formulated my replies to you and this proposal in a more public
venue, where such discussions of existential changes to the protocol
more rightfully belong:
http://bitcoinism.blogspot.com/2014/04/dirty-deals-in-smoke-filled-rooms.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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTV/Y0AAoJECoisBQbQ4v08NcH/RfkaBAcS5eAKmwePqFuqIUN
xJKyIWo+tyY1vPYgArCVNsYr3YM8Wc5fkpqLNxCaM7S0/UmO8YaOdiD7XJyl7bF9
xAveyRt1mfHhx9x6hnPLYbe8WKqtjssSt6MglN8OXtf0EDO+eIxPj6Ya8OZ5YJrL
N8SMHaDs2J+qy3Qfec9keE5dyhYLNRC6PjYPVvrRAyqFSjt/8r4Z2a4r0oqvv3Yt
mYU1Tx+WoXMKXWY/Dwql1NLbuspZsOhPx/ncROZ5KVryCdrcW/GEIEQ6P0AIdHvT
TKYJzh1bdRDYDmVS5z8nUG6waxJwuWPStQo7UYdg26daRUw5qPzjO9SMLLFZPCU=
=OOck
-----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/20140423/4c0947ef/attachment.bin>

2023-06-07 17:19:29 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/23/2014 05:47 PM, Gavin Andresen wrote:
> And why do you think your blog is more public than this open,
> publicly archived mailing list???
>
Non-developers are more comfortable using social media tools. Blog
posts can be shared, Tweeted, and commented upon using nothing more
than a web browser.
The barrier to participation on a mailing list is higher, and the
visibility is lower.
- --
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/
iQEcBAEBAgAGBQJTV/0yAAoJECoisBQbQ4v0Fm8H/j0fG7s/iEQUDlV2+5mxeiBO
eoPY2gwuDSTjXc74/3olPHrL/BTGtGg90zwFmlwruUJOaW2m3xvbTD78S8e3HmCC
fqqFKQLg+gOQYud2oiHVNW6H++QqKgSJXu4Lr87ZTkpiRGTgr5PWyhe+4sLeXxam
InqcFmtTHiUMKlmiPj/FUaPHxYT+n+FaPuiZRUYt0Wfxcc9b1n6gEpV7r36Wh8gl
e3rMeDwTfsj/0R4+E+oFEgPl7XBGIJWAf4Nzebuog4ABlqzm4B/RlclZ/5N3W2zZ
6ym6dGpFwN+RuDY2/S2kah6dAeKyk2mAsAChoSOj+vfhCW9wKzclVyM2FNV6lwE=
=djWj
-----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/20140423/3e5c938c/attachment.bin>

2023-06-07 17:19:28 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/23/2014 07:55 AM, Mike Hearn wrote:
> 2. Miners can vote to reallocate the coinbase value of bad blocks
> before they mature. If a majority of blocks leading up to maturity
> vote for reallocation, the value goes into a pot that subsequent
> blocks are allowed to claim for themselves. Thus there is no risk
> to voting "no" on a block, the work done by the Finney attacker is
> not wasted, and users do not have to suffer through huge reorgs.
If enough miners don't like a block that has been mined, they can all
work to orphan it without any change to the protocol whatsoever.
Why are proposing this a change to the network that allows miners to
vote to disregard output scripts, instead of creating an out of band
network via which miners can coordinate actions using the capabilities
the protocol already allows?
Once you've changed the network such that it is no longer a machine
that faithfully processes scripts, and instead is a machine via which
a set of controllers can decide which valid scripts will be honored
and which ones will not, what will be the next proposed condition
under which the miners can confiscate and redistribute balances?
- --
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/
iQEcBAEBAgAGBQJTV9OUAAoJECoisBQbQ4v0XE8H+QGcOc3JiYsS2/xoR8SqpyEx
gDChDFvhaao9qMPhfxBG0bso+4ITZ5c3mJawkqdBm3ZZPeygt1fLqvxe4c1AWocH
YCf9CyZJlm8KsDJOqorja5o/6oXjH5xiGgVi042Jhb9wj/aGNPFvL9X6DGhEeFKQ
uXFN4wTSPViEOryVqo3vEFh3md9Y1AIqcvc/b5M+EAtvaAD33/ALnzY9CNKymQZE
o0JGLEfwamKkZ+QA0mTfeDheJe9kj0KOQhXqOG/x3NlKCFVpmGz3daWZHJCFMDb4
+RmDwoxOKvXxgveXu9w4d3bc3SQZ75hygmeMvVQwZggia31wqrHtsWLqIiFhVnU=
=hpdg
-----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/20140423/6ba05543/attachment.bin>

2023-06-07 17:18:17 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/09/2014 06:50 PM, Gregory Maxwell wrote:
> Who says anything about a broken incentive model. You've made past
> claims about resource requirements that I think made no sense and
> then failed to defend them when they were challenge.
Anyone reading the archives of the list will see about triple the
number of people independently confirming the resource usage problem
than they will see denying it, so I'm not particularly worried.
- --
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/
iQEcBAEBAgAGBQJTRZhsAAoJECoisBQbQ4v0iD8H/A1RZyLJN6f+zt5x78CFgRdp
zqZua3NBwUN2L9mI/PU1NADtxoXgkq49XusHRc+bjLu17VxGMUOsmB+AeK3VU4sN
BVC1qIcWCa+OPMkgnMFrdydz4OGxX5xiJoCNsqveZIEYc8nQoCDfsn/fwqL50/Ct
NfmPzh/cW7uUZ+h2bBgduGD3fzpQBlnnswAbHHX3FbBh9MvcaCfROeXXqUCedWj9
H2qVCNWTkIFJksJkqyF3f+KfedOTIyUwflx/0niBvzXcP9w4oK+WpBApHACWxiSA
H3KHYNF0s2/fs+mIkabPLRX1PIUk15ln29FapoDvlHW9jzDE92x6JFnMppI4rEs=
=ILks
-----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/20140409/509a4b23/attachment.bin>

2023-06-07 17:18:16 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/09/2014 06:19 PM, Wladimir wrote:
> If no one wants to volunteer resources to support the network
> anymore, we'll have failed.
If the security of the network depends on a broken incentive model,
then fix the design of the network so that economics works for you
instead of against you.
- --
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/
iQEcBAEBAgAGBQJTRZLiAAoJECoisBQbQ4v0RRMIAKL84ju4b9XAls9sOxQGrLMr
xifQDhThCQKC4/qkOmGU8zseIdKRgXEq4auMF9/0BlgoSxsBcKynlRH2fFtYY7ol
sdjCy/5dk+MBu3K1GCvNn/cuGkpIJJxrom/9riSiaPtivE5ncl7cyW5hFqf2MzRd
dF6q937ocgBd8d2VuOQleQ9N5gue1+du77soxfp8oY7dXNdwk5ZrngeYxz1umsjQ
lBAI/3JYkKVhU5Rte3deJcMHe6xA+neIzvcfWbOZYrkdwWE+jLSKnDkDkCOXJnuP
vOI8CAteaFctV2mfgXX2CmNDWVeFsyCwoQwbnCmuE/uiM5y235PcTrsyr6U+Zzs=
=oQPK
-----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/20140409/2996507b/attachment.bin>

2023-06-07 17:17:37 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/07/2014 11:34 AM, Mike Hearn wrote:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
>
> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people *might* stop running a node (uses too
> much disk space, bandwidth, lost interest etc). But does anyone have any
> idea how we might get more insight into what's really going on? It'd be
> convenient if the subVer contained the operating system, as then we could
> tell if the bleed was mostly from desktops/laptops (Windows/Mac), which
> would be expected, or from virtual servers (Linux), which would be more
> concerning.
It doesn't do much good to only focus on the immediate symptoms at the
exclusion of big picture trends. There are three things happening now
that have nothing to do with operating systems.
1. The resource requirements of a full node are moving beyond the
capabilities of casual users. This isn't inherently a problem - after
all most people don't grow their own food, tailor their own clothes, or
keep blacksmith tools handy in to forge their own horseshoes either.
2. The growth of small and medium-sized native Bitcoin businesses is
lagging #1. Native here means their revenue and expenses are both
denominated in BTC. Most business adoption we've seen so far doesn't
actually handle bitcoins themselves. They use Bitcoin as a payment
method whose processing they outsource.
Contributing to this is the fact that Bitcoin Core, although it has made
great progress in the 0.9 release, can't be accurately described as
"enterprise ready".
3. The P2P protocol used by the network is broken from an incentive
perspective. Resource usage wouldn't be a problem as long as the users
which consume resources pay for them and the users who provide resources
are compensated, and they communicate via an efficient price discovery
mechanism. Right now there is no obvious way to incorporate price
discovery for bandwidth usage or storage space without a completely new
P2P protocol, and the effectiveness with which progress has been blocked
towards price discovery of transaction fees (the area where it is most
obviously necessary) means that I'm not optimistic that this subject
will ever be effectively addressed by Bitcoin Core.
- --
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/
iQEcBAEBAgAGBQJTQsgzAAoJECoisBQbQ4v0ZA8H/1YIJAg7AEUUe5RnuuAz7lVV
uiHtpmbmGaZ+Bd0qi1DEfPdeBP9bDKpO3O5napmtz+mqIE5H3VgAVg7z9U0sMf16
sZAJIWuVCg2drY/NaE+n3TKEEd4Z1Zj51rWde/KD6xjgR2usV9nLugkEJdLNahZu
0EbdAv40oCSZ8PScNElYqQyM8qcbta7LuDRCnnWvCyunZJzL4LSkQwDcsAWQ+oSv
FyqKY/e1Kd6mLyrN/NppMzdqiLv95zmE56Qkh6rlKeF+JgXxlfiEfDv8osl8IWJR
TOpmW0Dr+E4qe9E3nA7X5gV46nf8gxGZ4b0cUP+wivN9RRaE27+JlKhKaAV3ulc=
=vdPa
-----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/20140407/a3b1250c/attachment.bin>