<unnamed>

Public Key

npub1ddqaln8xsfmy6sxqplt9sz5ev99kh052sveqsh02q7hmc3a6n68shpgp9a

Profile Code

nprofile1qqsxkswlenngyajdgrqql4jcp2vkzjmth69gxvsgth4q0taug7afarcpzpmhxue69uhkummnw3ezuamfdejszwf9zq

Publishing to

nostr.wine

Last Notes

2023-06-07 17:59:46 UTC

- reply

📅 Original date posted:2017-04-08
📝 Original message:Yes, you only need a few bits in the version number, probably less than 8.
If you encourage the overt method of using AsicBoost I would argue that you
no longer need to dis-encourage the couvert method anymore as in Greg's
proposal. Nobody would use the couvert method anyway because the overt
method is so much simpler. So maybe the proposals can be completely
disentangled?
On Fri, Apr 7, 2017 at 5:05 PM, Jimmy Song via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I've gotten feedback from Adam Back that you actually don't need all 32
> bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
> the 32-bit version field, bits 16 to 23 are reserved for miners, the
> witness commitment stays as defined in BIP-141 except that it's now
> required. BIP9 then is modified so that bits 16 to 23 are now no longer
> usable.
>
> On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <jaejoon at gmail.com> wrote:
>
>> Hey everyone, This is an idea that I had about Segwit and Gregory's
>> proposal from yesterday that I wanted to run by everyone on this list. I'm
>> not at all sure what this would mean for non-upgraded nodes on the network
>> and would like feedback on that. This is not a formal BIP as it's a
>> modification to a previously submitted one, but I'm happy to formalize it
>> if it would help.
>> ----------------------------------------
>> MotivationOne of the interesting aspects of Gregory Maxwell’s proposal
>> is that it only precludes the covert version of ASICBoost. He
>> specifically left the overt version alone.
>>
>> Overt ASICBoost requires grinding on the version bits of the Block
>> header instead of the Merkle Root. This is likely more efficient than the
>> Merkle Root grinding (aka covert ASICBoost) and requires way less
>> resources (much less RAM, SHA256 calculations, no tx shuffling, etc).
>>
>> If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a
>> slight modification, this should, in theory, make ASICBoost a lot more
>> useful to miners and appeal to their financial interests.
>> The Modification
>>
>> Currently, the version bits (currently 4 bytes, or 32 bits) in the header
>> are used for BIP9 signaling. We change the version bits to a nonce-space so
>> the miners can use it for overt ASICBoost. The 32-bits are now moved
>> over to the Coinbase transaction as part of the witness commitment. The
>> witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes
>> being used as the version bits in the block header previously. The witness
>> commitment becomes required as per Gregory Maxwell’s proposal.
>> Reasoning
>>
>> First, this brings ASICBoost out into the open. Covert ASICBoost becomes
>> much more costly and overt ASICBoost is now encouraged.
>>
>> Second, we can make this change relatively quickly. Most of the Segwit
>> testing stays valid and this change can be deployed relatively quickly.
>>
>> Note on SPV clients
>>
>> Currently Segwit stores the witness commitment in the Coinbase tx, so
>> lightweight clients will need to get the Coinbase tx + Merkle proof to
>> validate segwit transactions anyway. Putting block version information in
>> the Coinbase tx will not impose an extra burden on upgraded light clients.
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/47873dc2/attachment-0001.html>

2023-06-07 17:53:47 UTC

- reply

📅 Original date posted:2016-10-02
📝 Original message:> When you proposed the extra nonce space BIP [1], you had already
> applied for your ASICBOOST patent [2] without disclosure in the BIP
> [1] nor in your Bitcoin Core pull request #5102 [2].
There may be quite a few things to clarify here, and a possible
misunderstanding:
The BIP proposal [1] and accompanying pull request [3] does not increase or
decrease the entanglement of Bitcoin consensus code with any patents. This
is indicated by the title of the pull request: "No forking Extra nonce
added to Bitcoin header." It is not a fork at all (soft or hard). The
consensus is not changed.
AsicBoost is possible with or without adoption of that BIP proposal. Of
several ways to implement AsicBoost (all described in the patent
application), making use of the version field is only one. And even that
particular one has always been possible since the beginning of Bitcoin and
is still possible today. It is not the case that the BIP proposal enables
AsicBoost in a way that wasn't possible before.
The rationale behind the BIP proposal was to eliminate incentives to mess
with the merkle root and, in the extreme case, to mine empty blocks. This
incentive is real, and it is real with or without AsicBoost. It costs
hardware manufacturers real $ in additional hardware components right now
to cope with the pre-hashing load.
Timo
On Sun, Oct 2, 2016 at 12:36 PM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Sergio,
>
> It is critically important to the future of Bitcoin that consensus
> code avoid any unnecessary entanglements with patents because "the
> free market" allows you and anyone else to make consensus change
> proposals that rely on (unknown) patents - but this is something we
> should all be working to avoid, as it unnecessarily hinders Bitcoin
> development and everyone's ability to deploy. Consensus code must not
> be hindered by patents and Bitcoin should retain its permissionless
> qualities.
>
> When you proposed the extra nonce space BIP [1], you had already
> applied for your ASICBOOST patent [2] without disclosure in the BIP
> [1] nor in your Bitcoin Core pull request #5102 [2].
>
> The ASICBOOST patent [2] describes the same process as in the BIP [1]
> and proposed code [3] "As we explained in our Provisional Application,
> it has been proposed to partition the 4-byte Version field in the
> block header (see, Fig. 6) and use, e.g., the high 2-byte portion as
> additional nonce range."
>
> Today when you proposed a new sidechain BIP [4], Peter Todd was
> (rightly) concerned about the prior lack of disclosure of your patents
> related to your prior consensus modification proposal. Hence the
> concern is that this might be happening this time as well.
>
> There is no evidence that any of the other filers for the
> ASICBOOST-like patents by mining companies other than your own were
> going to be using it offensively as those other companies appeared to
> understand the decentralization risk of having an advantage enforced
> by legal and not technical means.
>
> It's great that you have now committed to looking into the Defensive
> Patent License. This seems likely to mitigate some of the patent
> concerns. Although it would be a show of good faith if you also agreed
> to license ASICBOOST under the DPL.
>
> [1]: BIP: https://github.com/BlockheaderNonce2/bitcoin/wiki
> [2]: ASICBOOST PATENT https://www.google.com/patents/WO2015077378A1?cl=en
> [3]: Extra nonce pull request: https://github.com/bitcoin/
> bitcoin/pull/5102
> [4]: COUNT_ACKS
> [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/
> 013174.html
>
> On Sun, Oct 2, 2016 at 6:13 PM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Please Peter Todd explain here all what you want to say about a patent
> of a
> > hardware design for an ASIC.
> >
> > Remember that ASICBoost is not the only patent out there, there are at
> least
> > three similar patents, filed by major Bitcoin ASIC manufacturers in three
> > different countries, on similar technologies.
> >
> > That suggest that the problem is not ASICBoot's: you cannot blame any
> > company from doing lawful commerce in a FREE MARKET.
> >
> > It is a flaw in Bitcoin design that could be corrected if the guidelines
> I
> > posted in [1] had been followed.
> >
> > [1]
> > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-
> the-bitcoin-block-header/
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/ed3b4e7a/attachment.html>

2023-06-07 17:50:35 UTC

- reply

📅 Original date posted:2016-05-11
📝 Original message:On Wed, May 11, 2016 at 3:47 AM, Jannes Faber <jannes.faber at gmail.com>
wrote:
> On 11 May 2016 at 12:36, Henning Kopp <henning.kopp at uni-ulm.de> wrote:
>
>> On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev
>> wrote:
>> > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
>> > bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > > There is no way to tell from a block if it was mined with AsicBoost or
>> > > not. So you don’t know what percentage of the hashrate uses AsicBoost
>> at
>> > > any point in time. How can you risk forking that percentage out? Note
>> that
>> > > this would be a GUARANTEED chain fork. Meaning that after you change
>> the
>> > > block mining algorithm some percentage of hardware will no longer be
>> able
>> > > to produce valid blocks. That hardware cannot “switch over” to the
>> majority
>> > > chain even if it wanted to. Hence you are guaranteed to have two
>> > > co-existing bitcoin blockchains afterwards.
>> > >
>> > > Again: this is unlike the hypothetical persistence of two chains
>> after a
>> > > hardfork that is only contentious but doesn’t change the mining
>> algorithm,
>> > > the kind of hardfork you are proposing would guarantee the
>> persistence of
>> > > two chains.
>> > >
>> >
>> > Assuming AsicBoost miners are in the minority, their chain will
>> constantly
>> > get overtaken. So it will not be one endless hard fork as you claim, but
>> > rather AsicBoost blocks will continue to be ignored (orphaned) until
>> they
>> > stop making them.
>>
>> At least until a difficulty adjustment on the AsicBoost chain takes
>> place. From that point on, both chains, the AsicBoost one and the
>> forked one will grow approximately at the same speed.
>>
>>
> No: you are still assuming AsicBoost miners would reject normal blocks.
> They don't now and they would have to specifically code for that as a reply
> to AsicBoost being banned. So there won't be two chains at all, only the
> main chain with a lot (more than usual) of short (few blocks) forks. Each
> forks starts anew, it's not one long fork. Therefore there is no
> "difficulty adjustment on the AiscBoost chain".
>
> Now if they do decide to ban non-AsicBoost blocks as a response to being
> banned themselves, they're just another altcoin with a different PoW and no
> one would have a reason to use them over Bitcoin (apart from maybe selling
> those forked coins asap).
>
This is what I meant. If existing hardware gets forked-out it will
inevitably lead to the creation of an altcoin. Simply because the hardware
exists and can't be used for anything else both chains will survive. I was
only comparing the situation to a contentious hardfork that does not fork
out any hardware. If the latter one is suspected to lead to the permanent
existence of two chains then a hardfork that forks out hardware is even
more likely to do so (I claim it's guaranteed).
> You're confused about what "longest" means as well: it's not just the
> number of blocks, it's the aggregate difficulty that counts: so AsicBoost
> would never become "longer" (more total work) either.
>
> Hope this helps clear things up.
>
> --
> Jannes
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/7b9660b1/attachment-0001.html>

2023-06-07 17:50:34 UTC

- reply

📅 Original date posted:2016-05-11
📝 Original message:There is no way to tell from a block if it was mined with AsicBoost or not.
So you don’t know what percentage of the hashrate uses AsicBoost at any
point in time. How can you risk forking that percentage out? Note that this
would be a GUARANTEED chain fork. Meaning that after you change the block
mining algorithm some percentage of hardware will no longer be able to
produce valid blocks. That hardware cannot “switch over” to the majority
chain even if it wanted to. Hence you are guaranteed to have two
co-existing bitcoin blockchains afterwards.
Again: this is unlike the hypothetical persistence of two chains after a
hardfork that is only contentious but doesn’t change the mining algorithm,
the kind of hardfork you are proposing would guarantee the persistence of
two chains.
Note that “AsicBoost” above is replaceable with “optimization X”. It’s
simply a logical argument: If you want to make optimization X impossible
and someone is already using optimization X you end up with two chains. So
unless you know exactly which optimizations are in use (and therefore also
know which ones are not in use) you can’t make these kind of changes.
AsicBoost is known at least since middle of 2013.
To be more precise, if you change the block validation ruleset R to block
validation ruleset S you have to make sure that every hardware that was
capable of mining R-valid blocks is also capable of mining S-valid blocks.
The problem is that chip manufacturers will not tell you which
optimizations they use. You would have to threaten to irreversibly fork
their hardware out by a rule change, only then would they start shouting
and reveal their optimization. It seems extremely dangerous to set the
precedence of a hardfork that irreversibly forks out a certain type of
mining hardware.
The part "Also the fix should be compatible with existing mining hardware."
is impossible to achieve because it's unclear what "existing mining
hardware" is. There has never been a specification of what mining hardware
should do. There are only acceptance rules.
The only way out is to go the exact opposite way and to embrace as many
optimizations as possible to the point where there are no more
optimizations left to do, or hopefully getting very close to that point.
Timo
On Tue, May 10, 2016 at 11:57 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As part of the hard-fork proposed in the HK agreement(1) we'd like to make
> the
> patented AsicBoost optimisation useless, and hopefully make further similar
> optimizations useless as well.
>
> What's the best way to do this? Ideally this would be SPV compatible, but
> if it
> requires changes from SPV clients that's ok too. Also the fix this should
> be
> compatible with existing mining hardware.
>
>
> 1)
> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>
> 2)
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160510/26eb0bad/attachment.html>

2023-06-07 17:50:32 UTC

- reply

📅 Original date posted:2016-05-11
📝 Original message:Sorry, you must have meant all 12 bytes. That makes finding a collision
substantially harder. However, you may have to restrict yourself to 10
bytes because you don't know if any hardware does timestamp rolling
on-chip. Also you create an incentive to mess around with the version bits
instead, so you would have to fix that as well. So it basically means a new
mining header with the real blockheader as a child header.
On Wed, May 11, 2016 at 9:24 AM, Timo Hanke <timo.hanke at web.de> wrote:
> Luke, do you mean to replace the first 4 bytes of the second chunk (bytes
> 64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4
> bytes of the midstate? (I assume you don't care about 12 bytes but rather
> those 4 bytes.)
>
> This does not work. All it does is adding another computational step
> before you can check for a collision in those 4 bytes. It makes finding a
> collision only marginally harder.
>
> On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via
>> bitcoin-dev
>> wrote:
>> > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
>> > sergio.d.lerner at gmail.com> wrote:
>> > > You can find it here:
>> > >
>> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo
>> > > ck-header/
>> > >
>> > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of
>> the
>> > > second 64-byte chunk. That design also allows increased nonce space in
>> > > the first 64 bytes.
>> >
>> > My mistake here. I didn't recalled correctly my own idea. The idea is to
>> > include in the second 64-byte chunk a 4-byte hash of the first chunk,
>> not
>> > the opposite.
>>
>> What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?
>> Would that work?
>>
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/6cb58d22/attachment.html>

2023-06-07 17:50:32 UTC

- reply

📅 Original date posted:2016-05-11
📝 Original message:Ups, I forgot that you take the midstate which of course depends on the
version number. So forget everything I said about the version bits. You are
right. But why take the midstate? It can be any hash of the first chunk. So
you probably want to take a hash function that's available in standard
software libraries. And I suppose midstate() is not.
On Wed, May 11, 2016 at 11:28 AM, Timo Hanke <timo.hanke at web.de> wrote:
> Sorry, you must have meant all 12 bytes. That makes finding a collision
> substantially harder. However, you may have to restrict yourself to 10
> bytes because you don't know if any hardware does timestamp rolling
> on-chip. Also you create an incentive to mess around with the version bits
> instead, so you would have to fix that as well. So it basically means a new
> mining header with the real blockheader as a child header.
>
> On Wed, May 11, 2016 at 9:24 AM, Timo Hanke <timo.hanke at web.de> wrote:
>
>> Luke, do you mean to replace the first 4 bytes of the second chunk (bytes
>> 64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4
>> bytes of the midstate? (I assume you don't care about 12 bytes but rather
>> those 4 bytes.)
>>
>> This does not work. All it does is adding another computational step
>> before you can check for a collision in those 4 bytes. It makes finding a
>> collision only marginally harder.
>>
>> On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via
>>> bitcoin-dev
>>> wrote:
>>> > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
>>> > sergio.d.lerner at gmail.com> wrote:
>>> > > You can find it here:
>>> > >
>>> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo
>>> > > ck-header/
>>> > >
>>> > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of
>>> the
>>> > > second 64-byte chunk. That design also allows increased nonce space
>>> in
>>> > > the first 64 bytes.
>>> >
>>> > My mistake here. I didn't recalled correctly my own idea. The idea is
>>> to
>>> > include in the second 64-byte chunk a 4-byte hash of the first chunk,
>>> not
>>> > the opposite.
>>>
>>> What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?
>>> Would that work?
>>>
>>> Luke
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/faae91b2/attachment.html>

2023-06-07 17:50:32 UTC

- reply

📅 Original date posted:2016-05-11
📝 Original message:Luke, do you mean to replace the first 4 bytes of the second chunk (bytes
64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4
bytes of the midstate? (I assume you don't care about 12 bytes but rather
those 4 bytes.)
This does not work. All it does is adding another computational step before
you can check for a collision in those 4 bytes. It makes finding a
collision only marginally harder.
On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via bitcoin-dev
> wrote:
> > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
> > sergio.d.lerner at gmail.com> wrote:
> > > You can find it here:
> > >
> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo
> > > ck-header/
> > >
> > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of
> the
> > > second 64-byte chunk. That design also allows increased nonce space in
> > > the first 64 bytes.
> >
> > My mistake here. I didn't recalled correctly my own idea. The idea is to
> > include in the second 64-byte chunk a 4-byte hash of the first chunk, not
> > the opposite.
>
> What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?
> Would that work?
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/499e1347/attachment.html>

2023-06-07 17:50:03 UTC

- reply

📅 Original date posted:2016-04-01
📝 Original message:Hi.
I'd like to announce a white paper that describes a very new and
significant algorithmic improvement to the Bitcoin mining process which has
never been discussed in public before. The white paper can be found here:
http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf
Regards,
Timo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160331/00d287f0/attachment.html>

2023-06-07 15:20:28 UTC

- reply

📅 Original date posted:2014-04-27
📝 Original message:I'd like to put the following draft of a BIP up for discussion.
Timo
# Abstract
There are incentives for miners to find cheap, non-standard ways to generate new work, which are not necessarily in the best interest of the protocol.
In order to reduce these incentives this proposal re-assigns 2 bytes from the version field of the block header to a new extra nonce field.
# Copyright
# Specification
The block version number field in the block header is reduced in size from 4 to 2 bytes.
The third and fourth byte in the block header are assigned to the new extra nonce field inside the block header.
# Motivation
The motivation of this proposal is to provide miners with a cheap constant-complexity method to create new work that does not require altering the transaction tree.
Furthermore, the motivation is to protect the version and timestamp fields in the block header from abuse.
# Rationale
Traditionally, the extra nonce is part of the coinbase field of the generation transaction, which is always the very first transaction of a block.
After incrementing the extra nonce the minimum amount of work a miner has to do to re-calculate the block header is a) to hash the coinbase transaction and b) to re-calculate the left-most branch of the merkle tree all the way to the merkle root.
This is necessary overhead a miner has to do besides hashing the block header itself.
We shall call the process that leads to a new block header from the same transaction set the _pre-hashing_.
First it should be noted that the relative cost of pre-hashing in its traditional form depends
on the block size, which may create an unwanted incentive for miners
to keep the block size small. However, this is not the main motivation for
the current proposal.
While the block header is hashed by ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required.
Consequently, as ASIC cost per hash performance drops the relative cost of pre-hashing increases.
This creates an incentive for miners to find cheaper ways to create new work than by means of pre-hashing.
An example of this currently happening is the on-device rolling of the timestamp into the future.
These ways of creating new work are unlikely to be in the best interest of the protocol.
For example, rolling the timestamp faster than the real time is unwanted (more so on faster blockchains).
The version number in the block header is a possible target for alteration with the goal of cheaply creating new work.
Currently, blocks with arbitrarily large version numbers get relayed and accepted by the network.
As this is unwanted behaviour, there should not exist any incentive for a miner to abuse the version number in this way.
The solution is to reduce the range of version numbers from 2^32 to 2^16 and to declare the third and forth bytes of the block header as legitimate space for an extra nonce.
This will reduce the incentive for a miner to abuse the shortened version number by a factor in the order of 2^16.
As a side effect, this proposal greatly reduces the bandwidth requirements of a blind pool protocol by only submitting the block header to the miner.
# Backwards Compatibility
Old versions of the client will accept blocks of this kind but will throw an alert at the user to upgrade.
The only code change would be a cast of the version number to a short.
Besides the upgrade alert, old and new versions of the client can co-exist and there is no need to introduce a new block version number or to phase-out old block versions.
# Reference Implementation
# Final implementation
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8

2023-06-07 15:08:33 UTC

- reply

📅 Original date posted:2013-11-04
📝 Original message:On Sun, Nov 03, 2013 at 09:39:42AM +0100, Thomas Voegtlin wrote:
>
> Le 03/11/2013 08:40, Timo Hanke a écrit :
> >I think the communication would have to go the other way around. Trezor
> >has to commit to a value First. Like this:
> >
> >Trezor picks random s and sends S=s*G to computer, keeping s secret.
> >Computer picks random t and sends t to Trezor. Trezor makes r := s+t
> >its internal master private key with corresponding master public key
> >R := (s+t)*G. Since R = S+t*G, the computer can verify the master
> >public key. As you say, the computer can then store R and can later
> >verify for each derived pubkey that it was indeed derived from R, hence
> >from his own entropy t.
>
> I'm not sure how this differs from what I wrote...
Sorry, yes, of course it's the same..
Your very first proposal was fine, provided that Trezor commits to its
random value first.
> However, if this is how it works, then my question remains:
> The computer has no proof to know that pubkeys derived through
> bip32's private derivations are derived from its own entropy...
> This verification would only work for public (aka type2) derivations.
>
> .. but maybe Trezor works in a different way? I think an explanation
> from slush would be needed.
Does Trezor even use private derivation?
Regardless of whether the derivation is private or public, and
regardless of what kind of proof you use to show that the master public
key was derived from user supplied entropy, my question also remains:
How do you verify your backup? The backup is a seed or private key. It's
too long to do any meaningful computation by hand. So you would need a
second offline device, eg a second Trezor in "restore mode", just to
verify your backup.
Timo
> >However, Trezor could not use straight bip32 out of the box. The
> >chaincode would have to be something like SHA(R). And the seed (that
> >gets translated to mnemonic) would be r itself, making it 256 bit
> >instead of only 128 bit.
> >
> >If the longer seed is bearable then this is a good way to do it.
> >
> >One question remains: if you only write down the mnemonic how can you be
> >sure that it is correct and corresponds to the secret in Trezor? You
> >cannot verify that on paper. You would have to restore it on some
> >device, eg another empty Trezor, and see if it brings up the same master
> >pubkey. Right?
> >
> I guess you have to trust Trezor that it derives R from r
>
>
>
>
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8

2023-06-07 15:08:32 UTC

- reply

📅 Original date posted:2013-11-03
📝 Original message:On Sat, Nov 02, 2013 at 10:44:58AM +0100, Thomas Voegtlin wrote:
>
> >To be specific, we (in cooperation with / inspired by Timo Hanke)
> >developed method how to prove that the seed generated by Trezor
> >has been created using combination of computer-provided entropy
> >and device-provided entropy, without leaking full private
> >information to other computer, just because we want Trezor to be
> >blackbox-testable and fully deterministic (seed generation is
> >currently the only operation which uses any source of RNG).
> >
>
> Thanks for the explanation. Here is how I understand how it works,
> please correct me if I'm wrong:
>
> The user's computer picks a random number a, the Trezor picks a
> random number b.
> Trezor adds a and b in the secp256k1 group, and this creates a
> master private key k.
> Trezor sends the corresponding master public key K to the computer.
> Thus, the computer can check that K was derived from a, without knowing b.
No. You mean the computer would use B for this check?
(k,K) could be rigged by Trezor, who computes b as k-a.
Timo
> This also allows the computer to check that any bitcoin address
> derived from K is derived from a, without leaking b. (and
> reciprocally)
>
> However, it seems to me that this property will work only with bip32
> public derivations; if a private derivation is used, don't you need
> to know k?
>
>
>
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8

2023-06-07 15:08:32 UTC

- reply

📅 Original date posted:2013-11-03
📝 Original message:I think the communication would have to go the other way around. Trezor
has to commit to a value First. Like this:
Trezor picks random s and sends S=s*G to computer, keeping s secret.
Computer picks random t and sends t to Trezor. Trezor makes r := s+t
its internal master private key with corresponding master public key
R := (s+t)*G. Since R = S+t*G, the computer can verify the master
public key. As you say, the computer can then store R and can later
verify for each derived pubkey that it was indeed derived from R, hence
from his own entropy t.
However, Trezor could not use straight bip32 out of the box. The
chaincode would have to be something like SHA(R). And the seed (that
gets translated to mnemonic) would be r itself, making it 256 bit
instead of only 128 bit.
If the longer seed is bearable then this is a good way to do it.
One question remains: if you only write down the mnemonic how can you be
sure that it is correct and corresponds to the secret in Trezor? You
cannot verify that on paper. You would have to restore it on some
device, eg another empty Trezor, and see if it brings up the same master
pubkey. Right?
Timo
On Sun, Nov 03, 2013 at 08:03:54AM +0100, Thomas Voegtlin wrote:
>
> Le 03/11/2013 07:41, Timo Hanke a écrit :
> >No. You mean the computer would use B for this check? (k,K) could
> >be rigged by Trezor, who computes b as k-a. Timo
>
> I was just asking a question, in order to understand how this device
> works, and what are its requirements.
> if you think you can help, please explain.
>
>
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8

2023-06-07 15:08:30 UTC

- reply

📅 Original date posted:2013-11-03
📝 Original message:On Sat, Nov 02, 2013 at 02:14:22PM -0700, Johnathan Corgan wrote:
> On 11/01/2013 10:01 PM, bitcoingrant at gmx.com wrote:
>
> > Server provides a token for the client to sign.
>
> Anyone else concerned about signing an arbitrary string? Could be a
> hash of $EVIL_DOCUMENT, no? I'd want to XOR the string with my own
> randomly generated nonce, sign that, then pass the nonce and the
> signature back to the server for verification.
There were several replies like this, suggesting the client should
modify or add something to the token, or should give the token some
structure. But signing a token is not what the client should do in the
first place. At least not if the client's key is (EC)DSA. The standard
way is a challenge-response protocol in the form of the Diffie-Hellman
key exchange, which avoids producing any unintentional signatures.
Say the clients wants to prove he owns private key p, belonging to
public key P. P=p*G and G is the "base" of the (EC)DSA signature system.
The server generates a new keypair (a,A), a is private, A is public, and
sends A to the client as a challenge. The client computes and sends p*A
back. The server verifies whether p*A = a*P.
Only "public keys" are exchanged here, there's nothing that can be
mistaken for a (EC)DSA signature.
Timo
> --
> Johnathan Corgan, Corgan Labs
> SDR Training and Development Services
> http://corganlabs.com
> begin:vcard
> fn:Johnathan Corgan
> n:Corgan;Johnathan
> org:Corgan Enterprises LLC dba Corgan Labs
> adr:;;6081 Meridian Ave. Suite 70-111;San Jose;CA;95120;United States
> email;internet:johnathan at corganlabs.com
> title:Managing Partner
> tel;work:+1 408 463 6614
> x-mozilla-html:FALSE
> url:http://corganlabs.com
> version:2.1
> end:vcard
>
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8

2023-06-07 15:03:34 UTC

- reply

📅 Original date posted:2013-06-19
📝 Original message:On Wed, Jun 19, 2013 at 10:39:04AM -0400, Alan Reiner wrote:
> On 06/19/2013 10:25 AM, Timo Hanke wrote:
> > Since you mention to use this in conjunction with the payment protocol,
> > note the following subtlety. Suppose the payer has to paid this address
> > called "destination":
> >> Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
> >> checksum)
> > Also suppose the payee has spent the output, i.e. the pubkey
> > corresponding to "destination", which is PubKeyParent * Multiplier[i],
> > is publicly known. Then anybody can (in retrospect) create arbitrary
> > many pairs {PublicKeyParent, Multiplier} (in particular different
> > PublicKeyParent) that lead to the same "destination".
> >
> > Depending on what you have in mind that the transaction should "prove"
> > regarding its actual receiver or regarding the receiver's PubKeyParent,
> > this could be an unwanted feature (or it could be just fine). If it is
> > unwanted then I suggest replacing
> > PubKeyParent * Multiplier[i] by
> > PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
> > which eliminates from the destination all ambiguity about PubKeyParent.
> >
> > This modification would not be directly compatible with BIP32 anymore
> > (unfortunately), but seems to be better suited for use in conjunction
> > with a payment protocol.
> >
> > Timo
>
> It's an interesting observation, but it looks like the most-obvious
> attack vector is discrete log problem: spoofing a relationship between
> a target public key and one that you control. For instance, if you see
> {PubA, Mult} produces PubB and you have PubC already in your control
> that you want to "prove" [maliciously] is related to PubB, then you have
> to find the multiplier, M that solves: M*PubC = PubB. That's a
> discrete logarithm problem.
Correct, for a given PubC in advance you can't create such a "malicious"
relation to PubB. You can only "reversely" construct new PubC from given
PubB.
> I'm not as familiar as you are, with the available operations on
> elliptic curves, but it sounds like you can produce essentially-random
> pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
> the private key associated with those public keys.
Depends on who is "you". The arbitrary person who produces {PubX, Mult}
won't have the private key, but the person who knows the private key for
PubA will have it (assuming that PubB was computed from {PubA, Mult} in
the first place).
In the end, it all depends on your application. What proves enough for
one party doing repeated transactions with another may not suffice for a
third party doing auditing. On the other hand, ambiguity about PubA may
just as well be a wanted feature for deniability reasons.
Timo
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8

2023-06-07 15:03:32 UTC

- reply

📅 Original date posted:2013-06-20
📝 Original message:On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
> I think Timo's point is that while you cant do discrete log, you can do y-th
> root. So if P = xG is a parent public key (x private key, G base point),
> then your proposed multiplier address is hash of Q=yP. However its easy to
> find another P such that Q=zP'. ie just "divide by z" (EC multiply by z^-1
> mod n, n the order of the curve). So P'=z^-1.Q, which will work because
> Q=zP', substituting P' you get Q=z.z^-1.Q, Q=Q.
>
> Of course the attacker has just performed an unspenable DoS (maybe, or maybe
> a useless collision) because he wont know the discrete log of Q, nor P, nor
> P'. So thats the question, does the protocol have any reliance on knowing
> the discrete log - is it a problem if someone can find different multipliers
> of different (unknown, uncomputable discrete log) parent keys.
>
> If it was a concern I guess you could require a proof of knowledge of
> discrete log. ie as well as public key parent, multiplier the address must
> include ECDSA sig or Schnorr proof of knowledge (which both demonstrate
> knowledge of the discrete log of Q to base G.)
The "concern" (if there is any) would be that the owner of the parent
P=xG, i.e. the person knowing x, in addition to y creates another pair
(P',z) such that yP=Q=zP' and uses that second pair maliciously later on
(such as claiming the payment went to identity P' not P). Since the
owner of P knows the private key for P' (x*y*z^-1) he can also produce
proof of knowledge for discrete log for P'. I think adding proof of
knowledge or signatures on the multiplier don't help to eliminate all
possible concerns, which could involve proving something to a third
party that has not seen the communication between payer and payee.
If you consider only payer and payee then Alan's original proposal is
just fine, as far as I can tell. Only if you start using it in a payment
protocol or, more precisely, if you start interpreting P as an identity
(as Alan suggested in subsequent posts) _and_ this identity is a
public/global one rather than a local one that only the payer uses, then
reasons can pop up to eliminate ambiguity about which identity each
payment went to.
Timo
ps the fact that this post used the multiplicative rather than additive
derivation scheme doesn't change the argument.
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8

2023-06-07 15:03:30 UTC

- reply

📅 Original date posted:2013-06-19
📝 Original message:Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called "destination":
> Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
> checksum)
Also suppose the payee has spent the output, i.e. the pubkey
corresponding to "destination", which is PubKeyParent * Multiplier[i],
is publicly known. Then anybody can (in retrospect) create arbitrary
many pairs {PublicKeyParent, Multiplier} (in particular different
PublicKeyParent) that lead to the same "destination".
Depending on what you have in mind that the transaction should "prove"
regarding its actual receiver or regarding the receiver's PubKeyParent,
this could be an unwanted feature (or it could be just fine). If it is
unwanted then I suggest replacing
PubKeyParent * Multiplier[i] by
PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
which eliminates from the destination all ambiguity about PubKeyParent.
This modification would not be directly compatible with BIP32 anymore
(unfortunately), but seems to be better suited for use in conjunction
with a payment protocol.
Timo
On Mon, Jun 17, 2013 at 11:48:22PM -0400, Alan Reiner wrote:
> Goal: An alternative address format made possible by BIP 32, which allows one
> to specify a "Wallet ID" and "One-time payment" code, instead of the standard
> one-use Base58-Hash160 addresses. This allows parties with a persistent
> relationship to be able to prove that payment addresses they provide each other
> are linked to a particular wallet, reducing exposure to MitM attacks without
> the need for SSL or a web of trust, and without compromising the privacy of
> either party. For instance, this could be used between businesses that
> frequently do business, by exchanging and verifying public keys beforehand, or
> could be used by an exchange to identify if a customer withdrawal address is
> related to their last deposit address, and if not enforce extra authentication
> measures.
>
> Background:
> I haven't been following the payment protocol discussions/development much, so
> I apologize if this has already been addressed. I'm calling it
> "wallet-linkable" addresses, which would be an optional second form for sending
> someone your address. With BIP 32, the address is computed by the payee (the
> person sending the address to receive money):
>
> Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
> checksum)
>
> What I'd like to do is have the option, when specifying an address through the
> payment protocol, to send *just* the {PublicKeyParent, Multiplier[i]} and let
> the receiver of that address compute the address on their own. This is no
> significant burden on the receiver, but it does provide the useful property
> that they can recognize when addresses specified in this way come from the same
> wallet -- because the PubKeyParent will be the same. Remember, this is
> optional for the person providing the address.
>
> One nice, accidental feature of BIP 32 is that the Multiplier[i] used above
> does not actually reveal the "chaincode" (I think Pieter started calling it the
> "tweak"). It is derived from the chaincode but doesn't reveal it. Therefore,
> the payer sees the parent public key, but that's not useful to derive any of
> the other addresses unless they also have the chaincode. But they can verify
> that the PublicKeyParent is identical between transactions, and thus is
> accessible only to that wallet. It allows them validate a specific address
> provided by the payee, but not generate or identify any other addresses.
>
> Use Cases:
> (1) So, just like with PGP/GPG, when two parties decide they will start a
> relationship, they can start by exchanging the public keys of their wallet and
> verify them in a reliable manner. After that, when one party requests a
> payment address from the other, they can optionally send {PubKey, Multiplier},
> and the payer's software will identify the owner of that address, or let you
> select who you think the address belongs to and it will verify it. If the
> payee's system is compromised and address is replaced, the address received by
> the payer won't validate. This doesn't help if the side sending the money is
> compromised.
>
> (2) When a customer first provides a deposit to an exchange, it will send
> money from an address in their wallet and the software will provide the
> exchange the {PubKey,Mult}. When the customer later provides a withdrawal
> address, the site can automatically trust the address as long it is provided in
> the alternate form and the public keys match. If they don't, it might be the
> same customer just requesting a withdrawal to a different wallet, which is
> fine, but they'll have to go through an extra verification step to do so.
>
>
> Downsides:
> Multi-sig/P2SH - The only way this works with P2SH, violates one of the goals
> of P2SH slightly, but may not matter much if it's all done under the hood by
> the software. Instead of providing a 20-byte hash of a script, you provide all
> the public keys and multipliers for the individual addresses. The payer's
> software automatically verifies all addresses and creates the P2SH script
> itself (after a divine decree that public keys will always be sorted
> lexicographically in the multi-sig script). The blockchain still benefits from
> the "compression" of moving the bulky scripts to the TxIn, but it does require
> revealing more information than is necessary for the payer to pay the payee.
> But it may not really be a problem, given the benefits. It might just be
> slightly longer strings to exchange during initialization and for each
> transaction.
>
> I have various reasons I'd like to use this, and it'd be nice to have some
> community backing, so I don't have to twist anyone's arm to trust me that it's
> legit.
>
> -Alan
>
>
>
>
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8

2023-06-07 11:31:26 UTC

- reply

📅 Original date posted:2013-02-11
📝 Original message:On Sat, Feb 09, 2013 at 07:01:48PM +0000, Luke-Jr wrote:
> On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote:
> > namcoin tries to solve a different problem, DNS, whereas I want
> > to establish an identity for a payment protocol.
>
> What is the technical difference here? Namecoin ties names to data; DNS is a
> specific namespace in it. There is no reason I know of that this identity
> stuff cannot be a new namespace.
It's not about technical differences, but about the different use or
purpose, which can result in different security demands. I argue that
DNS has a lower demand in this respect than payment ids have. So DNS
data can be in a chain with a hashrate lower than bitcoin's hashrate but
payment ids _for_ bitcoin have to be in a chain with equal hashrate.
> > You can argue that alt-chains _can_ be as strong as bitcoin, but they
> > don't _have to_ be. There is no guarantee how many people will
> > cross-mine.
>
> This is true of namecoin, but it does not have to be true of new merged-mined
> data. You could very well require the Bitcoin proof-of-work to be valid and
> the master header to be in the Bitcoin blockchain.
Ok, true. This does the trick. If few miners merge-mine then the new
chain just becomes slower. But is this still an alt-chain? It is not
independently verifiable anymore, like the alt-chains described in the
wiki are. Instead, you need to refer to the bitcoin's chain to see if
the target is correct. Not sure if I got you right on this. But it seems
to be essentially a more efficient version of what I proposed, rather
than a true alt-chain.
I suppose you suggest to place the master header hash into the coinbase.
A drawback may be that it puts miners at a great advantage over regular
users. This could (but doesn't have to) become relevant depending on
your counter-measures against excessive alias registration. I think
Peter addressed this (below).
On Fri, Feb 08, 2013 at 06:01:08AM -0500, Peter Todd wrote:
> Finally, why is this implemented within the reference client? Use the
> raw transaction API and make up your own database. If you want, create a
> RPC command that allows you to query the UTXO set directly; this would
> be a useful feature to have. This patch will never be accepted to the
> reference client, so you'll just wind up having to maintain a fork. Even
> for a prototype this approach is ill-advised - prototypes have a bad way
> of turning into production code.
This was not intended to be a prototype and will certainly not be
maintained. It is a demo to be run on the testnet to get a feel of how
the user interface (RPC) and the "work flow" could look like, starting
from the creation of a certificate all the way to paying to a
customer-derived payment addresses (pay-to-contract) when the merchant's
base address is defined in the certificate. There's an appeal to be able
to issue
./bitcoind sendtoalias foo deadbeef 10
and being sure that 10 BTC go, e.g., to a unique P2SH multisig address
that is derived for order number 'deadbeef' from the two pubkeys that
foo defined in his certificate. And having the certificate verification
happen automatically in the background. The demo is in the reference
client a) to simulate this feel, b) because it was the fastest way to
code it. Apart from that, it could have just as well been separate, and
an UTXO query-RPC would certainly be nice.
Another reason for this demo was the fun of devising a certificate that
can handle all this.
BTW, I'm sure that some form of certificate handling will find its way
directly into the reference client. The user will want to trust only one
piece of software running on one piece of dedicated hardware.
On Mon, Feb 11, 2013 at 06:21:03AM -0500, Peter Todd wrote:
> In what way are you not solving the same problem as DNS? I don't mean
> the Luke-Jr's (quite correct) technical point about key-value maps, I
> mean the human problem that I have these unique numbers that I can't
> memorize, and I have some non-unique names that I can.
>
> By creating Yet Another Totally Different System you are just creating
> another way that users can be confused into thinking some name snatched
> up by some scammers in some little-used PKI system is who they are
> supposed to be communicating with. Fortunately your PKI system isn't
> actually used and probably never will be, so it's not a big deal yet,
> but ultimately you are adding to the problem.
What exactly is the problem, the "little-used"? Otherwise it's the same
as it is now, you pick up an interesting domain name on the street, type
it in, and start communicating with who you think it is, and maybe even
pay them. The EV that centralized PKI offers prevents only some attacks,
and may even create a false sense of security.
> Go work on namecoin and make it more usable. Then add some PKI to it
> using the *same* domain names so when I see a PKI certificate for "foo"
> I know it must be the same "foo" website I just visited and the same
> "foo at foo" I just emailed.
No. I outlined above why I think namecoin is unsuitable (but Luke's
suggestion for a new alt-chain may be). BTW, if you want to link aliases
of some "bitcoin PKI" and "domain names", they should not correspond
bijectively to each other. The "bitcoin alias" corresponds to a payment
base address, which I see as a more universal identifier than a domain
name. First, bitcoin alias foo can have several domains foo.com,
foo.co.uk, etc. but still only one "bitcoin certificate". This can be
achieved by either writing the domain names directly into the
certificate, or better, by having the "bitcoin certificate" sign an SSL
sub-certificate and tell your browser to ask bitcoind to verify it.
Second, a bitcoin alias can be meaningful without any domain names, e.g.
it can be a certificate for all vending machines of a certain seller,
with who you interact directly, say NFC. To summarize, I would either
not link bitcoin aliases with domain names, or put SSL certificates
"below" bitcoin certificates in the verification chain.
Also BTW, it is the beauty of the pay-to-contract principle that
authenticated communication is not even required. This means that if you
know you have the correct "bitcoin certificate" stored with your
bitcoind and you pay to it, then it doesn't matter if you ordered on a
wrong or fake website. The worst-case scenario is that you have to call
in via another channel and re-submit your order, but funds are never
lost.
> Alt-chains don't have to be based on mining you know. Your proof-of-work
> can be replaced by proof-of-sacrifice, specifically Bitcoins.
> [...]
> 1) https://github.com/petertodd/trustbits/blob/master/fidelitybond.md
Yes, I already read your discussing of sacrifice-methods after your
first reply and found it interesting.. The problem I see is to
dynamically (and automatically) adjust the minimum sacrifice amount. A
strict limit on the number of registrations like namecoin has is not
desirable. A constant sacrifice, as you mentioned earlier, is also
undesirable. A good measure could be the average transaction fee taken
over several blocks. Maybe the minimum sacrifice should be a constant
times that.
> > You are probably right that storing this in the _spent outputs_
> > would be better [than UTXO]. There doesn't seem to be any type of
> > client out there that would benefit from having to search UTXO only.
>
> The blockchain grows at a maximum rate of 55GiB/year. Do you think your
> users will all want to have that available just to validate some PKI
> certificates?
Actually yes. They are also willing to do that to verify their payments,
so why not for the certificate? But true, this was the reason why I
thought of putting it in the UTXO. To enable some future dedicated
"hardware wallet" to keep only the UTXO and to verify against it. Where
would you store you alt-chain block header hashes? UTXO?
BTW, suppose you avoid any squatting (there would certainly be ways to
do that). Then with my original proposal of one transaction per
registration you would grow the UTXO by O(n), n is the number of users.
Each user would create a small constant number of aliases. This number
will certainly be dwarfed by the number of unspend outputs that each
user keeps anyway as a result of their regular transactions. So it would
not present a problem for the UTXO. Actually, anything above the dust
threshold should not be a problem, or the system is misdesigned. But of
course the alt-chain header hashes would only take O(1), much better.
Timo

2023-06-07 11:31:20 UTC

- reply

📅 Original date posted:2013-02-09
📝 Original message:On Fri, Feb 08, 2013 at 06:01:08AM -0500, Peter Todd wrote:
> On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote:
> > First, we have drafted a quite general specification for bitcoin certificates (protobuf messages) that allow for a variety of payment protocols (e.g. static as well as customer-side-generated payment addresses).
> > This part has surely been done elsewhere as well and is orthogonal to the goal of this project.
> > What is new here is the signatures _under_ the certificates.
> >
> > We have patched the bitcoind to handle certificates, submit signatures to the blockchain, verify certificates against the blockchain, pay directly to certificates (with various payment methods), revoke certificates.
> > Signatures in the blockchain are stored entirely in the UTXO set (i.e. the unspend, unprunable outputs).
> > This seems to make signature lookup and verification reasonably fast:
> > it took us 10s in the mainnet test we performed (lookup is instant on the testnet, of course).
>
> Why don't you use namecoin or another alt-chain for this?
Because namcoin tries to solve a different problem, DNS, whereas I want
to establish an identity for a payment protocol. Your incoming payments
will land on addresses that are derived (regardless which way) from this
idenity. This makes your identity as important (securitywise) as
anything else involved in the bitcoin protocol. Therefore I would not
want to have payment-ids rely on anything _less_ than bitcoin's own
blockchain. In particular not on PKI with centralized root CAs. But also
not on namecoin or any other (weaker) alt-chains.
You can argue that alt-chains _can_ be as strong as bitcoin, but they
don't _have to_ be. There is no guarantee how many people will
cross-mine. The alt-chain could even disappear at some point. If at some
point your alt-chain is no longer being worked on, then how do you prove
that some old bitcoin transaction went to an address for which there was
a valid id/certificate at the time of sending? If the certificate is
based inside bitcoin's blockchain then you will have a proof for the
correct destinations of all your old transactions as long as bitcoin
exists.
Besides all this, as you mentioned namecoin specifically, that is
overkill if you just want to link two hashes together. A single 2-of-2
multisig output would suffice for that.
> The UTXO set is the most expensive part of the blockchain because it
> must be stored in memory with fast access times. It's good that you have
> designed the system so that the addresses can be revoked, removing them
> from the UTXO set, but it still will encourage the exact same type of
> ugly squatting behavior we've already seen with first-bits, and again
> it'll have a significant cost to the network going forward for purposes
> that do not need to be done on the block chain.
You are probably right that storing this in the _spent outputs_ would be
better. There doesn't seem to be any type of client out there that would
benefit from having to search UTXO only.
Timo

2023-06-07 11:31:13 UTC

- reply

📅 Original date posted:2013-02-08
📝 Original message:There have been proposals to use the blockchain to establish
"identities". firstbits is a simple example. I would like to announce a
project that extends this idea to turn the blockchain into a "root CA"
that can sign arbitrary certificates. The purpose is to use these
certificates in the payment protocol, where some might consider
traditional centralized root CAs unsatisfactory.
Code is here: https://github.com/bcpki
Technical specification and full-length examples are found in the wiki.
I therefore spare myself from repeating the details here, even though,
of course, discussion about those details is welcome on this list.
Excerpt from README.md follows:
First, we have drafted a quite general specification for bitcoin certificates (protobuf messages) that allow for a variety of payment protocols (e.g. static as well as customer-side-generated payment addresses).
This part has surely been done elsewhere as well and is orthogonal to the goal of this project.
What is new here is the signatures _under_ the certificates.
We have patched the bitcoind to handle certificates, submit signatures to the blockchain, verify certificates against the blockchain, pay directly to certificates (with various payment methods), revoke certificates.
Signatures in the blockchain are stored entirely in the UTXO set (i.e. the unspend, unprunable outputs).
This seems to make signature lookup and verification reasonably fast:
it took us 10s in the mainnet test we performed (lookup is instant on the testnet, of course).
Payment methods include: static bitcoin addresses, client-side derived
payment addresses (pay-to-contract), pay-to-contract with multisig destinations (P2SH)
Full-length real-world examples for all payment methods are provided in the tutorial pages.
These examples have actually been carried out on testnet3.
For further details and specifications see the wiki.
timo hanke