<unnamed>

Public Key

npub15z6e9t07ugx267aj3s3c487pln852ydytzlgu0vkkqxfznyvx4jq4kn0zr

Profile Code

nprofile1qqs2pdvj4hlwyr9d0wegcgu2nlqlen69zxj9305w8kttqry3fjxr2eqprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvedtg9x

Publishing to

relay.snort.social

Last Notes

2023-06-07 15:09:23 UTC

- 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:06:07 UTC

- 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:04:02 UTC

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

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

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

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

- 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:43 UTC

- 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:32 UTC

- 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:32 UTC

- 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 14:56:19 UTC

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