John Dillon [ARCHIVE]

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

Public Key

npub15z6e9t07ugx267aj3s3c487pln852ydytzlgu0vkkqxfznyvx4jq4kn0zr

Profile Code

nprofile1qqs2pdvj4hlwyr9d0wegcgu2nlqlen69zxj9305w8kttqry3fjxr2eqprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqwjlupe

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub15z6e9t07ugx267aj3s3c487pln852ydytzlgu0vkkqxfznyvx4jq4kn0zr

Show more details

Last Notes

2023-06-07 15:09:23

- reply

📅 Original date posted:2013-11-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> Last week I posted a writeup: "On the optimal block size and why
> transaction fees are 8 times too low (or transactions 8 times too big)".
>
> Peter Todd made some nice additions to it including different pool sizes
> into the numbers.
Peter claims on IRC that he is writing a paper of some kind on this topic. I
suggest he submit it to that crypto-currency thing the foundation is
sponsoring. Given the Nov 24th deadline, I also suggest at least making part of
it public ASAP so some peer review can be done. It would be a shame for a
simple math error to cause embarassment later.
> However, it occurred to me that things can in fact be calculated even
> simpler: The measured fork rate will mean out all the different pool
> sizes and network latencies and will as such provide a simple number we
> can use to estimate the minimum fee.
Are you sure about that? You are assuming linearity where none may exist.
> Luckily the fork frequency and the average block size are easily
> measurable. blockchain.info keeps historical graphs of number of
> orphaned blocks pr day
Are those stats accurate? Have any pool operators at least confirmed that the
orphaned blocks that blockchain.info reports match their own records?
My gut feeling is to relay all orphaned blocks. We know that with a high
investment and sybil attack as blockchain.info has done you can have better
awareness of orphaned blocks than someone without those resources. If having
that awareness is ever a profitable thing we have both created an incentive to
sybil attack the network and we have linked profitability to high up-front
capital investments.
On those grounds alone I will argue that we should relay all orphans to even
the playing field. If there is a circumstance where we do not want the attacker
to have that knowledge we have failed anyway, as blockchain.info's sybil attack
on the network clearly shows.
> Anyway - the all important number is alpha, the network latency which we
> expect to be dependent of various things such as interconnectivity,
> bandwidths, software quality etc, where mainly the latter is within our
> hands to bring down the fee. And you can actually setup the standard
> client to choose a better fee, as all the parameters in the formula are
> easily measured!
With relayed orphans you could even have P2Pool enforce an optimal tx inclusion
policy based on a statistical model by including proof of those orphans into
the P2Pool share chain. P2Pool needs to take fees into account soon, but simply
asking for blocks with the highest total fees or even highest fee/kb appears to
be incomplete according to what your and Peter's analysis is suggesting.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSg9pfAAoJEEWCsU4mNhiP5mcH/jKd2Rpl9gEJ7WhTndS5gYJ9
Ep151NyD/iKpAA4E/d9QVYalo8595LCqnrXnV6wuvuiifB6EJD5WBJq3MAMyaJLA
agl920ygY98slhDmFhnwlU9lkJVim5FoUkZgE7lQ5dr0MIhvoLQiF2Ywky49Izf0
IqL+nyW83AQweSalvktA+XGkDfGDV/EnJN7SdNqKDNtE7E9NeMl61NNOWNndsYy6
uT4PF2YB7rh8wGyHXMTC4Z192pfW4S4s60ZAflG/sTtWCcEwWi+5V/RIu0o5Hmog
RFpEPvc6d6ykdqtPfTRADMGkT2wC1yXsgeos9oFFVVuVSj8EqHb2db0B+psHRBk=
=76Qs
-----END PGP SIGNATURE-----

2023-06-07 15:09:19

- reply

📅 Original date posted:2013-11-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Nov 8, 2013 at 4:21 PM, Goss, Brian C., M.D.
<Goss.Brian at mayo.edu> wrote:
> Peter,
>
> What is the propagation time within a pool? If my pool is made up of a ton
> of fancy ASICs connected by 300 baud modems, how does that affect your
> analysis (ie, Q for a mining pool is effectively a function of time as
> well)?
The propagation time you're thinking of is from the pool to the miner, and even
now that is significant for pools that do not pay for stale shares. I remember
an Australian pool mentioning that problem on their website as a reason for the
pools existence.
I would expect selfish mining, as well as orphans becoming more important in
general, to centralize the physical location of hashing power too. If the 100ms
delay to your pool impacts profits you'll have an incentive to locate your
mining equipment physically closer to the pool. The next step is pools wanting
to physically locate themselves closer to other pools.
It would not be good if all Bitcoin mining was done in Iceland...
> Brian
> P.S. I hope these are not ignorant questions; if they are, please feel free
> to disregard!
Not ignorant at all IMO.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSg+CpAAoJEEWCsU4mNhiPufwIAKNpBBvlRvSQZOzMJvghG7fX
lCNliohDKw9kdKJJjN1T73Ssl06wGbBe881k4c4r7fHeNDRQZbrFsj+uBsFyUhmy
CF70KiOKuowDlWwyWMxZbbyinK0mEKC7J/hJVOt15FHubLnq71Utb+I2L7seyHlo
2E2byG4UnofoD5L+hGzfD6FJ/zYEHtTKgFw7Y1+ZSmAxlIcdrcpH7tPmUzFD7JPi
RnaK1BH7hpM6FyZQUhSC/tW7mYswNEasvouBE4V1vSySZb6S43kiED2Q4uH3W0+A
UtbyRQ7yT3BOLGB2OO/L92tg6S7WRyMtvQoevJkEIAnUywD3YWaZnBbf0IM4LWg=
=6750
-----END PGP SIGNATURE-----

2023-06-07 15:09:13

- reply

📅 Original date posted:2013-11-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> To peer with the public relay nodes, simply select the closest region
> out of us-west (West Coast US), us-east (East Coast US), eu (Western
> Europe), au (Australia), or jpy (Japan) and add
> public.REGION.relay.mattcorallo.com to your addnode list. Note that
> since all of the relay nodes will relay between each other, you gain no
> latency advantage by peering with more than the closest node to you (and
> currently all the regions map to one node, so there they're redundant
> anyway).
>
> For each relay node, you can connect to either port 8334 or 8335.
> Connecting on port 8334 will relay only blocks, and port 8335 will relay
> both blocks and transactions. The relay nodes will request any
> transactions which appear in your invs no matter which port you connect to.
You should split the block-only and block+tx not only by port number, but also
by DNS address. DoS attack by flooding blocks is fundamentally more difficult
than DoS attack by flooding transctions, so doing the split by IP address
ensures that in the event of an attack the more important block relaying
functionality is less likely to be damaged. In the meantime point both DNS
addresses to the same IP until it becomes an issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSg91YAAoJEEWCsU4mNhiPq2oH/03kVqfHsXJ1l10qHhYaBPMy
Le26Cp30Jt9BELiPVQISWjPeuOLsB0m7Say52GWHxBCfoNx3NYag6p8G3woSdWqv
guc5U2lTwfhXS5R7y0B5diaGJ+Jaq70me4DYGdEnmkBf0F38wcgOtK92V2esLyVx
TmCsRGxjAE8Ary0YHJOlb7sU4CNvQ8k1PDX6Hd+GCZVMvRtisILunGV4UDgSS62u
yddZfrOs0yWZr2bwwI4koB2Sc0cFjK6/gMhr/d19ikQj2i2uqxYtwZIxuaAvYNdA
hSmeouR4EFtVHTEQybF82VcfGcTcU11HncyKHU6FOAZQLZUgc3A/M3QgXc0mQrI=
=l6GI
-----END PGP SIGNATURE-----

2023-06-07 15:08:19

- reply

📅 Original date posted:2013-10-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, Oct 26, 2013 at 3:31 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> One limitation of the payment protocol as speced is that there is no
> way for a hidden service site to make use of its full authentication
> capability because they are unable to get SSL certificates issued to
> them.
>
> Thoughts?
I think this is a great idea and wish to see it done. Here is 1BTC for you,
redeemable when you finish this task. I trust either Jeff Garzik or Peter Todd
to evaluate your finished product, or possibly someone elses:
37NDa6iFLEozbvw8vj38ri5D6SLw5xQujS
22e067d3317e6300a9edda84fd0e24d8bfb86cf91540c3fe7acff45e4dc64dd3:0
redeemScript : "5241045f4bba15dbfe94a45f362aa13bbaef8bbf21ff84fec1be5b27fa628f4b3acca1a2e5711503c8b8fe2e228229b8b8814f9e33e0f7a314a089d7140269ffd51fe44104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSbfy2AAoJEEWCsU4mNhiPrMMH/jd+AgVYUKd1vmP1BfaZum1s
X186JulwF659YHOx94dLs+NOjvjMfY6cPbHm+B0j20CnhWrZrXzcXvwTHnzOSuoc
1AAXg0KDbvyo+7PvTrsGQfHhT1FZSRzIUToofVmFlvEIO6/LiYMAYWCgIiX9nPvv
RlvdtavTST+cY19yZamo5X0XU5cgI2tbtVWKEHJQ2VcglCgwFg5K0kZ0O1NMKbcZ
KBagY3PVTiHnYP+LwSTW6EU9DNq0eLYG39mz4N6CqGkXZjGgh2YXZ6Sl2qRuO/5e
Rd9HcJXKqPKqMuRpQ2PA5U3U6QSyrUz7/fmi5dsOxnR6pdR53kjUVSvbOqBFHXw=
=I1/R
-----END PGP SIGNATURE-----

2023-06-07 15:07:58

- reply

📅 Original date posted:2013-10-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, Oct 26, 2013 at 12:25 AM, Gavin Andresen
<gavinandresen at gmail.com> wrote:
> I feel like there is a lot of "in the weeds" discussion here about
> theoretical, what-if-this-and-that-happens-in-the-future scenarios.
>
> I would just like to point out (again) that this is not intended to be The
> One True Solution For Transaction Fees And Transaction Prioritization. If
> you've got a better mechanism for estimating fees, fantastic! If it turns
> out estimates are often-enough wrong to be a problem and you've got a
> solution for that, fantastic!
This discussion seems to be a lot of hot air over a simple observation that
estimates are imperfect and always will be. I do not understand you vehement
opposition the notion that a backup is a good thing except in the context that
replacement to change fees is halfway to profit-seeking replacement by fee.
Peter Todd:
You did a fair bit of leg work for replace-by-fee. Seems to me that
replace-for-fee will help prep infrastructure to eventual replace-by-fee usage,
while avoiding some of the politics around zero-conf transactions.
Go dust off your code and make it happen. I want to see a mempool
implementation similar to what you did for me on replace-for-fee, and I
understand much of the code is written in any case. This time I also want to
see a increasetxfee RPC command, and erasewallettx RPC command to deal with
duplicates. (I know touching the wallet code is scary) Having all will enable
usage, and I can imagine getting pools to use this will be easy enough.
(eligius?)
Here is your 4BTC bounty. In the event I am not around Gregory Maxwell can also
adjudicate. If both you and him feel someone else deserves it, by all means
send them the funds
bitcoind decodescript
522102d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac3914104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae
{
"asm" : "2 02d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac391
04d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e7141783
04f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce4
3 OP_CHECKMULTISIG",
"reqSigs" : 2,
"type" : "multisig",
"addresses" : [
"1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe",
"1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv",
"1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB"
],
"p2sh" : "3BST1dPxvgMGL3d9GPCHvTyZNsJ7YKTVPo"
}
(I realized right after my Tor payment protocol bounty that I would need some
bit of uniqueness like a bounty-specific pubkey to disambiguate multiple such
bounties!)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSbg9wAAoJEEWCsU4mNhiPROQH/j+eWccx7oSVsr94cgGu7qza
kdnA7B6BAlnCPg3D+nqEFKDqzOyFppeHLadCCIYHHc5iVRfJuu9J1Gh9lgMCuyCW
qN7ZOBCARjiVOqrHPQR1pf18i0ko7dQWw2hZjy51XKuFxAsHwZpB/fzQCbVVzyB6
l5SECCou58bJ/x7B0L93K+yjXuMGnvi9jqiLAKkLWYDzVm7TeVWNVQr04B7sqi6A
mY+BfG61e7sqM2UJd69yGLeQdEfghYTmtA+EaaqYS0L11m7yFGZdUqD7UNy1FKO7
44M1JTh2ANnQRjSTJWOBXQNHMa/mxDCji1VFUtJhZKEuOZyWpGm7HMH1D3vcvcQ=
=4flN
-----END PGP SIGNATURE-----

2023-06-07 15:06:16

- reply

📅 Original date posted:2013-08-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, Aug 19, 2013 at 12:59 AM, Gavin Andresen
<gavinandresen at gmail.com> wrote:
> Peter said:
> "In any case given that SPV peers don't contribute back to the network
> they should obviously be heavily deprioritized and served only with
> whatever resources a node has spare."
>
> This seems very much like a "cut off your nose to spite your face" solution.
>
> SPV peers are INCREDIBLY IMPORTANT to the growth of Bitcoin; much more
> important than nodes that have the bandwidth and disk I/O capability of
> being a full node. Bitcoin will be just fine if there are never more than
> 10,000 big, beefy, full nodes forming the backbone of the network, but will
> be NOTHING if we don't support tens of millions of lightweight SPV devices.
>
> Ok, that's an exaggeration, Bitcoin would be just fine in an Electrum model
> where tens of millions of lightweight devices rely 100% on a full node to
> operate. But I would prefer the more decentralized, less-trust-required SPV
> model.
So tell us how is your "vision" of 10,000 big beefy full nodes with SPV peers
any different from the Electrum model? These days Electrum clients have block
headers and verify that transactions have merkle paths to the block headers.
The only difference I see is that SPV uses bloom filtering and Electrum can
query by transaction. But Mike wants to add querying by transaction to full
nodes anyway, and one of the purported advantages of this UTXO proof stuff is
that you can query servers for UTXO's by address, so I see no difference at
all. A patch to do bloom filtering on Electrum would be amusing to me.
Here you have Peter talking about clever ways to actually get decentralization
by having SPV peers donate back to the network with spare bandwidth, like
relaying blocks, not to mention his partial UTXO set ideas, and you completely
ignore that. But I guess that would raise ugly questions when people realize
they can't now contribute back to Bitcoin, because the blocksize is a gigabyte
of microtransactions... It may also raise ugly questions with regulators that
may find the idea of "full node == data chokepoint == regulatory chokepoint" an
attractive notion. Why are there not any competent people other than Peter who
really have the guts to bring up these proposals? I've little luck getting
proof-of-concepts built for money anyway. Maybe we just have a darth of smart
competent people in this space.
You do a good job of signaling your priorities Gavin. The payment protocol
includes no notion that you may want to pay anyone but a SSL certified
merchant. Yes I know the crypto can be upgraded, but it says volumes that you
pushed for that first, without even the slightest token effort to allow
individuals to participate in any way. Sad given you have made things *less*
secure because there is no safe way to get money *into* my wallet with the
payment protocol, but could have been.
Tell me, when my decentralization pull-req is voted on, which way are you
planning on voting?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSEYg/AAoJEEWCsU4mNhiPQBIH/A2cef0NDzu72CY0+N1HdPO+
fdixwncAg1ok6YdJj5WALjHbkhJ+QRVEZoRr6rHPxxxTywI+HiPN1oaopIrq3StP
bNpvouaWXLyw6xHMrMYefVOluHNZg3lu1akLdGuYA7rDHLwP/RhlF1FFzXSxKFsp
ANcw4WW7U5r5nfBHYc/a9xo8S6THI7Nv2NDW6WaRQO4X9sbSKSdwanoe75CLsRzE
E2cPNvwG4WA/MUgkl3Ao6dMsEPPa8dJK98LaS4BE/m9iFWQiV8t35/FQ0GAFQoJo
PQUs8aAWiI0caAxI0vddxKQ+YlwPw2m1QH6h19wUO7+KLKOtxMFmWoDu/OLdTRM=
=IfkA
-----END PGP SIGNATURE-----

2023-06-07 15:06:08

- reply

📅 Original date posted:2013-08-19
📝 Original message:My apologies, that was for Peter
On Mon, Aug 19, 2013 at 5:00 AM, John Dillon
<john.dillon892 at googlemail.com> wrote:
> -----BEGIN PGP MESSAGE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F
> G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm
> GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7
> eF6yjogj5iaDUP2m7xLmRyaQvT/0GdRYk+c2JOH0HGGQ2WWylPMiczJmKmV4jrDd
> 6asoesEk5kH0IWM2xiY2re+/WkRVeNUlVT7R4+uIzQm/iMzKpIWNiF5a87x3+E9+
> +KgJg1a4elKZ6UO4Bvov+Gw65u7q3eunVUYHUKfaLIUBDAO4Pc5vOCVNqAEIAJyT
> qFTqTbV9XE+REN/1KVmRLgidcRcxnSFFnkUVUozdMev8oGqoW3iAs8rVr5DuSO/a
> FW0UOdI9vBLC51+pdbBNoR9c1saheRbnTks67kLziQmuBFkly6cbLYUyh859pA3K
> yjRaRLa1Q6IX76NZTdEc3F7XnfmMBwEFS2t9vSAqhFptAXlhnmKov+g7iJ8oaAWQ
> 361OcXvxPk6wmWKFroZIo1is0a3izoAcLFB9NWv7BU9I06XB3Gw5gVnzXQexTlV+
> KHd8zeJYfc1IaPLdxefhp8tfrJIjAOXq9FmKjgB5Qki8cgCWM1pJIJK0t4XTVxI6
> 8LU1aldq5Qlond0aIBfS6QFErTFtVYmFLjl8YETcphBZAOSb6Rgudrz9mAL1brOu
> fjg9aVTSTjWjFHflRFSpNKVjj+5zS93NMEEaNQmWjeexScw175DVKJoU6lnVFgfk
> I7d+Lf5axVwlawZ+euN9YURE1azWUR4OECfDvd6Na8MGs+OwedbWP5/OfDGg2rzN
> OG/SK5AxlrshrOmrY7emlMOhYIhd8A+KQ0ghLocTv8JVDvaIEnWkWEq4idhzOv4m
> 9xFmde45SOxy/PuReDEgGAS3S1IOMMzdkEH8yuzYf2cFzQ0d4PmHNn6NGDo9bEIV
> Bjw9pqg5rg+8un14T3+c9ZbfkEvLB+sEQ9uVidg9jE1ZSH/l9XG0stbSnnDmAkYy
> DbbA7WDsJ0fxQD1zvnDUlq84I2Fr5RwecOWuCUUUHGXdfe0AnxGL1k96Jd0t3BXj
> JbY5fBUbN1QTuwqUSUBhE8uE7gGVZyWHel+DtKxwpIkpQ/CPLxFWJQL8oswN4Re+
> CgS1Fs/P2MJdb0ht8cTTdFUEIKYW41eG84Vgpyn7gwd/IE1gPdpsDtoAV8uwIXsJ
> WBHtYgO/cH3ofyITOcsm7gfkI3V4T87I3Sjrnk0ipa6fWh8dwhZnG1s5b7lKVgAp
> QOqgWdjoP+4/FWCCpo9EVWqRfRU7js/TfuKOBiLDpKEkdmmuCOiMlxe5vt5FUHbq
> wT0V5Iian5GcqZvJ/CZWzAxMY+qXu/OziI9Emvz5AA/yWymcHJl2M8RY+L+fVB67
> /JSsHl0xQLHehKIFZKuTacy87pRHCoq7vA72lm+XCqC7+RojzPwODia7ShCfrZe2
> YctdU/VWVMMgkpLcGxRMRFc2Rxbbge3kEQCt+b7lL7HVq0vsBoF4g3X4kzLxxyeD
> JiR8PHknlWOjy5KgseKzTCt3sygvyJZrEPQ5SiBtoAkLgmEzkOxiy1DHrj59soM9
> QY7L3XTLLOya4daL5+iZjZXm28JNXAYycAu3fyXx7rnbL6m/gcGjJZiuwwajMvmF
> WvjbJBm9f5qOxK87ShnPj2ZwQ1w1nnz7i5oOdtELwUb96uMFegNDRSfMNpN4pmTh
> 2Qpffp9QZMEOxE+a7SnNjq5xG4S3qTnhdhTzQL5sIC+yJZ7L2gdbbrjdud2gcKRc
> yQIkst51OIV6/xJ65AD6qzIcifpLm+u5/t6eVGLvw0G8u3gFHgelM1kPfX8iYDOR
> CTDnJxx30/GXEvqD4/nCm5JytgolzH/PilBME1w2dPf845HebA0XCAhSoqdoLCvF
> 7jrllVCh/PDlK40XbO/cDYgXF7deDbgXVF2OBGc6qqAho3VE83ebR1wQWlUOyPIo
> ScQyePNu500Yy/GUnwBK7029N4r6R1RBDn/rTsD/2w==
> =6OvE
> -----END PGP MESSAGE-----

2023-06-07 15:06:07

- reply

📅 Original date posted:2013-08-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>> Doing this also makes it more difficult to sybil the network - for
>> instance right now you can create "SPV honeypots" that allow incoming
>> connections only from SPV nodes, thus attracting a disproportionate % of
>> the total SPV population given a relatively small number of nodes. You
>> can then use that to harm SPV nodes by, for instance, making a % of
>> transactions be dropped deterministicly, either by the bloom matching
>> code, or when sent. Users unlucky enough to be surrounded by sybil nodes
>> will have their transactions mysteriously fail to arrive in their
>> wallets, or have their transactions mysteriously never confirm. Given
>> how few full nodes there are, it probably won't take very many honeypots
>> to pull off this attack, especially if you combine it with a
>> simultaneous max connections or bloom io attack to degrade the capacity
>> of honest nodes.
>
> Oh, here's an even better way to do the "tx drop" attack: when you drop
> a transaction, make a fake one that pays the same scriptPubKeys with the
> same amount, and send it to the SPV peer instead. They'll see the
> transaction go through and show up in their wallet, but it'll look like
> it got stuck and never confirmed. They'll soon wind up with a wallet
> full of useless transactions, effectively locking them out of their
> money.
Excellent, and makes a mockery of zero-confirmation transactions to boot.
Can be prevented by passing along txin proofs, but they require the full
transaction, so the effective UTXO set size would go up greatly post-pruning. I
am sure Mike would love to demand that full nodes do this for their peers
though, at least until UTXO commitments are greated, at great cost to full
nodes.
On the other hand, a tx with some txin proofs can be safely relayed by SPV
nodes, an interesting concept. Do the UTXO commitment people have keeping proof
size small in mind?
> Here's another question for you Mike: So does bitcoinj have any
> protections against peers flooding you with useless garbage? It'd be
> easy to rack up a user's data bill for instance by just creating junk
> unconfirmed transactions matching the bloom filter.
That is good too.
I'll bounty 2.5BTC to implement the first attack, and 0.5BTC for the second.
Should be easy to do as a patch to satoshi bitcoin I think. The implementation
must include a RFC3514 compliant service bit to let peers know of the operators
intentions. Along those lines I'll donate 3BTC to adding service bit selection
to DNS seeds.
We should clearly show people the limitations of SPV before they depend too
much on it. Nothing wakes users up like a 21 million BTC transaction in their
wallet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSEYvxAAoJEEWCsU4mNhiPxI8IAJaWJ9s0YG3Ex5h8Dr6oPJ9M
uXTXa/Rt0DqS6mmyD9O80sXfgPbPbQa2rDL6imlqONaWfpXFZl2W9vxRGaZJ9wrr
3KBHzK8lasDOKqlEX92h8ZmQBjw4w5bK/heRLo1PnSZ8ojKn8+My1JvZWOPzF0Ct
tDXXuCE94csKuGRdmdDdVoXqy4XZaMQhHrGbrWVotQs1HzX3iK146GoGaZC0YyBx
cdWg/xDPtAxgb5zf2RSeNHfXeY0wZawe8vBxaS56gCRl54PG7fJvqL+YPcarNb1p
zEmahJjoyQHskjFeDpgEiXnWu3K3JGTSA5GvekWvBbJCcV4o1E6EI6LG0f1SfIs=
=12DC
-----END PGP SIGNATURE-----

2023-06-07 15:06:07

- reply

📅 Original date posted:2013-08-19
📝 Original message:-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)
hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F
G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm
GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7
eF6yjogj5iaDUP2m7xLmRyaQvT/0GdRYk+c2JOH0HGGQ2WWylPMiczJmKmV4jrDd
6asoesEk5kH0IWM2xiY2re+/WkRVeNUlVT7R4+uIzQm/iMzKpIWNiF5a87x3+E9+
+KgJg1a4elKZ6UO4Bvov+Gw65u7q3eunVUYHUKfaLIUBDAO4Pc5vOCVNqAEIAJyT
qFTqTbV9XE+REN/1KVmRLgidcRcxnSFFnkUVUozdMev8oGqoW3iAs8rVr5DuSO/a
FW0UOdI9vBLC51+pdbBNoR9c1saheRbnTks67kLziQmuBFkly6cbLYUyh859pA3K
yjRaRLa1Q6IX76NZTdEc3F7XnfmMBwEFS2t9vSAqhFptAXlhnmKov+g7iJ8oaAWQ
361OcXvxPk6wmWKFroZIo1is0a3izoAcLFB9NWv7BU9I06XB3Gw5gVnzXQexTlV+
KHd8zeJYfc1IaPLdxefhp8tfrJIjAOXq9FmKjgB5Qki8cgCWM1pJIJK0t4XTVxI6
8LU1aldq5Qlond0aIBfS6QFErTFtVYmFLjl8YETcphBZAOSb6Rgudrz9mAL1brOu
fjg9aVTSTjWjFHflRFSpNKVjj+5zS93NMEEaNQmWjeexScw175DVKJoU6lnVFgfk
I7d+Lf5axVwlawZ+euN9YURE1azWUR4OECfDvd6Na8MGs+OwedbWP5/OfDGg2rzN
OG/SK5AxlrshrOmrY7emlMOhYIhd8A+KQ0ghLocTv8JVDvaIEnWkWEq4idhzOv4m
9xFmde45SOxy/PuReDEgGAS3S1IOMMzdkEH8yuzYf2cFzQ0d4PmHNn6NGDo9bEIV
Bjw9pqg5rg+8un14T3+c9ZbfkEvLB+sEQ9uVidg9jE1ZSH/l9XG0stbSnnDmAkYy
DbbA7WDsJ0fxQD1zvnDUlq84I2Fr5RwecOWuCUUUHGXdfe0AnxGL1k96Jd0t3BXj
JbY5fBUbN1QTuwqUSUBhE8uE7gGVZyWHel+DtKxwpIkpQ/CPLxFWJQL8oswN4Re+
CgS1Fs/P2MJdb0ht8cTTdFUEIKYW41eG84Vgpyn7gwd/IE1gPdpsDtoAV8uwIXsJ
WBHtYgO/cH3ofyITOcsm7gfkI3V4T87I3Sjrnk0ipa6fWh8dwhZnG1s5b7lKVgAp
QOqgWdjoP+4/FWCCpo9EVWqRfRU7js/TfuKOBiLDpKEkdmmuCOiMlxe5vt5FUHbq
wT0V5Iian5GcqZvJ/CZWzAxMY+qXu/OziI9Emvz5AA/yWymcHJl2M8RY+L+fVB67
/JSsHl0xQLHehKIFZKuTacy87pRHCoq7vA72lm+XCqC7+RojzPwODia7ShCfrZe2
YctdU/VWVMMgkpLcGxRMRFc2Rxbbge3kEQCt+b7lL7HVq0vsBoF4g3X4kzLxxyeD
JiR8PHknlWOjy5KgseKzTCt3sygvyJZrEPQ5SiBtoAkLgmEzkOxiy1DHrj59soM9
QY7L3XTLLOya4daL5+iZjZXm28JNXAYycAu3fyXx7rnbL6m/gcGjJZiuwwajMvmF
WvjbJBm9f5qOxK87ShnPj2ZwQ1w1nnz7i5oOdtELwUb96uMFegNDRSfMNpN4pmTh
2Qpffp9QZMEOxE+a7SnNjq5xG4S3qTnhdhTzQL5sIC+yJZ7L2gdbbrjdud2gcKRc
yQIkst51OIV6/xJ65AD6qzIcifpLm+u5/t6eVGLvw0G8u3gFHgelM1kPfX8iYDOR
CTDnJxx30/GXEvqD4/nCm5JytgolzH/PilBME1w2dPf845HebA0XCAhSoqdoLCvF
7jrllVCh/PDlK40XbO/cDYgXF7deDbgXVF2OBGc6qqAho3VE83ebR1wQWlUOyPIo
ScQyePNu500Yy/GUnwBK7029N4r6R1RBDn/rTsD/2w==
=6OvE
-----END PGP MESSAGE-----

2023-06-07 15:05:31

- reply

📅 Original date posted:2013-08-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, Aug 5, 2013 at 3:30 AM, Peter Vessenes <peter at coinlab.com> wrote:
> I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He
> told me recently NTRU, which is lattice based, is one of the few (only?)
> NIST-recommended QC-resistant algorithms.
>
> We talked over layering on NTRU to Bitcoin last year when I was out that
> way; I think such a thing could be done relatively easily from a crypto
> standpoint. Of course, there are many, many more questions beyond just the
> crypto.
Is NTRU still an option? My understanding is that NTRUsign, the algorithm to
produce signatures as opposed to encryption, was broken last year:
http://www.di.ens.fr/~ducas/NTRUSign_Cryptanalysis/DucasNguyen_Learning.pdf
Having said that my understanding is also that the break requires a few
thousand signatures, so perhaps for Bitcoin it would still be acceptable given
that we can, and should, never create more than one signature for any given key
anyway. You would be betting that improving the attack from a few thousand
signatures to one is not possible however.
In any case, worst comes to worst there are always lamport signatures. If they
are broken hash functions are broken and Bitcoin is fundementally broken
anyway, though it would be nice to have alternatives that are similar is pubkey
and signature size to ECC.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR/zffAAoJEEWCsU4mNhiPypEH/1AoIR5eWewNbGO9/AZNykwf
Rs3P1iOJYt4oR0oTOHwlsXKX1qU9QAvWQUjDH60XyChCqb+E+xMz4LZgV6H71A03
XcEUZ6r4TRtEdH5kWwtoaxz2oxIIfwfRHIisUCCX2VvXzlBDjcuZvPQXSB0KE8Sx
z8pBZuRKbLeU19COK4BZs1/83/DTsYrV0Ln3LYT3UT5oiJBzA9pmX0cVxQePx2rc
hoNaxR4wR/oCUCvv73xhbzvB91RrAEgrJsd1ve4qR14LxWeOnTHqWQ2/E5JechZz
is/ryBW1Yit5GmsQlfNtKhS3zAaiCjha5e03CaSSlT0LjuVabe2A43LfEb0n4Mw=
=c5f5
-----END PGP SIGNATURE-----

2023-06-07 15:05:16

- reply

📅 Original date posted:2013-07-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Peter Todd recently came up with two related, and IMO very good, uses for
non-standard transactions to implement both oracles and one-time-password
protection of wallet funds. While the wallet fund case could be implemented as
only a single standard type, at the cost of generality, the oracle case would
be most useful with more arbitrary rules. More generally it is also useful to
be able to have scriptPubKeys like the following:
n <pubkey>...<pubkey> m CHECKMULTISIG <master pubkey> CHECKSIG BOOLOR
and many other similar constructions.
What are your thoughts on creating a whitelist for specific opcodes that would
apply to scripts serialized using P2SH, retaining the existing standard
whitelist for scriptPubKeys? (I would still recommend dropping pay-to-pubkey
and pay-to-multisig due to their potential for dumping data in the UTXO set)
I'm thinking it should contain the following opcodes, picked for either being
already used, or having simple semantics:
0 to 75 byte pushdata
PUSHDATA1
1NEGATE
OP 1 to OP16 (numbers are allowed through pushdata anyway)
IF
NOTIF
ELSE
ENDIF
VERIFY
RETURN
TOALTSTACK
FROMALTSTACK (the alt-stack makes stack manipulation in complex ways possible)
DROP
DUP
SWAP
EQUAL
EQUALVERIFY
0NOTEQUAL
BOOLAND
BOOLOR
RIPEMD160
SHA1
SHA256
HASH160
HASH256
CHECKSIG
CHECKSIGVERIFY
CHECKMULTISIG
CHECKMULTISIGVERIFY
Note how this list allows for complex logic, but does not allow for arithmetic,
thus not exposing us to a source of problems in the past.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR9XMQAAoJEEWCsU4mNhiPyXoIAMz2YZsq+/YUnq5G5AEVmJL/
D7qrLpuI++auMEDoXzt8CqmXbDqci/d70IsBYeHdZkxBp2dah99iDzwIoBhtO/xh
XR8m4P+FH+IF6xbuTUAQbBQxr9VuymUatUCmsFzP0YbtPwIzJvUAqJkVeYW1DUXj
6pc9EW3iYdhAvpKNU7A19F6FA96y9m9DyBvY3TCHwzf591Ld1S8ghb9dEuKKYMGl
8TuEMMU/bytZkdD590Ww+f6ukeSOMw9C9+IpAKotB2oq4F4Vkwyzw4rd8sNRAa6c
lEDov6UtDSp4ALMfUxw/nxMO8UB43iJhu31KihcjOZpiYvRVeQlM8XLEvAafZvA=
=Jph1
-----END PGP SIGNATURE-----

2023-06-07 15:05:16

- reply

📅 Original date posted:2013-07-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Jul 28, 2013 at 1:20 AM, Peter Todd <pete at petertodd.org> wrote:
> FWIW with some minor scripting language additions such as access to txin
> and txout contents, along with merklized abstract syntax tree (MAST)
> support, we can even implement a version where scriptPubKey's can be
> reused:
<snip>
> // Stack now only contains the nonce preceeded by a merkle path linking
> // that nonce to the tip of a merkle tree over all nonces.
> //
> // Verify that path.
> SWAP // Move direction flag to the top
> IF
> SWAP
> ENDIF
You missed a 'CAT' opcode here.
> HASH160
> (repeat above five lines 63 more times)
<snip>
> payment. If they opt for a paper-based one-time-password table they
> simply use the 6 word string as an index to their pre-printed OTP
> encyclopedia set.
I think you should disclose whether or not you have any ties to the pulp and
paper business... By my calculations the production of a single OTP table would
consume roughly half of all the forest biomass on this planet.
> Like the previously described version the security level is still a
> healthy 2^64 - again the attacker needs to find a 64-bit pre-image,
> considered to be a highly difficult task for any attacker unable to
> count from 0 to 2^64 or store a table containing 2^64 values.
>
> There is the disadvantage of the large storage requirements for both
> wallets, however because of the double hashed construction,
> H(H(nonce-secret+i)), neither table needs to be kept secret. Thus
> without loss of security both tables can be easily stored in a
> distributed hash table in the cloud and queried as needed.
ROTFL!
Your idea is better than you realize, you are just too paranoid for your own
good. The thing is the attacker isn't going to be someone paying you funds over
your minimum spending limit, which means the size of the table deriving which
H(nonce) is selected for a given txid:vout can be significantly smaller. For
instance if you want to have 256 total payments before a 50:50 chance of any
pair using the same nonce, you only need a table with ~2^16 elements or with 20
byte hashes just a megabyte of data. It is the 16 level merkle proofs that are
the problem, 16*21=336 bytes of data in the scriptSig. Then again, that's only
4.5x the size of a single signature, not unreasonable.
Also your nested IF statements, while a lovely and hilarious use of MAST, can
be replaced by simply creating the merkle tree over the tuples [i,H(nonce_i)]
and proving that the nonce_i you provided matched the precommitted tree. Now
you only need to provide one merkle proof, not two.
But don't let me discourage you, rarely do I see elaborate jokes that also meet
the criteria to be a least publishable unit. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR9WzMAAoJEEWCsU4mNhiP8wIIAJTESdZiIyrfmrJIQad19He0
nPUB1UGdrcRyYBKfk2bxmIgeTppEneISerAzFpfsZk/R1vLSp2zuFvFLMvaTqF0a
nof9dR4ztp753P6O9nLBIK1gcoOagg/FL61Cd1mQzoTjznGioEgk1mCo/Qjb8h9E
I43De70j575bvUkq8RQgijctIt463bM7vfdBC6qtgSziL/xrLUDQEJ6Mhqz3rnmX
+A2+MPHd/aGnRIcBuN6DFQTMXpjXG2y1CIM45e2gPL5x/vSIXqJoJs9tgGyzuFLG
rR34GCsifUKxJyvswG5ue9rNuo5mDkri2jIFx8SlqhfT/b8iWU8JIieoZYGuMiA=
=uhmy
-----END PGP SIGNATURE-----

2023-06-07 15:05:07

- reply

📅 Original date posted:2013-07-28
📝 Original message:My signature:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Linux distribution packaging and Bitcoin
========================================
2013-07-23
This note summarises the dangers inherent in the Linux distribution
packaging model for Bitcoin, and forms a request from upstream
maintainers to not distribute Bitcoin node software as part of
distribution package repositories without understanding the special
requirements of Bitcoin.
Distributors typically unbundle internal libraries and apply other
patches for a variety of generally good reasons, including ensuring
that security-critical fixes can be applied once, rather than multiple
times for many different packages. In most cases, the common
distribution packaging policy has many advantages.
However, Bitcoin nodes are an unusual category of software: they
implement a complex group consensus in which every client verifies the
behaviour of every other exactly. Even an exceptionally subtle change -
including apparently harmless bugfixes - can cause a failure to reach
consensus. A consensus failure of one client is a security risk to the
user of that client. A significant number of nodes failing to reach
consensus - as happened in March 2013 due to a change in database
libraries[1] - is a critical problem that threatens the functionality
and security of the system for all users.
For this reason, it is _vital_ that as much of the network as possible
uses _unmodified_ implementations that have been carefully audited and
tested, including dependencies. For instance, if the included copy
of LevelDB in bitcoind is replaced by a system-wide shared library,
_any_ change to that shared library requires auditing and testing,
a requirement generally not met by standard distributor packaging
practices.
Because distributed global consensus is a new area of computer science
research, the undersigned request that distributors refrain from
packaging Bitcoin node software (including bitcoind and Bitcoin-Qt)
and direct users to the upstream-provided binaries instead _until they
understand the unique testing procedures and other requirements to
achieve consensus_. Beyond being globally consistent, upstream binaries
are produced using a reproducible build system[2], ensuring that they
can be audited for backdoors.
1. https://en.bitcoin.it/wiki/BIP_0050
2. http://gitian.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR9WC5AAoJEEWCsU4mNhiPg6UH/2oHzBWBPaQMhH/GCTHQEi5U
7GSRfqwihIs/M2ROHLNq0HhgWR7mPAh5TTI6+tG95FCGCGNZq0seqw9wW4ZyGCoc
VueY51q4hcn23405oLD/QGK2lDxxywWY8XtFYVPqAzXTq6zRzgpNJkjoRtOAUOP7
3PrRkimYYyj0KrqFg+cEvZDT27dkeX+5PXM6Ua0o7h/TlhR2RJPhej5DI8cNLXgA
f0t+mES4Apb6zLgnEYYlPp22FR9vuFcJO3z1akhVL4DLUMqr58NYHLVnH1FH0Jhn
hVuld159QtCjQ5Qyn19cn86akTQJVi+ikCXqaKriCc2jBFX7TCI8WTDc6aSZpsQ=
=oX5d
-----END PGP SIGNATURE-----

2023-06-07 15:05:04

- reply

📅 Original date posted:2013-07-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, Jul 24, 2013 at 11:55 AM, Tier Nolan <tier.nolan at gmail.com> wrote:
> Distributing headers with 1/64 of the standard POW means that a header would
> be broadcast approximately once every 9 seconds (assuming a 10 minute block
> time). This was picked because sending 80 byte headers every 9 seconds
> shouldn't represent much load on the network.
As Peter said, "much" should be quantified.
Remember that there is a statistical distribution here, what is the probability
of how many seconds per headers?
> This creates an incentive for miners to take headers into account. If all
> the headers were worth less than a full block, then a fork which was losing
> would suddenly be winning if a block is found. A fork will only become the
> main chain due to a new block, if it is within 16 mini-confirms.
Sounds like you are changing economics and requiring miners to have even better
network connections. This is not a thing to do lightly and it probably a bad
idea.
> Second, if a header builds on a header that is in the header tree, then it
> is broadcast, even if it doesn't meet full POW (only 1/64 required). This
> gives information on which fork is getting the most power.
>
> It gives information about potential "consensus loss" forks, where a
> significant number of miners are following an alternative chain.
>
> In fact, this is probably worth doing as an initial step.
I understand Pieter Wuille is working on letting Bitcoin propagate and make use
of pure block headers, a step towards SPV and partial UTXO mode.
Orphan measurement would be very useful for a lot of reasons, how about you
think about that first? It wouldn't have the potential data rate issues either
and should be a very simple change. Just set some threshold relative to the
height of the best block where you will not further propagate and orphan
block(header) and prior to that limit do so freely. I believe the change would
be 100% compatible with the P2P protocol as it is based on inventories.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR9WXdAAoJEEWCsU4mNhiPBUYIALgg3ylA5mkciT3W/kb+qXCp
spYlPwAU/HVUrd/p6Ra6xAOOa224BE018FHRx7cJ31AQdVPsKhC1XiQCeYMv14Cj
5LstO2VTzxLovfs1lTVnekt+xVo6EHP47Qhmhdfo1AQWHS2njIp2lT9gAlNgMYoI
Twu0FLfJFwg14HlueLhTNvGo3TeVpGhTV3HYTbjWGBuPeroaaPCKKQOy/jmA9mnZ
1x4MjQZ+AkGA3+vrinyRZ1FQsp1pOUZMZx5UFYDOOPS3TysxttiHF/Vkdmy9dNVf
5zbXrEDImlariRnyxCf6sn4Fpu9H9bt6yttCez6NHqAoZCwciXyo+UrZjFawSVg=
=8gci
-----END PGP SIGNATURE-----

2023-06-07 15:04:34

- reply

📅 Original date posted:2013-07-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
It's been pointed out recently how a fairly cheap attack on the Bitcoin network
would be to take advantage of the fact that we limit the number of incoming
connections, but don't require anything of those connections. This means an
attacker can simply repeatedly query the the DNS seeds for new addresses and
make enough incoming connections that those nodes can not accept further
clients. nMaxConnections defaults to 125, and beyond that there is the limit on
file descriptors, as well as possible limits by stateful firewalls. (how much
memory/cpu does an incoming connection require?) The DNS seeds themselves crawl
the network on your behalf, and let you direct the attack starting at the nodes
new SPV clients are most likely to connect too.
The cost to the attacker is minimal, 1 INV message per transaction and block,
and some gossiped peer addresses. Currently that should be on the order of 30
bytes a second. The attacker can do even better by pretending to be an SPV
client, thus reducing their incoming bandwidth consumption to nearly nothing,
yet increasing resource usage on the node.
Peter estimated you would need just 200 or so well distributed IP addresses to
make it impossible to use an SPV client. In fact as far as I can tell for
incoming connections we don't force incoming connections to be well
distributed, so the attack could be done by simply one server with enough
amount of bandwidth. Estimates of the total number of nodes out there on
mainnet are in the tens of thousands, let's say 25,000 for arguments sake. 125
connections to every one of those nodes would only cost the attacker 94MB/s of
incoming bandwidth, easily attainable by a few cheap EC2 nodes, and on EC2
incoming bandwidth is free. The SPV version of the attack would let the
attacker spend as little as they wished.
Obviously if we want to make it possible for SPV nodes to reliably connect to
the network we need to give them a way to prove they have sacrificed some
limited resource to allow nodes to distinguish legit users from attackers.
Failing that, we need to make attacks sufficiently expensive to discourage
bored script-kiddies, much the same way flooding the network with transactions
is sufficiently expensive due to fees that such attacks are impractical.
Now something to keep in mind is whatever we ask SPV nodes to sacrifice must
not be reusable. For instance proof-of-stake *doesn't* work without consensus
because an attacker can reuse the proof for multiple connections. Similarly IP
addresses don't work, requring incoming connections to be "well distributed" in
IP space isn't a bad idea, but it doesn't buy much DoS resistance. Fees paid by
confirmed transactions do work, but only if something links the transaction to
the specific connection.
We also want whatever the nodes to sacrifice to be something not much more
costly to the client than to the attacker. Bandwidth isn't reusable, but an
attacker with EC2 or a botnet has vastly lower costs for bandwidth than a user
with an Android wallet on a phone.
For a non-SPV-mode client we can easily do anti-DoS by requiring the peer to do
"useful work". As the incoming connections slots get used up, simply kick off
the incoming peers who have relayed the least fee-paying transactions and valid
blocks, keeping the peers who have relayed the most. We can continue to use the
usual, randomized, logic for outgoing peers to attempt to preserve the
randomized structure of the bitcoin network. Without an ongoing attack nodes
making new connections are unaffected, and during an attack new connections are
made somewhat easier by the increased numbers of incoming slots made available
as the attackers connections timeout.
Yes an attacker can simply relay some high-fee transactions to keep their nodes
from being kicked off, but in that case are they really an attacker? I reject
the argument that we are letting them de-randomize the structure of the network
because as I've shown they can already do that with little expenditure.
For SPV nodes again in the absense of an attack such anti-DoS code has no
effect. When an attack is launched the SPV client can simply create some
high-fee transactions with their own coins to get connection priority. SPV
nodes already have serious privacy issues, so I don't see the creation of
transactions as a big deal. Re-use is an issue, but nodes can take into account
how long it takes for another nodes to advertise the transactions when dealing
with SPV peers. Better systems can be implemented later, such as micropayment
channels and coinbase probabalistic payments, that don't result in blockchain
transactions just for the sake of anti-DoS.
A demo of the attack against would be useful. Pieter Wuille's bitcoin-seeder
code could probably be re-used as it already has the required functionality of
making large numbers of connections. In fact, simply running multiple instances
of it could do the trick.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR4yHgAAoJEEWCsU4mNhiPRvkH/3fl5brCe+1cBUoFtAnVHV+0
dezNeXo+nAbDg8XCkF6cmFkDBSgTj8l2iy0N1pfCq1XDXmqfM5p+CtxIBuIwwURc
KnpwNnRwoQ0JKYFonmaM0rQgOcXnRvyNq2DVL/b/fA6X3I5nignWNFDtzpvFhM+J
IjhEVbu5S25c+O8LFlJV0ujjBgnR/8gJ0xV2fvdsaisAVHly1n9QWa1FEnMz7hp9
wfXPBh8tnehKnsspyeAEq5Yc/Yyow97CdwOqPVknI0rhes0OWR8ORcJ2NkBZm/Pn
rUFFMwAme/K1f3PqW1+EpM4gG/pJvg+xU5E5KdqgnjsQLoEGWtMcxEdAeCoBuNI=
=jzfg
-----END PGP SIGNATURE-----

2023-06-07 15:04:33

- reply

📅 Original date posted:2013-07-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Jul 14, 2013 at 7:28 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Sun, Jul 14, 2013 at 07:05:26PM +0000, John Dillon wrote:
>> Long-term we should be using P2SH with an inner OP_CHECKSIG for most addresses
>> as it's a 1 byte savings. Change addresses can have this done first, although
>> bitcoinj support will help so that satoshidice and similar sites can pay to
>> P2SH change. As for multisig's P2SH overhead for a 1-of-2 and 2-of-2 and
>> 3-of-3, is 10%, 8.6% and 6.2% respectively, all pretty minor, especially if you
>> assume the blocksize limit will be raised.
>
> Small comment: the current implementation in the reference client uses a custom
> script encoder for the UTXO database, which stores every (valid) send-to-pubkey
> as 33 bytes and every send-to-pubkeyhash or send-to-scripthash as 21 bytes.
> So for "standard" address payment, there is no storage impact of using P2SH
> instead.
By "impact" I am referring to the impact on transaction size and thus
blockchain space and fees, not UTXO size as stored by nodes themselves.
Specifically take the size of the txout and txin and compare the version using
P2SH to the equivalent version not using it to get my numbers.
Anyway, given how much uncompressed keys are still used obviously fee pressure
isn't even close to getting people to create efficient transactions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR4v6QAAoJEEWCsU4mNhiP/ToH/1zwzkG0v8OphBaglzhF/dha
QgRXy3CGQqs43w1hEsfPNaZUyKIZz2gmGtJV2PUh5FavhWY9IUuMCVLvPJ18KZkc
eCLtAWSlUkjemXz6S52RPXW3vmKTJzZK4ZBZP0JiRYfhBQWbUlArLh+mQw9RcWng
9fdS/Xw4QYFfnN46NMlHdHyqGn4Mu8VgsozeUlxWXBGorf2+IFbMxR1BRi33CluH
3r6AIRHXPSqgHf6qnHgWqKh/WXMxuG8lLyLa00Rj+ByNcNQCwLV/+9AzSJYNA5Ol
nnGdkbVDtLjmDS4KjwuSXGP8jh/uRrHLubcgk6UEm27K2/yJxARBfECo78aBLsg=
=Nx+9
-----END PGP SIGNATURE-----

2023-06-07 15:04:33

- reply

📅 Original date posted:2013-07-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
As you all know keeping the size of the UTXO set small is critical, and more
recently we've also had problems with distasteful data being added to the UTXO
set. (http://garzikrants.blogspot.se/2013_04_01_archive.html) Gregory Maxwell
has an excellent solution to the distasteful data problem in the form of P2SH^2
(http://comments.gmane.org/gmane.comp.bitcoin.devel/1996) and Peter Todd
pointed out how we can implement it with the existing P2SH form. We're also
going to be implementing some kind of OP_RETURN <data> soon which handles the
timestamping and similar use-cases, again without UTXO impact.
Right now the only scriptPubKey form with any significant use is the
checksighash. Bare pubkey gets used by the odd miner, and by Deepbit due to
their ancient codebase. The former isn't an issue as the miner mines the txout
themselves, and the latter shouldn't find updating to be a big deal.
OP_CHECKMULTISIG is used by Peter Todd's timestamper, but that can be changed
to OP_RETURN without difficulty. However all that will (hopefully!) soon change
as hardware wallets and the payment protocol make hardware wallets worthwhile,
and we should make sure these protocols take the extra step of using P2SH
before we get locked into a bunch OP_CHECKMULTISIG implementations.
We also have the problem that the IsStandard() code accepts up to 120 bytes of
junk data as a pubkey, allowing injection of 240 bytes of *spendable* data into
the UTXO set with bare OP_CHECKMULTISIG. This capability has to be stopped.
Thus I'm offering a reward of 1BTC for whomever creates a patch to change
IsStandard() to accept only P2SH and pubkeyhash in a raw scriptSig, allowing
other forms only when used with P2SH. I'm offering a further 1BTC to whomever
gets such a patch accepted into mainline. It's a pretty easy patch, so I'm
asking that all core-developers (that includes you Peter) hold off for one week
to give less experienced developers a crack at it. If for some reason you want
to remain anonymous that is ok by me as well provided you assign copyright to
me. I do expect unittests. Should be about half a day to a days work.
Long-term we should be using P2SH with an inner OP_CHECKSIG for most addresses
as it's a 1 byte savings. Change addresses can have this done first, although
bitcoinj support will help so that satoshidice and similar sites can pay to
P2SH change. As for multisig's P2SH overhead for a 1-of-2 and 2-of-2 and
3-of-3, is 10%, 8.6% and 6.2% respectively, all pretty minor, especially if you
assume the blocksize limit will be raised.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR4vX+AAoJEEWCsU4mNhiPg/EIAKWFaMsugbY4zZ+dpgnaTcUr
D1ZnY5PogETVqcwuXdVdHe2zCUcBhejsBe8ic9vp8OnttXTxo8uXJp9xBuq9VYBN
vXMyGKtxacLL5WS5ShAWnWS47xLf9wnKCJSGX0nqaETIQEUgqCMjTGspZNOpC9W0
fKBIDi4cZbpXn1EQx45v9vplZhFg+vBQV/Ia2/5rjZLPFvdqZoSBruOVTB/X2SDU
Hq36DQkRFblp/s3Ktv9c3yUQ8HocRIXD8jKRsE+uCNfEeI2b9oLpPp1cPsOvjveI
McJnHod8EDzxwbm6abK2cxHWBpGmBa5AABsRmQfpJK+u7GDQoPqzfJ68M1otZjk=
=uP4n
-----END PGP SIGNATURE-----

2023-06-07 15:04:19

- reply

📅 Original date posted:2013-07-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Jul 14, 2013 at 7:33 PM, Luke-Jr <luke at dashjr.org> wrote:
>> Merge mining is very much mining a coin for free. Ask not what the total
>> reward is, ask that the marginal cost of merge mining an additional coin
>> is.
>
> But the total reward is what mining will tend toward equalizing in costs.
> In any case, the cryptocurrencies are neutral to cost of mining, or perhaps
> even benefit from it being as cheap as possible: if it's cheaper to mine, you
> can get an even higher difficulty/security out of it.
Again, you forget that there may exist miners for which the value of the coin
is negative.
Never mind that in practice you want there to exist a cost to encourage miners
to actually pay attention to what they mind and to encourage them to update
software when required and participate.
>> The issue is that unless there is a cost to mining a *invalid* block
>> the merge mined coin has little protection from miners who mine invalid
>> blocks, either maliciously or through negligence. If the coin isn't worth
>> much, either because it's market value is low or the worth is negative to
>> the malicious miner, your theories of value have nothing to do with the
>> issue.
>
> Invalid blocks are rejected by validating clients in all circumstances.
Validating clients, not SPV clients.
> I suspect you may mean a block that doesn't include transactions you want
> confirmed. In that case, you must not be paying sufficient fees for the miner
> to consider it worth their time, or must be doing something the miner
> considers fundamentally objectionable (in which case they won't be satisfied
> by any fee). But these miners, unless they are able to acquire over 50% of the
> hashrate (in which case the cryptocoin is compromised), are not the only ones
> mining blocks, and if another miner accepts your transactions there is no
> issue.
All those things simply change the amount of alt-coin the miner gets, which to
the miner may have no reward. You also have the issue that we may be talking
about a non-currency chain where reward is more nebulous.
In any case, regarding a zerocoin chain, Peter's observation that
proof-of-sacrifice allows a strong 51% attck defense is very clever and IMO is
significantly stronger than proof-of-work mining, merged or not, would provide.
It's essentially the ability to conjur up mining capacity on demand, but only
by those who have a stake in the crypto-coin. It does depend on the existance
of a proof-of-work chain, but we have a perfectly good one handy.
PS: good to see you signing you email!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR4wCFAAoJEEWCsU4mNhiPIcwH+gLYbUPDi/7ITK02wftqEV2E
FSlzZ0W8aw7z7sF7hqPm7jpmtqbXdvQRSSy+XRDgWUxvF72o5oRTwOpY7xN8KOct
9rMwF35nld8An9FOjOB6NR3sIQxmAg9q7xoilZrOHyRFcz/UT0BexSZ3x5DrKIAB
6S7qalrGT0NWZx8CI0PRAzY8Nx+WouaoofBaypRaXBVJxigFqJlWNxgUM1FuoCL+
C1wn0hlbWfO42Mh9jdnFZXhH2Omd5V3PzIS/t2cJGTjrwr7nT6VAJu+0hbNZHI/q
yg0TGbO/01pp4OVe7WdLz9OktMqqDdDZJd6HWLQk07zqHS3iRJ2cpRIO6k9UCk0=
=oicX
-----END PGP SIGNATURE-----

2023-06-07 15:04:17

- reply

📅 Original date posted:2013-07-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Jul 14, 2013 at 7:42 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Sun, Jul 14, 2013 at 07:33:06PM +0000, Luke-Jr wrote:
>> Invalid blocks are rejected by validating clients in all circumstances.
>
> I don't think that's what John means.
>
> If you have hash power for the parent chain, mining invalid blocks for the
> merge-mined chain costs you nothing. Yes, they will be invalid, but you've
> lost nothing.
>
> The basic assumption underlying mining security is that it is more profitable
> to collaborate with mining a chain (and profit from the block payout) than to
> attack it. In the case of merged mining, this assumption is not valid.
You said it better than I did.
Essentially I am worried about the chain being strangled at birth, merge-mining
makes doing so cost nothing for the attacker. With zerocoin this is a
particularly dangerous possibility due to those in the Bitcoin community who
would like to see Bitcoin continue to have poor privacy properties.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR4wF9AAoJEEWCsU4mNhiPtCgH/3QLvFer3QHNU7AP+nehwcgK
QS3xLv60lvm+pYLVAp9xFyJ5SCHVGTPvWRBmoldk8xxh9ORHlNEsnrcx9ZONTJ4F
ja4Alp9MLZK5S8dKk2juJNdKziyRkQci/nNwuqepX5JjCIRNZq1lcW4Be4W7InPt
Ltrvp7lA03uNuAXxtlYnko4mEY5l1NiBp4BvhGZ6+GRdCltPeIk2m0NwLDHWd31t
qFLnnPSw0/9FGVs7lOaWuxbMGwPzGrIu6TXm17dqgBsl+8JuP6zHFE1ccqIxKyb6
Tdf4yNvhsvE+qlTnmcQNxM9nMHL4uqBZqJR174fAKQzcNGzVLloqbmRqKzuw5o4=
=leUJ
-----END PGP SIGNATURE-----

2023-06-07 15:04:16

- reply

📅 Original date posted:2013-07-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón <jtimon at monetize.io> wrote:
> All the arguments in favor of this pegging use zerocoin's point of
> view. Sure it would be much better for it, but are additional costs to
> the bitcoin network and you cannot do it with every chain.
Seems that Peter is describing a system that requires no changes at all to the
Bitcoin codebase and thus there are no costs whatsoever.
Peter: I'm a bit confused by this concept of "bi-directional sacrifice" though,
I assume there exists only a sacrifice in one direction right? Wouldn't selling
a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin tx
moving it to the new owner only happens if a specific form of bitcoin tx
happens too?
> Merged mining is not mining the coin for free. The total reward (ie
> btc + frc + nmc + dvc) should tend to equal the mining costs. But the
> value comes from demand, not costs. So if people demand it more it
> price will rise no matter how is mined. And if the price rises it will
> make sense to spend more on mining.
> "Bitcoins are worth because it costs to mine them" is a Marxian labor
> thory of value argument.
> It's the other way arround as Menger taught us.
Merge mining is very much mining a coin for free. Ask not what the total reward
is, ask that the marginal cost of merge mining an additional coin is. The issue
is that unless there is a cost to mining a *invalid* block the merge mined coin
has little protection from miners who mine invalid blocks, either maliciously
or through negligence. If the coin isn't worth much, either because it's market
value is low or the worth is negative to the malicious miner, your theories of
value have nothing to do with the issue.
Gregory Maxwell has written about this issue before on the #bitcoin-dev IRC
channel and on bitcointalk as well if memory serves. I advise you to look up
his description of the problem, almost everything he writes on the topic of
crypto-coin theory is spot-on correct.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR4vpGAAoJEEWCsU4mNhiPwu0IAMrzkVfI0CQuNJRCR+jwhNts
juEerApSSpBes6CjLBJJYZWDdMReSl6izqNDancnJygYc+Q5/IkwBispyZyeIVqY
HbV+jyAFQeVaJBZp8N+ZUDfN9/35SkPb4Y30dkq6V76hBfl+59bWq4qG0dhiO915
SBWAUPLspb5GOyu494GJUr4SPzgs9mAKfNGeQR2anOLj8Qam8Khfa4Zm5T5dX8WQ
vBunUCLykPvWBC3nuTDBU5gQu4TGW9ivGB4p6yLr7MyaPQYZEnYGqgU/yIfAhnBj
MfIfs6njPwhGMwteNmwLoS0VLRBFjWZDflquJ0NK6mNLR3c9yjOFMFPTTZFVinQ=
=b40P
-----END PGP SIGNATURE-----

2023-06-07 15:04:07

- reply

📅 Original date posted:2013-06-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Jun 28, 2013 at 10:20 AM, Mike Hearn <mike at plan99.net> wrote:
> I suspect what you saw is mining nodes restarting and clearing their
> mempools out rather than an explicit policy of replace by fee.
Possibly, but it is a rather short window of opportunity and the mining node
would have to be connected directly, to Peter's replace-by-fee node. I also
took care to ensure transactions were only ever broadcast once. (I disabled the
wallet rebroadcast mechanism)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRzWYWAAoJEEWCsU4mNhiP3fIIAJLFxMnjI4BGRrNLsxs0hXp0
zDCgiZ6UnZa5JRcd/6KjV3hnPHwweGEjChGfrzY/Fxo4Pga1lQFlp8E8PaFUJq50
r6LTNJQLW50r5mFkZ6Mkh877WwX/OHBzkp8SqbbD7+dDBV7R9LqLYqLTHgObKxg1
V9UjGRJiMohW8HLdOzEXOz1ugoBCjR+vyQW5ZD2nZVcQlIhxSIgeC/M46oxMN7pE
Y5EepCQehNPuc1On7TtJ9LlmFJ6Dvsl6dqwKNWMi1lgBTiw7abdTJne2B/KeDyom
vhGuhmpMLGKKgJns3hne3yQM+Ivi3jLIHKejcoCm1JkSCdjw48XkyGd0V359M3w=
=qyyq
-----END PGP SIGNATURE-----

2023-06-07 15:04:05

- reply

📅 Original date posted:2013-06-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn <mike at plan99.net> wrote:
>> I see some of the the other things that were concerning for me at the
>> time are still uncorrected though, e.g. no proxy support (so users
>> can't follow our recommended best practices of using it with Tor),
>
> Yeah. That's not the primary privacy issue with bitcoinj though. I'm
> much, much more concerned about leaks via the block chain than the
> network layer. Especially as Tor is basically a giant man in the
> middle, without any kind of authentication you can easily end up
> connected to a sybil network without any idea. I'd be surprised if Tor
> usage was very high amongst Bitcoin users.
Tor does not act as a particularly effective man in the middle for nodes
that support connections to hidden services because while your
connections to standard Bitcoin nodes go through your exit node, the
routing path for each hidden service peer is independent. Having said
that we should offer modes that send your self-generated transactions
out via Tor, while still maintaining non-Tor connections.
Anyway Sybil attacks aren't all that interesting if you are the one
sending the funds, and receivers are reasonably well protected simply
because generating false confirmations is extremely expensive and very
difficult to do quickly. After all, you always make the assumption that
nearly all hashing power in existence is honest when you talk about
replace-by-fee among other things, and that assumption naturally leads
to the conclusion that generating false confirmations with a sybil
attack would take more than long enough that the user would be
suspicious that something was wrong long before being defrauded.
I'd be surprised if anyone has ever bothered with a false confirmation
sybil attack. I wouldn't be the slightest bit surprised if the NSA is
recording all the Bitcoin traffic they can for future analysis to find
true transaction origins. Which reminds me, again, we need node-to-node
connections to be encrypted to at least protect against network-wide
passive sniffiing.
Regarding usage I would be interested to hear from those running Bitcoin
nodes advertising themselves as hidden services.
> It's not a library limitation anyway, it's a case of how best to
> present information to a user who is not familiar with how Bitcoin
> works. "Safe" and "Not safe" is still a rather misleading distinction
> given the general absence of double spends against mempool
> transactions, but it's still a lot more meaningful than "2 confirms"
For what it is worth I ran a double-spend generator a month or so ago
against the replace-by-fee node that Peter setup and I found that a
small number of the double-spends did in fact appear to be mined under
replace-by-fee rules.
Specifically the generator would create a transaction from confirmed
inputs, wait 60-180 seconds (randomized) to allow for full propagation,
and then create a double-spend if the transaction hadn't already been
mined. The transactions were randomized to look like normal traffic,
including occasional bets to Satoshidice and similar for fun. (for the
record the script had no way of knowing if a bet won and would happily
attempt to double-spend wins) Fees for the replacement were power-law
distributed IIRC, with some occasionally set to be quite hefty.
Though possibly just an artifact of unusually slow transaction
propagation it appeared that about 0.25% of hashing power was following
replace-by-fee rules. (not including transactions involving gambling, I
know Eligius and perhaps others block such transactions from their
mempools making double-spends easy to accomplish by including
Satoshidice outputs)
I'm actually surprised by that figure myself given Peter Todd and I
haven't made a serious attempt yet to get miners to use replace-by-fee
rules. An interesting experiment would be to advertise that money is
being given away by such a tx generator in the mining forum, although I
would prefer to see solid mempool support for the "scorched-earth"
double-spend countermeasure first; Peter sounds like he has some great
ideas there, although as usual I am seeing very little in the way of
code. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRzWCOAAoJEEWCsU4mNhiPwhgH/ic/OJMCYwdIuEM2ArSAEQRY
l5bqafMYMcC/KE9xqZ1HVkLJ9Zg57MQ8VZw95WOsmRgNA0v1xIoCyREjI84QkCIq
R/hOgS97eJc+XXnPBVoB4Jadq5LQ6jNpJo7cmiLJjCEmE6rTxLZBBT4P3eQw8oIn
WAd7X7utP7/QAkjhaWB9FsfWT8QZseqpSPv8WucRftsRCABurzuD+eSfpRqYwk2z
XBD0zO+EyAtu6hB3dRAFhqnhVfEcOLJCtXpm76WO574H4AZ/8EN+HozLJSUtylCq
j1NZnpj/6pdFh2v5Pid4HEMEvuNNX60u6iXGJ560PUsdKmOh+LEhUBLKd9acJTw=
=QtjI
-----END PGP SIGNATURE-----

2023-06-07 15:04:02

- reply

📅 Original date posted:2013-06-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, Jun 27, 2013 at 6:41 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke at dashjr.org> wrote:
>> On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
>>> * Very real possibility of an overall net reduction of full nodes on P2P
>>> network
>> Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or
>> MultiBit node. :/
>> Jim, will MultiBit be adding p2p listening support?
>
> Without validation listening isn't currently very useful. :( Maybe it
> could be somewhat more with some protocol additions.
Possible non-validation data that can be usefully propagated:
1) Block headers.
2) *Confirmed* transactions linked to an aformentioned blockheader.
3) Proof-of-work/sacrifice limited P2P messages, for instance to
co-ordinate trust-free-mixes or act as a communication channel for
micropayment channels.
4) With UTXO existance proof support propagate transactions
accompanied by proofs that all inputs exist. This would also allow for
implementation of Peter's low-bandwidth decentralized P2Pool proposal.
5) UTXO fraud proofs. (one day)
Strictly speaking #2 doesn't even need the protocol to be changed
actually as it can be handled entirely within the existing INV/getdata
mechanism. Sure someone could throw away a lot of hashing power and
get an invalid block propagated, but really so what? SPV nodes should
always take confirmations with a grain of salt anyway.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRzWx8AAoJEEWCsU4mNhiPlTkIAJKzFsT65o6LoU70hbaBsu3g
aBdjYZSCnJ9+qWI2tqqUBedq2etbt71hAfWNnTXvFus+0iVB1HWJClW155319vuH
Xi1m9G3O0NzX1d+cssMPxFBHsl4Rz6XYICrYyVEe2X554Zawdg6I53+1INHRfsBT
1vmq5Bxgopt0Tk9Vf8HNdRt/IXZJaPYm1PEzJHFppuOvl5+Fpypy3t/QXdsP8puP
LnRdL7Bxfu3BSWrSRZo7l5Fpww3Y/vdNYCL4jDD/ME+36wi4CUM3psL8lsk81lB4
3t/ytF4y/adT/dEEtMj7BGWS0TIMMH0NyeCjqBdStiQsVfoowLCVfpuDzouZ6yY=
=TI1m
-----END PGP SIGNATURE-----

2023-06-07 15:03:12

- reply

📅 Original date posted:2013-06-10
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, Jun 10, 2013 at 4:44 AM, Edmund Broadley <rebroad at gmail.com> wrote:
> I really like this idea. I also like that users with no clue will leave
> their vote to the default chosen by the software developers, which hopefully
> will be 1MB. I like how coin age is factored in do votes are hopefully
> proportional to bitcoin assert ownership.
The default should *not* be set by wallets at all in fact. The default is that
by not voting, you accept the status quo, which is defined as the mean of the
old and new limits in the past year.
So lets say the limit is 1MB, and through voting it ends up at 2MB in one year.
Until that time by not voting you are in effect voting for the limit to be 1MB,
but after the next interval you not voting is equivalent to voting for a 1.5MB
limit. A subtle issue is then txout age, and at that point a 1.5 year old txout
should be like voting for the 1MB limit still, albeit weighted less. What you
don't want is your lack of vote to suddenly turn into a 1.5MB vote. This makes
sure that at all levels the increases are gradual rather than abrupt, although
the rate of increase may still be quite fast if the community votes that way.
(first derivative of the limit is a close approximation to a continuous
function)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRtV0iAAoJEEWCsU4mNhiPRDIH+wapKxD0fc2div9gkhxZ4qVt
9Wh4u1vKM4RsxdPgh9uKFJomjErBXBROJ57cJqB1rwHt1xhUyHgbC8JstU0PWzUM
Ygwgibe9nsSjqHp2w15Bat+NmkYpxrjmVhf9woZkPQl+A1bWd3MFXOGoTIPPCl3I
KkMTaR3VbZDwqg0DlteZMR2im2DkT4zDsCkSb8KSCoaeTEdafkPceVHWU6isWxV9
Y0TGFCKaoMjxqxnkgH+vHsJlIM4E3rb0NHTo8rHD7Hm1txw/4/fVwE56/9U+8FaK
XAPXS0gkIR83V7cWMLa/q6LpZyzJmfFXCZhjT4YxVqeq/wB/SR9j2hhNdLnjuCo=
=y1c+
-----END PGP SIGNATURE-----

2023-06-07 15:03:12

- reply

📅 Original date posted:2013-06-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> Thinking about this a little more, I guess it does not hurt to build some
> kind of voting system into the clients. But I think it's more useful for
> straw polls. For example a bug fix 100% of people should agree on. A
> protocol optimization perhaps 80% would agree on. A protocol change that
> redistributes wealth or incentives perhaps only 60% will agree on.
>
> At this point in time it's far too easy to deliver contentious changes into
> the hands of the general population. I think that fortunately we're blessed
> with a very strong dev team, but the fundamental philosophy of bitcoin is to
> not put too much trust in single point, but rather, to distribute and
> diversify trust to the edges.
I disagree entirely. Your example of "straw polls" for bug fixes and
features is precisely what the current method of rough consensus and
running code, an IETF expression, handles just fine.
What the method does not handle effectively are issues that are
fundementally political rather than technical in nature. Blocksize is
precisely the latter because while the tradeoffs are technical in
nature the fundemental issue at hand is what do we want Bitcoin to be?
Who are we going to allow to participate?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRzWR7AAoJEEWCsU4mNhiPEYsIAME+VvS4vfE0PdOMv3vHWGSH
HwUJdtKPold4+p0jhPBKSMbgnpMvXsZezMIIxj8xehnblnVuUdyakibXAdgVNLvp
a6SCw+W/VnopYCw151zZ4FQS92KQuSbX+XmYTQy32oqZIXtBmTE1fydw5q6YhoXb
gCCygPRyLTIQxLZAxqqRrQ0nsSE5ID5kDcr+xRsmCvfIKrzoOCbYL+nXPCB4Zzgu
Gs7Lfa0yfTrUlQmoDseyoWrVuhfYuFNesTAs3z6imMTdHqZh8Z+a+gmC+G9qFO1h
y7hOmzW4oz7hH4R2F6M+UpV6rKdwMaNYwrDw5eHClDgGYNfjjVduQ/YMQnbjyAc=
=5mhd
-----END PGP SIGNATURE-----

2023-06-07 15:03:10

- reply

📅 Original date posted:2013-06-15
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, Jun 10, 2013 at 5:43 PM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jun 10, 2013 at 01:25:05PM -0400, Alan Reiner wrote:
>> to sign votes. Not only that, but it would require them to reveal their
>> public key, which while isn't technically so terrible, large amounts of
>> money intended to be kept in storage for 10+ years will prefer to avoid
>> any exposure at all, in the oft-chance that QCs come around a lot
>> earlier than we expected. Sure, the actual risk should be pretty much
>> non-existent, but some of the most paranoid folks are probably the same
>> ones who have a lot of funds and want 100.00% of the security that is
>> possible. They will see this as wildly inconvenient.
>
> Solving that problem is pretty easy actually: just add a voting only
> public key to your outputs. Specifically you would have an opcode called
> something like "OP_VOTE" and put a code-path in your script that only
> executes for that specific key.
Rather than "OP_VOTE" all you really need is the "spending tx matches a
template" functionality that has been proposed for many other things.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRvLIoAAoJEEWCsU4mNhiPdtoIAKOeEwtWXw6fNKbSN0miGmcQ
rHxgoEh5EAPsbs0hkCRpsVF7OjvmAftOn0Z0K0X/a4UFVHI64bvvGUg0brmAMnh3
ha4Mu/o7UwxwVJmmd6vpUw4smjbQrKbRzheXXQKUsDG2HOmRzMabFjJG1F20mPdg
RobwYG49fKLcjAfqqTjOwSQE5KBjrugAUo32OUJWHZyNR5E3JYUXRHseHCfQ+1Fd
VOQ8rWA4OaqwiX7PXdrNMWXc7Ab1dK7j9U7n4FgzCGIJjAek2dGbYLdrjftGKI+z
Vje7o/RCJFLkJW5cC/wDoB/58XyJuvsvGOBAjvz01UrengUiapkhLRjKQwbveEo=
=P0Hm
-----END PGP SIGNATURE-----

2023-06-07 15:03:05

- reply

📅 Original date posted:2013-06-10
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, Jun 10, 2013 at 8:14 AM, Melvin Carvalho
<melvincarvalho at gmail.com> wrote:
> -1
>
> Firstly I appreciate the ingenious thought that went into this post.
>
> However, Bitcoin's fundamental philosophy was one CPU one vote.
Indeed it was. Which is why as GPU's came onto the scene Satoshi was strongly
against them. I have to wonder what he thinks of ASICs where just a handful of
companies control the supply of Bitcoin hashing power.
Satoshi also never forsaw pools, which are why just 2 or 3 people control the
majority of Bitcoin hashing power.
> The asymmetry lies in psychological terms, in that new defaults tend to be
> adopted 80% of the time, so core devs have disproportionate amount of power
> as things stand.
That's why I'm very clear that doing nothing is a vote for the status quo. Of
course wallet authors can do what they want to try to get users to vote
according to their wishes, or for that matter simply steal your vote, but we
already must put a lot of faith into wallets to not steal our funds.
> Unless there's a very good reason not to, e.g. miners are clearly abusing
> the system, we should stick with 1 CPU one vote.
People are proposing we put control of the blocksize entirely into the hands of
miners, yet we all have an interest in auditing the blocks miners produce.
There must be balance.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRtY2jAAoJEEWCsU4mNhiPQEsH/0VNA7aJYdUbJjTnIiKoaCv3
JtWS1MKHjAJE6ZPDt+T/QPkEdZI4kNz3DGcZL6EDJtvZxZHfvEIaZDF1gpaH6OkC
oIZ0PkFPOxi0cncuAvT/a770evu7LzuT6fisY3EgGnlHujLQZ47LEa73Xo7pJVc7
RJHamGwkj+3HZRIuZIAn87qws/zRyTx5SXvb56xCKb0oxE4ZO0dn+8/nNSPWw13i
p3LpLlEQBBu+Du2nPSQupRjkz4MPP8v9EYefV5cjtNBK7ufAvA64OnwKB5dST+h+
N/vBcj3EIj/WEOf4myGcVxKp+skJ2SJDwxLigevgkKYPDNTVfXIverdXB0ANrQA=
=c8iU
-----END PGP SIGNATURE-----

2023-06-07 15:02:59

- reply

📅 Original date posted:2013-06-10
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
It has been suggested that we leave the decision of what the blocksize to be
entirely up to miners. However this leaves a parameter that affects every
Bitcoin participant in the control of a small minority. Of course we can not
force miners to increase the blocksize if they choose to decrease it, because
the contents of the blocks they make are their decision and their decision
only. However proposals to leave the maximum size unlimited to allow miners to
force us to accept arbitrarily large blocks even if the will of the majority of
Bitcoin participants is that they wish to remain able to validate the
blockchain.
What we need is a way to balance this asymetrical power relationship.
Proof-of-stake voting gives us a way of achieving that balance. Essentially for
a miner to prove that the majority will of the poeple is to accept a larger
blocksize they must prove that the majority has in fact voted for that
increase. The upper limit on the blocksize is then determined by the median of
all votes, where each txout in the UTXO set is one vote, weighted by txout
value. A txout without a corresponding vote is considered to be a vote for the
status quo. To allow the voting process to continue even if coins are "lost"
votes, including default votes, are weighted inversely according to their age
in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old will be
recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1 day old
and 6 months old UTXO are treated equivalently. The 1 year minimum is simply to
make voting required no more than once per year. (of course, a real
implementation should do all of these figures by block height, IE after 52,560
blocks instead of after 1 year)
A vote will consist of a txout with a scriptPubKey of the following form:
OP_RETURN magic vote_id txid vout vote scriptSig
Where scriptSig is a valid signature for a transaction with nLockTime
500,000,000-1 spending txid:vout to scriptPubKey:
OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL
vote_id is the ID of the specific vote being made, and magic is included to
allow UTXO proof implementations a as yet unspecified way of identifying votes
and including the weighted median as part of the UTXO tree sums. (it also
allows SPV clients to verify the vote if the UTXO set is a Patricia tree of
scriptPubKeys) vote is just the numerical vote itself. The vote must compute
the median, rather than the mean, so as to not allow someone to skew the vote
by simply setting their value extremely high. Someone who still remembers their
statistics classes should chime in on the right way to compute a median in a
merkle-sum-tree.
The slightly unusual construction of votes makes implementation by wallet
software as simple as possible within existing code-paths. Votes could still be
constructed even in wallets lacking specific voting capability provided the
wallet software does have the ability to set nLockTime.
Of course in the future the voting mechanism can be used for additional votes
with an additional vote_id. For instance the Bitcoin community could vote to
increase the inflation subsidy, another example of a situation where the wishes
of miners may conflict with the wishes of the broader community.
Users may of course actually create these specially encoded txouts themselves
and get them into the blockchain. However doing so is not needed as a given
vote is only required to actually be in the chain by a miner wishing to
increase the blocksize. Thus we should extend the P2P protocol with a mechanism
by which votes can be broadcast independently of transactions. To prevent DoS
attacks only votes with known vote_id's will be accepted, and only for
txid:vout's already in the blockchain, and a record of txouts for whom votes
have already broadcast will be kept. (this record need not be authoritative as
its purpose is only to prevent DoS attacks) Miners wishing to increase the
blocksize can record these votes and include them in the blocks they mine as
required. To reduce the cost of including votes in blocks 5% of every block
should be assigned to voting only. (this can be implemented by a soft-fork)
For any given block actual limit in effect is then the rolling median of the
blocks in the last year. At the beginning of every year the value considered to
be the status quo resets to the mean of the limit at the beginning and end of
the interval. (again, by "year" we really mean 52,560 blocks) The rolling
median and periodic reset process ensures that the limit changes gradually and
is not influenced by temporary events such as hacks to large exchanges or
malicious wallet software. The rolling median also ensures that for a miner
the act of including a vote is never wasted due to the txout later being spent.
Implementing the voting system can happen prior to an actual hard-fork allowing
for an increase and can be an important part of determining if the hard-fork is
required at all.
Coercion and vote buying is of course possible in this system. A miner could
say that they will only accept transactions accompanied by a vote for a given
limit. However in a decentralized system completely preventing vote buying is
of course impossble, and the design of Bitcoin itself has a fundemental
assumption that a majority of miners will behave in a specific kind of "honest"
way.
A voting process ensures that any increase to the blocksize genuinely
represents the desires of the Bitcoin community, and the process described
above ensures that any changes happen at a rate that gives all participants
time to react. The process also gives a mechanism for the community to vote to
decrease the limit if it turns out that the new one was in fact too high. (note
how the way the status quo is set ensures the default action is for the limit
to gradually decrease even if everyone stops voting)
As many of you know I have been quite vocal that the 1MB limit should stay. But
I would be happy to support the outcome of a vote done properly, whatever that
outcome may be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRtVFBAAoJEEWCsU4mNhiP6EAIAMjq4UgXxmEjOgHWf0KcmwmH
Ra/I3oY7krvg/lu1YCa+ACMBdoca9WODySUIe7R3niphKXEnknHGUIf8tm/Vrq4H
gPF4cgYEr18EYTVtvT9J1pZUB4f5dxkXXNpcQ60juaz9KervFQMOGnpr6Fyxi3dS
ghObNYcr3D2v1fjx56sp7BCNn0XHxTb1ZLUJB0BZhDKlamfgcxruKMbpsZmACJUj
gTNLNweaAomBIH++j7cnXeB0jZc/1ilv8qLA/f3TGb43FDkAQcvvSjGijI+OJOm6
Fh/WRBav1BJiV6PKs9xuHXsaxZ/T7Fb8Wg8EynSi0mSj47QXdKZgeZCi3XlSyxM=
=aKBD
-----END PGP SIGNATURE-----

2023-06-07 15:02:38

- reply

📅 Original date posted:2013-06-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> I'm one of the people experimenting in this area. I've long argued
> that a zero-output transaction should be permitted -- 100% miner fee
> -- as an elegant proof of sacrifice. Unfortunately that requires a
> hard fork. Also, for most people, it seems likely that a change
> transaction would be generated. That, then, would generate an
> already-standard transaction, where inputs > outputs.
100% miner fee is not a proof of anything because the miner could have created
that transaction for themselves. You must have proof that all miners had an
equal opportunity at collecting the fee, and the only way to do that is by
Peter's announce-commit protocol, or his unspendable until after n blocks
proposal.
Also the idea of a zero-output transaction is silly. In almost all cases you
are making the sarifice to link that act to an identity, and linking that act
to arbitrary data is far more flexible than any scheme relying on the pubkeys
that paid for the transaction. With a arbitrary data you can slice up the
sacrifice for instance with a merkle-sum-tree, as well as hide what the
sacrifice was for to preserve anonymity. The extra cost in size of the provably
unspendable OP_RETURN scriptPubKey is minimal for the rare time when it isn't
required.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRrf/BAAoJEEWCsU4mNhiP7+MH/RGfo2k+Zd0VoGzv3KSTzBrM
auK9Do2fYp2YvMnT/JFYbz2MgbTcCiKGyZfxjaH+zrqdTFgkgAE53midIv/Rd5/w
kjjifJuqw5AyIN6ANA1TuLQ64elPOXXymsaMqWO8ou0angG6DBI/LZZEG7SXM7+I
Jwk3MXLhFswvvuRif4G2C9v29WqSj4XRxxl3o63ziSYvZPPCHLYHAL9BJaMpDhaw
LxebM088RofzJAoGL1QIeQhDS3aAK4jKSZtJ/6+fwYZQB2Qc3sa1v9IAcCQHE+M3
6oQY0tzEEFg9+xdnSM7J6pW7qW28nFS8Fdr6UkUUlwhI5c4KnIKCtQa3o1mYDFE=
=SHWS
-----END PGP SIGNATURE-----

2023-06-07 15:01:48

- reply

📅 Original date posted:2013-05-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Peter's "Coinbase TxOut Hashcash" scheme mentions in passing anti-DoS
protection on the P2P flood-fill network for non-transaction messages, and an
application to use those messages, trust-free mixing. I did some review of the
source code and I think we can create a generalized P2P flood-fill message
system without difficulty.
First of all like Mike Hearn suggested in the tx-replacement (satoshi's
version) thread we can easily prioritize, or I should say deprioritize
non-essentially traffic with a simple "allocated bandwidth" scheme where nodes
set how many KB/second of bandwidth they want to give to P2P network messages.
Next out of that allocation use a priority scheme where higher priority
messages get put ahead of lower priority ones in the queue for retransmission.
Messages of too low a priority are dropped, and in general they basically just
don't get good network propagation, much like transactions with dust outputs
will increasingly face.
How do you determine priority? Why simply a genuine bitcoin sacrifice!
Previously that would have been some big bulky fidelity bond scheme, but now we
can use Peter's Coinbase TxOut Hashcash, or PowPos (proof-of-work
proof-of-sacrifice) as he mentioned in the forums. (and privately) I'll jump
the gun a bit and call it PowPos, it's a nice name as you say. :) We already
relay transactions based on 1mBTC/KB, so a similar per KB message cost is
reasonable.
Peter suggested using PayWords to amortize the cost of transmitting the PowPos
initial proof, which of course needs to be paid for. Storing original proofs
should be pretty cheap, so lets make the default to store them on disk, like
the UTXO set, with per-node settings for just how many of these proofs we are
willing to store. We can treat them kinda like accounts, and old enough
accounts simply get deleted, with a per-node configuration on how old is too
old. It's best effort, not permanent like the UTXO set. Nodes should be able to
ask their peers for the actual proof corresponding to a payment attempt if they
need it. (maybe a general delta compression system could do this and other
stuff?)
Nitty gritty: define either NODE_P2PMSG for "supports P2P messages" or a more
general NODE_SELECTIVE_RELAY to advertise general limitations on what a node
relays. (min txout value, replace-by-fee, p2p message etc?)
Define MSG_FLOOD_MSG inventory type. The logic is that flood-fill messages
*are* something you can have in your "inventory" of data, even though they are
still things that expire. Again nodes can set message expiration and prune them
in some sane way, a days worth of messages is probably fine for the vast
majority of nodes.
Each flood fill message needs a header with the sacrifice proof, either a full
PowPos, or a PayWord linked to a PowPos, followed by a type disambiguator
(64-bit uuid?) followed by the data payload. Limiting the payload to 100K by
default seems fine to me, same limit as on transactions.
The PowPos initial proof could also be it's own message type, MSG_POWPOS, and
again it's something you would have in your "inventory"
I haven't written up a formal trust-free-mix message proposal. Peter do you
have one? Seems to me negotiating transaction fees could be a bit tricky as you
want people to somehow at least say that yes they are willing to pay
transaction fees of X for the outputs they want, without revealing what those
inputs are. At the same time opportunistic mixing is cool, where you say "make
these coins available to be mixed if it doesn't cost me anything" and duplicate
other's txout values on the fly to make determining what is what as difficult
as possible, as well as occasionally broadcasting requests for random, or even
*common* txout values. (don't forget about zipfs law!)
Anti-anti-propagation DoS prevent is going to be hard too. You can rank nodes
based on the sum of genuine Bitcoin, or in this case genuine sacrifice activity
they are broadcasting to you. Tricky though because PayWord sacrifices aren't
stored anywhere, so a peer could reuse the same PowPos if they control all your
peers that are using the protocol.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRkKG0AAoJEEWCsU4mNhiP9nMH/1VB4ub5ftPfNK+2S0pcPaxd
wlc3KigF+5mDKN7t2gKr+DevS0gEJdOBzsCYbyartHbqeUSt7MLofKITbiIEWuTV
N1zaclwpP5VzkfiCoLj8sJ3If4s0Tkz71+y8WMAOfjJ/XqwqxHVnpLiLgLme1Wxb
FlSEzXRcnR66DisfvO+dDd0h5A2+OQEIoreTARK/w49caSHU+vAw9j6RHmUZ1Muw
zEy5VGs94kuehfn6nVyFSyZ3CdrEzstXFuv2eUs2bd3rUpGlgRjSUN1k6QnN5tdq
XUefI0bSVu1nWxBuS6k3wbTFulkLyWUY3Mt8aNR0/Ss19V8eAjWu87Fc8x4rH5c=
=KrwV
-----END PGP SIGNATURE-----

2023-06-07 15:01:47

- reply

📅 Original date posted:2013-05-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> - what about if a pool could lock the reward (rather than receive it or
> destroy it) eg some kind of merkle root instead of a public key hash in
> the reward recipient address field in the coinbase.
Sorry I don't have time for a full reply due to some other commitments, but you
remind me of an idea bouncing around to use a Merkle Sum tree as a way to split
one sacrifice among an arbitrarily large set of users. Credit goes to Gregory
Maxwell (according to the wiki) and the idea is to have the roots of the tree
be account "numbers" (pubkeys here) and account amounts. He proposed it for
off-chain transaction account ledgers, but the idea works equally well here to
split some initial sacrifice into lots of little bits. For instance a on-chain
sacrifice to an anyone-can-pay output could be split into enough parts to make
it useful even when tx fees become large.
Incidentally all this stuff about rivest paywords is probably silly, why not
just commit your sacrifice to a pubkey and make signatures saying what your new
balance is for each message and how much you intended to spend? This allows for
easy fraud proof creation, and gives you a choice of either lying to some
nodes, and getting poor propagation, or being honest and spending the amount
you should have.
For DoS protection it seems to me that mostly trusting nodes to give accurate
balances, enforced with a fraud proof system to halt double-spending, is
perfectly adequate. But no sense implementing so much complexity right at the
start of the effort! Just a thought for where things can go in the future.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRkaGUAAoJEEWCsU4mNhiPKsoH/1zhTBS/rINhF8oxxFoScD6i
0ybiUarIQEmmpAr3i46oMcSrw0SiOoiUzj6zvJorA21ddoErkTDVpMWI18RnKFos
bTC4NVzvcegLdnbYb+76XKOCMc1dchFXq+WEGRdu/WKzOL7ODUUKAl/hG2Fk4lPU
3x8mHq0k2pqMAYX5/TX0w0pDnS227L+V1O3EoZD86MjR/CliHsZyBnXIqyqV4rY8
354JswKQ/XWb85gwZwFq1WXsFIZAep+eRVqmOluu3Ol97c5G85utNYDkg2hALURy
gfpwmXKPFGm8h2lE1cMaOxkvQHOOPH8v7WdoBx08/ojhsyQNMpND4xej5FP/e5c=
=vrFC
-----END PGP SIGNATURE-----

2023-06-07 15:01:43

- reply

📅 Original date posted:2013-05-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, May 11, 2013 at 10:22 AM, Adam Back <adam at cypherspace.org> wrote:
> I didnt quite understand the writeup and the references were ambiguous.
No you didn't. :)
What is special about what Peter is proposing is that it is *not* merge-mining.
You see, merge-mining is essentially where you use one PoW for two purposes,
two different blockchains. So you are getting more value from just one unit of
work.
But Peter's coinbase hashcash protocol carefully ensures that the act of mining
the hashcash is guaranteed to cost the miner at least some well-defined amount,
and that amount can be easily calculated by considering the probability that a
block could have been found with the effort required to generate the proof of
work, and the amount of value the miner would have then given away in a
"anyone-can-spend" output. (you may not realize this, but a scriptPubKey with a
single pushdata opcode is always evaluated as true, which means it can be
respent by anyone)
Don't feel bad though, I had to ask him to explain it to me too. :)
> Rivest's PayWord for people who dont know the reference in this context is
> the observation that for a low value micro-payment, you dont mind if you
> only receive a payment 1 time in k so long as the expected payment is n
> after receiving n (eg satoshi sized) payments. Eg like a penny tip jar so
> long as your expected payment is correct long term (win as often as you
> lose) you dont mind. And a fair 100% payout lottery can be fun of itself.
I think you are misremembering. I just checked the paper and PayWord is based
on chains of hashes and you give the receiver a digest and if after n repeated
hashes it is considered to have been worth n*k It is not a probabalistic
scheme.
Incedentally while it is an obvious enough idea, though I didn't see a
reference to it, PayWords can be easily extended with a time-bandwidth
trade-off by using a structure similar to a merkle tree. The roots could be
created from some fixed nonce K and a increaing integer, H(K | n) Then you
would provide a merkle path to the previously agreed upon final digest. So
proof size for your payment would be log(n), and time to check the proof
log(n). Unfortunately setting up the scheme is still 2*n however that only
needs to be done once.
> So let say each email client sends in an email header the head of the
I have to respect a man who after all these years is still thinking
about anti-spam for email. :)
> Maybe one can put the bitcoin hash in DNS with a 5min TTL and have mail
> clients read that to reduce scope for stale mining.
Peter actually made a blockchain headers over DNS system, and a blockchain
headers over twitter system as an April fools joke. See
https://twitter.com/blockheaders
> In this way one can merge mine bitcoin & hashcash to the benefit of the
> recipient (or some beneficiary trusted not to be paying the proceeds to the
> spammer). And in a way that scales to email scale, and does not involve
> installing a bitcoin client in every client, nor mail server.
Blockchain header data may very well be one of the most widely distributed
single data sets in the history of mankind, and most of its closest cousins are
definitions such as the ASCII table or near definitions like the DNS root
servers. Not something with new data every 10 minutes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRkJZoAAoJEEWCsU4mNhiPtscIAL4eM+reWCfAjw0FAv5c5lwQ
tJvuVgmkCVyVurQLFbMt0hxXiYAFeTJ31uW0QBEdvitzIUAWR4QO/wfqNULAdZoA
RzTCOBTjfFFGQLd7UdRuDSSEvq23oeJCoixbtdGpAmM1ySRvCExkO+fYehNqXEDN
FF1PVv9VPc5KXbDw3mB6l8dkMCLEHmYpkdrNRvHHQMhyLXO8q3Q6H3zDy3YbztZC
rxibYprOtF1Z2dZzIYTWaGoA9ONLqSgOU2J1htj6kastsjW1d3XKIkdU/eRP2cEs
CG2EWyyrm59e4zpYL4BJj0zBMW9+pQQsSvrAtAoAFVdLojsAWBVL0PIQ8h8N6SY=
=+ptH
-----END PGP SIGNATURE-----

2023-06-07 15:01:35

- reply

📅 Original date posted:2013-05-09
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
After some consultation with affected sites by myself and Peter we have decided
to release an initial replace-by-fee implementation and setup a server using
those rules on testnet. This implementation does not include recursive fee
evaluation, and is therefore vulnerable to DoS attack, so hopefully that will
continue to allow adoption to proceed gradually. We can-not recommend mining on
mainnet with it. It does not include an "undo" RPC command or an adjust fees,
and Peter says he has not implemented one yet. Patches are welcome.
Specifically there were requests from vulnerable parties, which interestingly
included a site that knew they had bugs related to replacement but not
financial vulnerabilities, to put up a server on testnet to check wallet code.
The vulnerable requested to remain undisclosed. An additional consideration was
the upcoming anti-dust rules which are yet another example of why zero-conf is
so much more dangerous to accept than single-conf. Two of the people contacting
us brought up that issue in fact.
The code is on github:
https://github.com/petertodd/bitcoin/tree/replace-by-fee
and a replace-by-fee server operating on testnet is available at
testnet-replace-by-fee.bitcoin.petertodd.org To test you will need to use the
raw transaction API and manually create the replacement transaction. Do note
that your wallet will retain the existing one and no mechanism yet exists to
delete the old transaction from your wallet. Again, a certain amount of
"cludgyness" to this is intentional to discourage premature non-testing use.
Regarding the reward, I've decided Peter will collect the full amount even
though the work is not %100 complete (the mempool aspect) due to his concern
about staging an implementation properly, working with vulnerable sites, and
overall genuine interest in the actual issues at hand rather than the reward.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRi3LeAAoJEEWCsU4mNhiPwscH/2CI0d3h/3jix3iyz2I9I8Sz
6nbP8eA01l9kzG37cH1rFAbt7C+fL/nardV4U1qmiwC0MN7NPpX6BFn5eQ2PUKbu
41+AnjgWicB2tnCC07ngboQ1JCeZ+RTfATepuMxEdWFBsc8ZQXs0apWS01FT+TDq
J/a7QkhNfTaAQzXyqmLp0TQO7/Z7ysmCftOhtGbfvfhF2o23BuphQiRVA9IOoUuj
Fgb5wrfQqJ8TjvXRXAUQ7SUlzfN9BlPxMkTc6NhbcgIpuq1Kb43mLoDl3s2irH4A
GtjRtobV5Cfozm1r+8KPtIYEoQoj0PqTjO5YMwD/vTaRfNzdS4Tse5LQLGT6Jug=
=M1mj
-----END PGP SIGNATURE-----

2023-06-07 15:01:33

- reply

📅 Original date posted:2013-05-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, May 9, 2013 at 1:57 AM, Peter Todd <pete at petertodd.org> wrote:
> Remember that interpreting the timestamp on a block for the purposes of
> timestamping is a lot more subtle than it appears at first.
I actually just meant how Pieter Wuille was talking about a blocktime accurate
to only within 18 hours. :) But it is a nice writeup!
In any case, for many things simple relative ordering is enough rather than
absolute time.
> There are two types of timestamps possible: proofs that data existed
> before a time, and proofs that data existed after. With the former type
> the *later* the proof says the data existed, the more conservative the
> assumptions behind the proof. So simply adding two hours to the block's
> timestamp is relatively reasonable. (this assumes the attack managed to
> mine a single block, and all nodes have accurate clocks)
Nope. The attacker can make the timestamp on the block they mine as little as
the minimum from GetMedianTimePast(), and adding two hours to that number could
easily be well before true time.
What you probably need to do is some sort of median time calculation for the
blocks around your timestamp. The proof becomes probabalistic based on the % of
hashing power the attacker controls and in turn depends on if the time they
created their timestamp was of their own choosing.
IE, if you just want to create an inaccurate timestamp, but don't care when,
you can just mine blocks and wait until you get lucky. If you need to create an
inaccurate timestamp *now* the problem is much harder.
But all this analysis can be developed later, and data timestamped now. :)
> Back to the block header time... Frankly, the easiest thing to do is
> just have a flag day where blocks after a certain height are considered
> to have a different epoch from the standard 1970 one when computing
> their time. Boring, but it works fine and only needs to be updated every
> few decades.
Oh, right, yes, that is a much more simple idea and far less prone to bugs.
Many SPV clients wouldn't even need upgrades if they don't acturally validate
the blocks they receive and just look for the biggest PoW.
>
> You're midstate idea is very clever though and could come in handy in
> the future for different purposes. Eventually we should discuss this
> with the ASIC manufacturers - if it can be implemented as a firmware or
> FPGA upgrade in the field all the better.
Yes
Anyway, you are being distracted from what we were talking about before, get
back to work!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRiwrGAAoJEEWCsU4mNhiPvYAH/3kjlg5diWeyYUJlKPKRpygQ
XAU8a2D3h9bABacmmhx5yW3AmtV0QqLgKlB76t41JB4O6Jer5FT8tBBwPnjDijtI
KrBWwPqNhVZiyTSDZQTF6BR1a0DDCZVtOXlpOTj6NL1+hy7NYTYsqxAVzS8QgZUH
RXt7QTYGrrmMbmm75NdWhK59mbv22UEaDHfDW0qqgSzdb7f1EQv1fou3MfKScQSd
7OsGU3k5PM+KQ/FGBy+r+07GY5yj85YMooGky0MCjtkOiU/qr+pxfs1uT2R8/512
TyZxzn1vtgWUEGOUeMCml+bgjUOvOgcIvAarzZmyLyAAY15S/LT8MvAr2RUjAfY=
=UDyE
-----END PGP SIGNATURE-----

2023-06-07 15:01:32

- reply

📅 Original date posted:2013-05-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, May 9, 2013 at 1:13 AM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote:
>> Guffaw :) The year 2038 is so far in the future that it is not really
>> relevant, from that angle.
>
> "Meh". I think it's highly unlikely we'll break the block header format, as it
> pretty much means invalidating all mining hardware.
Doesn't most mining hardware at the ASCI level start with a SHA256 midstate
given that the nonce is at the end? Adding further information to the block
should be possible at the beginning of the block without major changes to the
mining hardware.
> There's also no need: 32 bits is plenty of precision. Hell, even 16 bits would
> do (assuming there's never more than a 65535s (about 18 hours) gap between two
> blocks). Just assume the "full" 64-bit time is the smallest one that makes
> sense, given its lower 32 bits.
I feel somewhat uncomfortable about the "after-the-fact" auditing possible in
this scenario. Besides the timestamping provided by the block headers appears
to be useful in some payment protocols, not to mention in general.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRivnmAAoJEEWCsU
4mNhiPUIYH/AlxK4DHvIdq0khNH0nfK65E
F1ZyYZTGLNHKqrJLCU2kc7zteGadQuccmFsYpmViIr14tzpU7xMImUHpj7fEHO3R
S/1zy59rx2+VYcevYdwMDTywanjeForRpli93Hz570GfwfG/D7VPejfLo6iq5dOt
EG5m3Z8F7wNzWBmfBYBHKLrNBJe6iw0qJ2nNiHXcELt6gaqG3C9wI9NAPtQWQKjB
57h7yTnFCRmjA3HDdCe2s0FVJgRP5cJqz3e62qZrY/BRmw/Vrx8ExuX1LJFqUx3k
5tg+BxXH4DJbNIojuq9lLl5lWxKOI1iSJJuCAixo/6s/manLFggJv7KtYgzhhjI=
=BxDb
-----END PGP SIGNATURE-----

2023-06-07 15:01:32

- reply

📅 Original date posted:2013-05-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, May 8, 2013 at 11:44 PM, Peter Todd <pete at petertodd.org> wrote:
> Who knows?
>
> Satoshi used 32-bits and those fields can't be changed now without every
> single Bitcoin user changing all at once. (a "hard-fork" change)
>
> We'll probably need to do one of those eventually for other reasons, so
> we might as well leave fixing the timestamps until then.
Perhaps Satoshi did this delibrately, knowing that at some point a hard-fork
would be a good idea, so that we all would have a good excuse to do one?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRivT1AAoJEEWCsU4mNhiPhxUH/271jtMvNrliZxFTvud282Dc
snEieMig1p/HXy6ry1YLp+Q2k4Ya3QFFPlbsqHeTjL+NaJSGOHPBen4lpWahOH+T
N6TQoOls7BMpQ7Y54Nqy5Qh9GeQnbDGcbQ8fBUfFqAF1Ljs0OBsbJtvC3vZTbYEn
dwB+7dvPLGKVfz/yrR9wrLhDzoXHbG4C3sefqNnm+fkHHIuTy4nxwtVVMydlzerF
Bwg1oc64dlul7sugBGXo2FjtGrxxkRxWWqj+dPgBnE/bDKIlemw34PtQZ2OK+IUS
CH7Q0EGBnr7TpXJT5AOMkycd8v9MJ2wNIt4v3YLqyViQ48Q5coxAS0GepcRnbMU=
=na4H
-----END PGP SIGNATURE-----

2023-06-07 15:01:22

- reply

📅 Original date posted:2013-05-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> > You mean scam you with a zero-conf transaction that hasn't actually been
> > broadcast?
>
> Yeah. Or just scam you at all. It's hard to imagine an organisation as
> a big as a mobile carrier engaging in financial scamming (roaming fees
> excepted).
Unless the government told them too.
> I've said this before, but I think it's worth repeating. The
> double-spend protection the block chain gives you has a sweet spot
> where it's really, really valuable (essential even) and then there are
> lots of kinds of transactions on either side of that sweet spot that
> don't really benefit from it.
>
> Obvious/trivial case where you don't need a block chain - Facebook
> buys Instagram for a gajillion coins. The legal system is plenty good
> enough to ensure the payments are honoured. Another example, when my
> employer pays me my salary. They aren't going to double spend this
> except through some horrible accident that we can get sorted out some
> other way.
The employer example actually shows something important: between a worker and
an employer double-spending already irrelevant. People get paid after they work
their two weeks not before, so the double-spend is already irrelevant.
However when your employer pays you on the blockchain until the transaction
confirms for someone else to accept funds from that payment they not only have
to trust you, but also the employer. Sure they could take it as "you said you
would apy me so it is your responsibility to make that happen" but that brings
a whole new level of complexity.
A scheme where you vouch for your payments with your identity can benifit from
being able to follow that chain all the way back to the last confirmed
transaction, although actually implementing this may be too complex to be
worthwhile, especially initially.
> Another case, very small payments. This is Satoshi's bag of crisps
> example. If the cost/complexity of double spending is higher than what
> the payment is worth, again, you don't really need the block chain.
> That's why it's worth optimising unconfirmed transactions to be harder
> to double spend, it optimises (pushes up) that lower bar.
Yes. But the issue is how are you going to optmize it? By adding yet more
restrictions and limitations on those who chose to run a node or mining
operation, or by actually fixing the trust issue? We know you can do the
latter, so do not sacrifice Bitcoin's core layer in silly attempts to make
double-spends harder. Fundementally Bitcoin has exactly one way of achieving
consensus, and that is the blockchain.
It must be your right to chose what transactins you chose to mine and chose to
relay. End of story. Bitcoin is not about imposing regulation on those who
choose to use it.
> Place where you really want the chain - largeish sums of money are
> moving around, but not large enough to justify expensive
> cross-jurisdictional legal action, or where the cost of identity
> verification and all the associated paperwork is just too high. I
> guess most online transactions fall into this bucket today.
Indeed. Especially for the most popular use of Bitcoin as a payment system:
buying things PayPal won't let you. In that circumstance the only leverage you
have is the protections of the blockchain and the damage you can do to the
other (often anonymous) parties reputation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRivRcAAoJEEWCsU4mNhiPoJcIAL7T/x5gipsCNn/w3EfhZhKo
iukP0Kc3cni/Kb6gJrOlXufIxDrX8QxEhbIIrypFbyg+xHPK8NzSd13ScKNtLgjM
w2uOI/IkgUh7VLIEZADqLO3TM5S5VDZ/A42yzTIq8MeWxaTBD1JulOc/RbljGu8V
UrF6ptxu2UXTc0eXcor1lHfJRVteTJAAba5Awa1EAHX8f2c/1FhdrnOZwfLVJIfK
/nnUgqGKc8l08knC6NnAlP39zbk/FHiZF/keWIFIzhiyXTnqKnqD096tIx6MpPci
LGafjCoXACpr1XeiSufER/z6WxTvOvCbWRw4MYrbyRkmChqMtc8a7RMEPLXhaMQ=
=Oh/p
-----END PGP SIGNATURE-----

2023-06-07 15:01:10

- reply

📅 Original date posted:2013-05-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sorry I should have used the word bootstrapping there rather than discovery.
But again I think that shows my point clearly. Centralized methods like DNS
should be used for as little as possible, just simple initial bootstrapping,
and focus the development efforts towards the non-centralized peer discovery
mechanisms.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBCAAGBQJRhlpyAAoJEEWCsU4mNhiP+NwH/3RY5vBpSYkwKgTmdKHRc/gw
BJCSV/1MEDECgBTxaRYSzYZyargjsdG50KaIaCq8M1+8DWkBEkH8JFif7UYMlZGM
WROMP6UjAnP1fJ3B2JChdMgRv1HdXJQDQVcO8UnSJschhX8lZZiUySbaqIPuRuV/
lI7/JkUZvmnms4+HGiaqwfbPO0k6ytJNKxORrk4TzFnThh4dy9WytElc8JHZOFaQ
ly159X5JuEwh8DLOoUtPhaR6tJaJbJLBEt+QJiGnSktPsJCE8p9+4HQ0kMCQr3Ha
05EHTZEw+TqEPaA7vFLgA/9tWjK9s1Y6sqLOAYiLp/0wSKzCkBO0C5LWFHsJ/XQ=
=aCgi
-----END PGP SIGNATURE-----

2023-06-07 15:01:10

- reply

📅 Original date posted:2013-05-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I think you too should ask yourself why you are putting so much effort into
optimizing a centralized service, the DNS seeds, rather than putting effort
into optimizing the P2P peer discovery instead. DNS seeds are a necessary evil,
one that shouldn't be promoted with additional features beyond simply obtaining
your initial set of peers.
After all Peter, just like you have implemented alternate block header
distribution over twitter, in the future we should have many different means of
peer discovery. Right now we have DNS seeds, a fixed list, and IRC discovery
that does not work because the servers it was pointed too no longer exist. Not
a good place to be.
Some random ideas:
search engines - search for "bitcoin seed address" or something and try IP's
found (twitter is similar)
ipv4 scanning - not exactly friendly, but the density of bitcoin nodes is
probably getting to the point where a brute force search is feasible
anycast peers - would work best with UDP probably, who has the resources to set
this up?
It is probably not worth the effort implementing the above immediately, but it
is worth the effort to ensure that we don't make the DNS seed system so complex
and sophisticated that we depend on it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBCAAGBQJRhU44AAoJEEWCsU4mNhiPtssH/1yb/FZRRaZpr3CwkoaOhbhu
pxfRNWgOEOL/mlWKTVgp2812qEnY9DySpJ5DJMjx7/GhSvOtnteza5ts4+pbuWhd
l6E1R9zAYxX+VOiBxcBtoZNEXDcS+CjMumuBH5S1v+L5jEntOWS9G8DKasjD2WAQ
DzX8YbOuzIOqasEbr5Hpr9Vfl7ZtW/+q/sPhQ1q3a7n7MaaIZrZicisJw3z7T7+0
T0yK8vUdYfstTjs0zLzfI5PW9+TG5T0kvj0kXSCjnK723Mfl7SXp6UZx6yebBi6q
tcTVOPo4hfBWk8XryZxaSNCkDYY6kryy5cb2V+BojVfqLWVKgR3pdZqXqnEKNLo=
=0XFF
-----END PGP SIGNATURE-----

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2013-04-23
📝 Original message:Sorry I don't have time to reply more in depth, but I wanted to say to
Jeremy (especially) and Peter I'm very impressed to see such a good
design be created so fast that does not depend on replacement at all.
This is a great example of how often the right approach to a problem
is to accept that the easy solution will not work, and find a way to
overcome the issue, rather than trying to paper over the easy
solution's problems with insecure design. I'm reminded of Peter's work
on fidelity bonded banking to overcome Bitcoin's scalability problem,
although that needs to become real, and soon, so we can find all the
flaws in it that will only become apparent when the idea is
implemented for real.
Jeremy: There does not seem to be a PGP key listed for your email
address. Is that correct?
On Sat, Apr 20, 2013 at 8:51 PM, Jeremy Spilman
<jeremy.spilman at gmail.com> wrote:
> I was discussing this with petertodd a couple days ago and we were thinking
> the sequence I sent yesterday was usable today. I tried getting it to work
> on test-net but the final transaction closing the channel was not being
> accepted into the mempool beacause "ERROR: CTxMemPool::accept() : inputs
> already spent"
>
> But I was talking with sipa and gmaxwell on IRC about it, and sipa reminded
> me; Test-Net implements IsStandard() to allow the non-final "refund" TX into
> the mempool, but then doesn't allow it to be replaced, Main-Net implements
> IsStandard() to *reject* non-final transactions in the first place.
>
> Therefore, this actually will work on Main-Net today, since the refund TX
> won't even be allowed into the mempool until it's final, the AP is free to
> sign and broadcast its final TX without any replacement. Of course, if the
> AP waits too long, the user can get their Refund into the mempool and the
> AP's [higher seq] version will be locked out.
>
> This may be a case where Test-Net is in a "bad" state, by allowing non-final
> TXs into the pool, but not allowing replacement, you get an intermediate
> state which neither matches Main-Net behavior, nor implements behavior which
> would ever be deployed to Main-Net as-is.
>
> The current Main-Net behavior is actually very well suited for this
> application. Any application that can be reduced to two instances of a Tx,
> namely one non-final, and one final which is updated internally between the
> parties, works very well under the current Main-Net rules.
>
> If you set the nLockTime of the refund to be several days after the
> scheduled closing time of the channel, it would be quite challenging to get
> the Refund TX into the blockchain *despite* a final broadcast TX from the
> AP. Since the vast majority of Main-Net won't even accept it, the attacker
> would have to distribute the TX to any miner who could include the AP's
> transaction in a block between now and when the refund becomes final, and
> convince them all to not include the perfectly valid, fees paid, final,
> nSeq=MAX, nLockTime=0 transaction from the AP. Demonstrating that level of
> coordination would act substantially against the best interests of the
> miners, to say the least.
>
> This proposal still suffers from any malleability weakness, where the user's
> refund could be invalidated by a miner changing the TxID of TX1.
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 11:47:11

- reply

📅 Original date posted:2013-04-19
📝 Original message:I understand that Gavin has spent effort on security efforts against
small-scale attackers. It's the fact that he is so dismissive of the
threat that large attackers play that is what bothers me. But if I am
being divisive I understand.
I posted a clarification of what the reward is for exactly on the
forums: https://bitcointalk.org/index.php?topic=179612.msg1881800#msg1881800
On Thu, Apr 18, 2013 at 8:14 AM, Peter Todd <pete at petertodd.org> wrote:
> On Thu, Apr 18, 2013 at 06:07:23AM +0000, John Dillon wrote:
>> Gavin do you actually agree with Mike on this stuff like he implies?
>> Because if you do, I think people should know. Myself I wouldn't want
>> to be contributing to your salary as a foundation member if you don't
>> take Bitcoin security seriously.
>
> FWIW Gavin has spent quite a bit of time and effort ensuring that
> Bitcoin is resistent to DoS attacks, as well as spearheading a move
> towards better testing. The latter in particular is helpful against
> chain-forking bugs, so better testing is very much a security issue. He
> also spearheaded P2SH, and the current efforts to get a payment protocol
> implemented. I'm less convinced about his stance against attackers that
> pose a threat to the system as a whole, but it's not fair to accuse him
> of not taking security seriously.
>
>> Strict replacement by fee should be written so it can be tested
>> properly and people in the Bitcoin ecosystem use proper security
>> practices with regard to unconfirmed transactions. I'm willing to
>> pledge $500USD to anyone who implements it. That is write the core
>> functionality that does replacement by fee, and a simple 'undo' RPC
>> command. I would do it myself but my programming is rusty.
>
> You should clarify if you want this patch to compute fees recursively or
> not, IE, should the patch include fees paid by child transactions in how
> it computes the total fee the transaction pays. Doing this is
> non-trivial, although Luke-Jr has written a patch to do this without
> replacement: https://github.com/bitcoin/bitcoin/pull/1647
>
> Also, clarify if you want unit-tests and similar things included in the
> implementation.
>
> --
> 'peter'[:-1]@petertodd.org

2023-06-07 11:47:04

- reply

📅 Original date posted:2013-04-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Apr 17, 2013 at 9:48 AM, Mike Hearn <mike at plan99.net> wrote:
> So it'd be nice if this ended up not being necessary. Experience indicates that rational miners typically don't pursue a short-termist profit-at-any-cost agenda - free transactions have always been included in blocks, miners include transactions even though you could avoid a lot of complexity by just not including any at all, etc. Some miners like BTC Guild have actually sacrificed significant amounts of money for the good of the system. You can see this in terms of rational self interest - miners earn Bitcoins thus it's in their interest for Bitcoins to be as useful as possible, as that is what gives them value. Or you can see it in terms of ideologically-driven altruism. Or both.
Please don't say Gavin agrees with you. This reminds me of discussing
security in the early days of the internet when the general assumption
that everyone played nice was still correct.
We're seeing huge, expensive, DoS attacks against mining pools,
exchanges, information sites, stores etc. Bitcoin has enemies. Peter
Todd is 100% correct, tx replacement is another form of zero
confirmation transaction and all that has to happen is some subset of
mining power start doing replace by tx fee for it to have no security
while with your proposed implementation opening up a DoS attack
vector.
You also see the DoS attack vector as unimportant and suggest to
handle it as a prioritization problem. "real world experience
indicates that people don't pointlessly mount attacks over and over
again if there's nothing to be gained by doing so." <- of course there
is something to be gained, shutting down a service dependent on tx
replacement, as seen by all the DoS attacks we are seeing. If I were
deciding if my service should use tx replacement and I understood that
it could be trivially shut down, I sure wouldn't be happy I could
"just warn users not to take advantage of the feature whilst the flood
is in progress"
Gavin do you actually agree with Mike on this stuff like he implies?
Because if you do, I think people should know. Myself I wouldn't want
to be contributing to your salary as a foundation member if you don't
take Bitcoin security seriously.
The rapidly-adjusted payments stuff on the Contracts page of the wiki
is broken in multiple ways:
1. (known) Requires DoS vulnerable infrastructure.
2. (known) TX mutability
3. (unknown?) Just doesn't work. Step 5 is to check that T2 is signed
correctly by the access point, and if so, sign T1 and T2. But the
signature of T2 includes the txid of T1 and that isn't known until T1
is fully signed.
That #3 has not been noticed before shows that for all this hot air
no-one has ever bothered making an implementation of the idea. So
Mike, why are you happy to make testnet vulnerable to an unusually
easy DoS attack for an idea you haven't even tried on your own private
testnet with replacement enabled?
Anyway, with Peter Todd's much saner tx-replacement-by-fee the
following can be done:
1. Create a new public key PK1
2. Request a public key PK2 from the access point.
2. Create TX1 with two inputs and two outputs. Both parties sign it
and broadcast it.
access point input -> 2 PK1 PK2 checkmultisig, value = input #1 - fee
you input -> 2 PK1 PK2 checkmultisig, value == input #2 - fee
3. Create TX2.
TX1 #1 -> pay to access point PK2
TX1 #2 -> pay to yourself PK1 (change)
Set TX2 nLockTime to some time in the future.
4. Set the initial value's of TX2 out #1 and out #2 to the value the
access point and you committed in TX1. Both parties sign with
SIGHASH_SINGLE. (which means both parties are signing for both inputs)
5. Update TX2 as required and sign both inputs. The access point
doesn't need to sign TX2 or give the updated copy of TX2 to the other
party. The TX is not broadcast when updated (like the earlier contract
proposal) although doing so harms no-one.
When the session ends with both parties online, do the following:
1. You sign a version of TX2 with the final output values and nLockTime=0
2. If the final output values are acceptable to the access point, they
sign the other half of the 2-of-2 inputs and broadcast. (with whatever
fees required)
If the buyer quits the session abruptly:
1. Access point signs the last (most funds) version of TX2 given to
them, waits until the nLockTime expires, and broadcasts. This also
gets their TX1 input back.
If the access point quits abruptly they can do the above when they go
back online. The buyer has the first, signed, version of TX2 and at
worst can broadcast it eventually to get their deposit back.
Attacks:
After TX1 is signed and broadcast both parties are in on the contract
together, so the funds can't move without the consent of the other.
Both parties can block the movement of the other's deposit, but they
lose their deposit too. With tx mutability there is a small window of
time for a technical mistake, but that should be very, very rare.
You can broadcast an earlier version of the transaction where you pay
less than you were supposed too. However if you do this, the access
point can broadcast a new version of the transaction, splicing
together your signature on the correct output value, with your
signature on an earlier version of the access point's output, thus
paying miners a higher fee than the transaction you broadcast.
Rational miners will chose the latter version rather than your one.
This bidding process can continue until you are out the full amount
you were supposed to pay, with the whole payment going to fees, so why
bother? With nLockTime you don't have a better chance of mining the
transaction than any other miner.
I apologize if the above has already been discussed. I only looked at
the wiki and source code and don't waste too much time reading the
endless bitcointalk forums. The wiki should be updated with these
ideas as they are developed by people and vetted.
Strict replacement by fee should be written so it can be tested
properly and people in the Bitcoin ecosystem use proper security
practices with regard to unconfirmed transactions. I'm willing to
pledge $500USD to anyone who implements it. That is write the core
functionality that does replacement by fee, and a simple 'undo' RPC
command. I would do it myself but my programming is rusty.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRb4vZAAoJEEWCsU4mNhiPRNoH/jGcGw2NBUcIh0/HT70nnwU+
deaXcdYp9RhDlSf0VGvPwwEAnjWBFc+pYVC+vtL4XEvWR+5PC7FcOrRrv/+sTDPs
YwPkCIwvXJizFe5pAhXOde4EdibXU0WXTLonMNUeZkwhxUfrczURm2tgmJlNE7nA
3PBun4c4r7EcdRHuh9SiK0C4RgB5w63t/qyFVUfqwhyKYiS55K/2t2mVLLxcPWkY
8nxlYlese5eZZJBTfiePtPOqTd43DHOkN+4Iu5XXQIH7v2QHf50DMqgI3iVLVe08
c2i9GutwX+2MevSMe/S57952BCjBq4zF0nBpaAfIFCVHDDZ6bDbgA7fUjDtLVds=
=1Tc0
-----END PGP SIGNATURE-----