Natanael [ARCHIVE]

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

Public Key

npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjt

Profile Code

nprofile1qqs0zneuwxjwvwsjeppwffgywynr4kjtdn77pylukevgdya8y6umqxqaz248g

Author Public Key

npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjt

Show more details

Last Notes

2023-06-07 18:18:15

- reply

📅 Original date posted:2019-05-24
📝 Original message:On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.
To deal with potentially wildly varying difficulty, could the value exposed
be the sum of accumulated PoW, or in other words the sum of each block's
difficulty value in the entire chain? This should be a value that will only
rise unless a reorg happens after a difficulty drop happens (only likely to
be the result of users manually blacklisting an otherwise valid block that
is several blocks back in the chain).
This mimics the effect of the block number which only grows. So if you're
starting at time A with difficulty X, then you'd estimate what you think
the accumulated PoW ought to be at time B with expected difficulty Y (as
compared to the current value at time A), and put that value into the
script.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190524/2cdfd6bc/attachment.html>

2023-06-07 18:17:37

- reply

📅 Original date posted:2019-04-07
📝 Original message:Related ideas previously submitted by me;
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013885.html
Title: Block size adjustment idea - expedience fees + difficulty scaling
proportional to block size (+ fee pool)
Den sön 7 apr. 2019 17:45simondev1 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> skrev:
> Dear bitcoin developers,
>
> New BIP: https://github.com/bitcoin/bips/pull/774
>
> ==Abstract==
> Logarithm of transaction fee limits block size.
>
> ==Motivation==
> Keep block space small.
> Waste less with spam transactions.
> Auto balance Fees: Increase very low fees, Descrease very high fees.
> Allow larger size when sender pays a lot.
> Allow wallets to calculate/display how much average free block space there
> is for each fee price.
> Allow senders to have more control about how the fee/priority of their
> transaction will behave, especially in the case of increased adoption in
> the future.
>
> ==Specification==
> Every transaction has to fit into the following block space:
> Input variable 'FeeInSatoshiPerByte': Must be positive or 0
> type: double
> unit: Satishi per byte
> Output:
> type: uint
> unit: bytes
> Formula:
> floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 )
>
> ==Implementation==
> Sort transactions by FeeInSatoshiPerByte (lowest first)
> For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the
> bytes of space used so far. Check if summed up bytes of space used so far
> is smaller or equal than the formula result.
> If this is valid for each transaction then the blocksize is valid.
>
> ==Backward compatibility==
> Soft fork: If applied AND old hardcoded block size limit is kept.
> Hard fork: If applied AND old hardcoded block size limit is removed.
>
> Regards, simondev1
>
> _______________________________________________
> 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/20190407/0f09ef59/attachment.html>

2023-06-07 18:15:14

- reply

📅 Original date posted:2018-11-19
📝 Original message:Den mån 19 nov. 2018 21:21 skrev Steven Hatzakis via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Hi Weiji, and Everyone,
>
> I think this is an important topic so sharing my two cents in case in
> helps: It makes sense for users to know that they can't merely just
> translate a word from one language into another and expect the same
> underlying entropy to be mapped, as the wordlists are not the same (i.e.
> words differ at the same index values across languages).
>
> However, while the words for each language cannot translate directly to
> their equivalent in another language, in terms of entropy (bits), the
> underlying entropy is, in fact, the same, when comparing mnemonics
> generated across languages (see English/Spanish comparison below) when
> sourced from the same initial entropy.
>
> Importantly, the entropy is a pre-image of the resulting mnemonic and
> doesn't change as the language changes, where the only changes are to the
> resulting words which depend on the language chosen, for a given entropy
> string. Ideally, the wallet/software should deal with these nuances, I
> don't think the protocol needs any revision (except for how the BIP39 seed
> is derived, perhaps), even if someone made up their own wordlist, as long
> as the wallet/software has a copy of it to map those words to the
> underlying index values, it's *those underlying index values and the
> entropy they map too is what really matters**. *
>
> I fully support the idea for users to back up this pre-image (initial
> entropy) as it can also be used to check the validity of the mnemonic and
> check that it mapped correctly, see Ian Coleman's BIP39 tool which shows
> index values, a feature that I proposed last year and was since
> implemented. Below is an example of how two mnemonics generated with the
> same entropy will produce different BIP39 seeds.
>
> * Example initial entropy of 128 bits +4 bit checksum derived from hash of
> byte array: *
>
> 10001101000 01010100100 11011010000 11100001101 01010001101 00010010001
> 01100000010 10101110100 00100100011 11110000111 01100011010 1100010 (+1110
> checksum)
>
> *In English*: minimum fee sure ticket faculty banana gate purse caught
> valley globe shift
>
> The same initial entropy above (all 132 bits) produces this mnemonic:
>
> *In Spanish*: mercado faja soledad tarea evadir aries gafas peine búho
> tumor gerente reja
>
> And the underlying index values below are the same for both the English
> and Spanish mnemonics above:
>
> Word Indexes: 1128, 676, 1744, 1805, 653, 145, 770, 1396, 291, 1927, 794,
> 1582
>
> *ISSUE AT HAND*: While the initial entropy is the same, and word indexes
> the same for a given entropy, (i.e. same pre-image), the resulting BIP39
> seed is not the same when comparing the above English mnemonic with its
> Spanish counterpart:
>
> - *English BIP39 seed:*
> ce7618075099c89e986f18dc495daa3be190450ed07bef77d4334a54dbc1cd7e205797ffed2615ac0999a5d691f65bf316e2cdbfd2c9d7d90b03e77ff1e6a6f5
> - *Spanish BIP39 seed*:
> 9f164de0fb09af51b5831886e424d6d2479d49b5e5a1b28f5c09467ea36089b144cd94bb9b636b3c27ccff96a8958e5b7ce43cf1dea81423fc66fa7fef0aea2c
>
>
> *Option 1:* Without changing anything in terms of the entropy
> generation/mapping process in the BIP39 spec, the wallet/client-side
> software would ideally recognize the language and show the corresponding
> index value per wordlist, and reverse-calculate the entropy and then re-map
> it to the language selected.
>
> *Option 2*: Perhaps a revision is needed to how the BIP39 seed is
> generated in the first place, such as by hashing the entropy instead of the
> words. Any thoughts on how viable that could be where the initial entropy
> is fed into the PBKDF2 function and not the words?
>
> *Closing thoughts and tiny checksum nitpick: *
>
> - The multiple BIP39 seeds per language lend some similarities to
> BIP44 multi-account, so perhaps this can be an advantage, depends on how it
> is applied in UI/UX's (compared to having one BIP39 seed regardless of
> language, for a given initial entropy).
> - There is perhaps an opportunity to add greater detail to the BIP39
> spec in terms of standards/best-practices for computing checksum values, as
> some software may be hashing bits, versus hashing bytes, or hashing the
> entropy as a hex string, etc.. for a given entropy, which will result in
> different checksum values for the same "valid" mnemonic, that might not be
> "valid" in another wallet which may format the data differently before
> hashing to compute the checksum.
>
This probably wouldn't work as a drop-in replacement, but having the
identifier of the chosen wordlist be part of the mnemonic might work?
Perhaps the raw seed would then be [hash of chosen dictionary]+[sequence of
word indexes].
The user experience then involves always selecting a dictionary by name. I
also suggest maintaining an official list of named dictionaries.
The purpose of including the dictionary in the seed is so that if you use
the last word as a checksum, you also can verify that the dictionary
selection is correct as well as the word sequence.
This allows substitution of words to other languages by manually specifying
a different input dictionary, but you would then have to remember both the
seed language and the translated language so you can specify both
correctly.
The user experience here matches your option 1, while the implementation
matches option 2.
If you remove specification of the seed's original language, you would need
auto detection during entry when the raw seed is just the index. I do not
recommend trying that, especially if any language would end up with
multiple competing dictionaries. Even more so if there's many related
languages which might collide (like all the Latin languages, or even US vs
UK English...).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181120/f6a48b42/attachment.html>

2023-06-07 18:12:26

- reply

📅 Original date posted:2018-05-24
📝 Original message:Den tor 24 maj 2018 04:08Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> skrev:
>
> My understanding of the question is this:
>
> Are there any useful applications which would be impeded if a signing
> party who could authorize an arbitrary transaction spending a coin had
> the option to instead sign a delegation to a new script?
>
> The reason this question is interesting to ask is because the obvious
> answer is "no": since the signer(s) could have signed an arbitrary
> transaction instead, being able to delegate is strictly less powerful.
> Moreover, absent graftroot they could always "delegate" non-atomically
> by spending the coin with the output being the delegated script that
> they would have graftrooted instead.
>
> Sometimes obvious answers have non-obvious counter examples, e.g.
> Andrews points related to blindsigning are worth keeping in mind.
>
As stated above by Wuille this seems to not be a concern for typical P2SH
uses, but my argument here is simply that in many cases, not all
stakeholders in a transaction will hold one of the private keys required to
sign. And such stakeholders would want a guarantee that the original script
is followed as promised.
I agree that such flags typically wouldn't have a meaningful effect for
funds from non-P2SH addresses, since the entire transaction / script could
be replaced by the very same keyholders.
I'm not concerned by the ability to move funds to an address with the new
rules that you'd otherwise graftroot in, only that you can provide a
transparent guarantee that you ALSO follow the original script as promised.
What happens *after* you have followed the original script is unrelated,
IMHO.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180524/1eccb847/attachment-0001.html>

2023-06-07 18:12:25

- reply

📅 Original date posted:2018-05-23
📝 Original message:Den tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> skrev:
> Hello all,
>
> Given the recent discussions about Taproot [1] and Graftroot [2], I
> was wondering if a practical deployment needs a way to explicitly
> enable or disable the Graftroot spending path. I have no strong
> reasons why this would be necessary, but I'd like to hear other
> people's thoughts.
>
I'm definitely in favor of the suggestion of requiring a flag to allow the
usage of these in a transaction, so that you get to choose in advance if
the script will be static or "editable".
Consider for example a P2SH address for some fund, where you create a
transaction in advance. Even if the parties involved in signing the
transaction would agree (collude), the original intent of this particular
P2SH address may be to hold the fund accountable by enforcing some given
rules by script. To be able to circumvent the rules could break the purpose
of the fund.
The name of the scheme escapes me, but this could include a variety of
proof-requiring committed transactions, like say a transaction that will
pay out if you can provide a proof satisfying some conditions such as
embedding the solution to a given problem. This fund would only be supposed
to pay out of the published conditions are met (which may include an expiry
date).
To then use taproot / graftroot to withdraw the funds despite this
possibility not showing in the published script could be problematic.
I'm simultaneously in favor of being able to have scripts where the usage
of taproot / graftroot isn't visible in advance, but it must simultaneously
be possible to prove a transaction ISN'T using it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180524/328e93da/attachment.html>

2023-06-07 18:12:25

- reply

📅 Original date posted:2018-05-24
📝 Original message:Den tor 24 maj 2018 01:45Gregory Maxwell <greg at xiph.org> skrev:
> I am having a bit of difficulty understanding your example.
>
> If graftroot were possible it would mean that the funds were paid to a
> public key. That holder(s) of the corresponding private key could
> sign without constraint, and so the accoutability you're expecting
> wouldn't exist there regardless of graftroot.
>
> I think maybe your example is only making the case that it should be
> possible to send funds constrained by a script without a public key
> ever existing at all. If so, I agree-- but that wasn't the question
> here as I understood it.
>
I have to admit I not an expert on this field, so some of my concerns might
not be relevant. However, I think Wuille understood my points and his reply
answered my concerns quite well. I'm only asking for the optional ability
to prove you're not using these constructions (because some uses requires
committing to an immutable script), and that already seems to exist. So for
the future implementations I only ask that this ability is preserved.
I think such a proof don't need to be public (making such a proof in
private is probably often better), although optionally it might be. A
private contract wouldn't publish these details, while a public commitment
would do so.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180524/6e1d11a6/attachment.html>

2023-06-07 18:10:45

- reply

📅 Original date posted:2018-02-13
📝 Original message:Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CAÑUELO via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
***
NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES THE
NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS THE
SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN
(CORE) BLOCKCHAIN
***
That's better solved with trademarks. (whoever would be the trademark
holder - Satoshi?)
This would also prohibit any reimplementation that's not formally verified
to be perfectly compatible from using the name.
It also adds legal uncertainty.
Another major problem is that it neither affects anybody forking older
versions of Bitcoin, not people using existing independent blockchain
implementations and renaming them Bitcoin-Whatsoever.
And what happens when an old version is technically incompatible with a
future version by the Core team due to not understanding various new
softforks? Which version wins the right to the name?
Also, being unable to even mention Bitcoin is overkill.
The software license also don't affect the blockchain data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180213/5c9fcd62/attachment-0001.html>

2023-06-07 18:10:39

- reply

📅 Original date posted:2018-02-15
📝 Original message:Den 15 feb. 2018 22:58 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
Also, the miners will indeed see one valid decommitment. This
decommitment may have been sent by the attacker but it's the preimage
chal of the address, because otherwise it's not valid for the malicious
commitment. But if the decommitment is chal, then this decommitment is
also valid for the commitment of the honest user, which is earliest
additionally. So the honest commitment wins. The attacker does not
succeed and everything is fine.
The reason why this works:
There is only one unique decommitment for the UTXO (assuming H_addr is
collision-resistant). The decommitment does not depend on the
commitment. The attacker cannot send a different decommitment, just
because there is none.
If your argument is that we publish the full transaction minus the public
key and signatures, just committing to it, and then revealing that later
(which means an attacker can't modify the transaction in advance in a way
that produces a valid transaction);
Allowing expiration retains insecurity, while allowing expiration makes it
a trivial DoS target.
Anybody can flood the miners with invalid transaction commitments. No miner
can ever prune invalid commitments until a valid transaction is finalized
which conflicts with the invalid commitments. You can't even rate limit it
safely.
Like I said in the other thread, this is unreasonable. It's much more
practical with simple hash commitment that you can "fold away" in a Merkle
tree hash and which you don't need to validate until the full transaction
is published.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180215/c5df0634/attachment-0001.html>

2023-06-07 18:10:39

- reply

📅 Original date posted:2018-02-15
📝 Original message:Small correction, see edited quote
Den 15 feb. 2018 23:44 skrev "Natanael" <natanael.l at gmail.com>:
Allowing expiration retains insecurity, while *NOT* allowing expiration
makes it a trivial DoS target.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180215/f3aca9fc/attachment.html>

2023-06-07 18:10:38

- reply

📅 Original date posted:2018-02-15
📝 Original message:Den 15 feb. 2018 17:00 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
Consensus rules
===============
A decommitment d = chal spends a UTXO with address H_addr(chal), if
there exists a commitment c in the blockchain which references the UTXO
and which is the first commitment (among all referencing the UTXO) in
the blockchain such that
1. k = KDF(chal) correctly decrypts Dec(k, c)
and
2. tx = Dec(k, c) is a valid transaction to spend UTXO
The UTXO is spent as described by tx.
Commitments never expire.
I addressed this partially before, and this is unfortunately incomplete.
Situation A: Regardless of expiration of commitments, we allow doubles. (Or
no doubles allowed, but commitments expire.)
If I can block your transaction from confirming (censorship), then I can
make my own commitment + transaction. The miners will see two commitments
referencing the same UTXO - but can see only one transaction which match a
valid challenge and spends them, which is mine. You gained nothing from the
commitment.
Situation B: We don't allow conflicting commitments, and they never expire.
I can now freeze everybody's funds trivially with invalid commitments,
because you can't validate a commitment without seeing a valid transaction
matching it - and exposing an uncommitted transaction breaks the security
promise of commitments.
Any additional data in the commitment but hash it the transaction is
pointless, because the security properties are the same. You can't freeze
an UTXO after only seeing a commitment, and for any two conflicting
transactions you may observe it does not matter at all if one references
UTXO:s or not since you already know both transactions' commitment ages
anyway. Oldest would win no matter the additional data.
Commitments work when the network can't easily be censored for long enough
to deploy the attack (at least for 2-3 blocks worth of time). They fail
when the attacker is capable of performing such an attack.
As I said previously, the only completely solid solution in all
circumstances is a quantum resistant Zero-knowledge proof algorithm, or
some equivalent method of proving knowledge of the key without revealing
any data that enables a quantum attack.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180215/7b046cd7/attachment.html>

2023-06-07 18:10:10

- reply

📅 Original date posted:2018-01-24
📝 Original message:Den 24 jan. 2018 16:38 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
Okay, I think my proposal was wrong...
This looks better (feel free to break again):
1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed
2. Reveal classic_pk in the blockchain
Then the tx in the first valid commitment wins. If the attacker
intercepts classic_pk, it won't help him. He cannot create the first
valid commitment, because it is created already. (The reason is that
the decommitment is canonical now; for all commitments, the
decommitment is just classic_pk.)
That's not the type of attack I'm imagining. Both versions of your scheme
are essentially equivalent in terms of this attack.
Intended steps:
1: You publish a hash commitment.
2: The hash ends up in the blockchain.
3: You publish the transaction itself, and it matches the hash commitment.
4: Because it matches, miners includes it. It's now in the blockchain.
Attack:
1: You publish a hash commitment.
2: The hash ends up the blockchain.
3: You publish the transaction itself, it matches the hash commitment.
4: The attacker mess with the network somehow to prevent your transaction
from reaching the miners.
5: The attacker cracks your keypair, and makes his own commitment hash for
his own theft transaction.
6: Once that commitment is in the blockchain, he publishes his own theft
transaction.
7: The attacker's theft transaction gets into the blockchain.
8 (optionally): The miners finally see your original transaction with the
older commitment, but now the theft transaction can't be undone. There's
nothing to do about it, nor a way to know if it's intentional or not.
Anybody not verifying commitments only sees a doublespend attempt.
---
More speculation, not really a serious proposal:
I can imagine one way to reduce the probability of success for the attack
by publishing encrypted transactions as the commitment, to then publish the
key - the effect of this is that the key is easier to propagate quickly
across the network than a full transaction, making it harder to succeed
with a network based attack. This naive version by itself is however a
major DoS vector against the network.
You could, in some kind of fork, redefine how blocks are processed such
that you can prune all encrypted transactions that have not had the key
published within X blocks. The validation rules would work such that to
publish the key for an encrypted transaction in a new block, that
transaction must both be recent enough, be valid by itself, and also not
conflict with any other existing plaintext / decrypted transactions in the
blockchain.
Blocks wouldn't necessarily even need to include the encrypted transactions
during propagation. This works because encrypted transactions have zero
effect until the key is published. In this case you'd effectively be
required to publish your encrypted transaction twice to ensure the raw data
isn't lost, once to get into a block and again together with the key to get
it settled.
Since miners will likely keep at least the most recent encrypted
transactions cached to speed up validation, this is faster to settle than
to publish the committed transaction as mentioned in the beginning. This
increases your chances to get your key into the blockchain to settle your
transaction before the attacker completes his attack, versus pushing a full
transaction that miners haven't seen before.
This version would still allow DoS against miners caching all encrypted
transactions. However, if efficient Zero-knowledge proofs became practical
then you can use one to prove your encrypted transaction valid, even
against the UTXO set and in terms of not colliding with existing
commitments - in this case the DoS attack properties are nearly identical
to standard transactions.
If you want to change a committed transaction, you'd need to let the
commitment expire.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180124/c42ae892/attachment.html>

2023-06-07 18:10:10

- reply

📅 Original date posted:2018-01-24
📝 Original message:Den 25 jan. 2018 00:22 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
I think you misread my second proposal. The first step is not only to
publish the hash but to publish a *pair* consisting of the hash and the
transaction.
If the attacker changes the transaction on the wire, the user does not
care and will try again.
I guess I assumed you meant it otherwise because I didn't assume you
intended a commitment to the full transaction just without the asymmetric
key material.
You could treat it the same way as in my suggestion, let it expire and
prune it if the key material isn't published in time.
However... A sufficiently powerful attacker can deploy as soon as he sees
your published signature and key, delay its propagation to the miners,
force expiration and then *still* repeat the attack with his own forgery.
Honestly, as long as we need to allow any form of expiry + relying on
publication of the vulnerable algorithms result for verification, I think
the weakness will remain.
No expiration hurts in multiple ways like via DoS, or by locking in
potentially wrong (or straight up malicious) transactions.
---
There's one way out, I believe, which is quantum safe Zero-knowledge
proofs. Currently STARK:s are one variant presumed quantum safe. It would
be used to completely substitute the publication of the public key and
signatures, and this way we don't even need two-step commitments.
It does however likely require a hardfork to apply to old transactions. (I
can imagine an extension block type softfork method, in which case old
UTXO:s get locked on the mainchain to create equivalent valued extension
block funds.)
Without practical ZKP, and presuming no powerful QC attackers with the
ability to control the network (basically NSA level attackers), I do think
the Fawkes signature scheme is sufficient. Quantum attacks are likely to be
very expensive anyway, for the foreseeable future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180125/45fe3cec/attachment.html>

2023-06-07 18:10:09

- reply

📅 Original date posted:2018-01-24
📝 Original message:Den 23 jan. 2018 23:45 skrev "Gregory Maxwell via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
On Tue, Jan 23, 2018 at 10:22 PM, Anthony Towns <aj at erisian.com.au> wrote:
> Hmm, at least people can choose not to reuse addresses currently --
> if everyone were using taproot and that didn't involve hashing the key,
Can you show me a model of quantum computation that is conjectured to
be able to solve the discrete log problem but which would take longer
than fractions of a second to do so? Quantum computation has to occur
within the coherence lifetime of the system.
Quantum computers works like randomized black boxes, you run them in many
cycles with a certain probability of getting the right answer.
The trick to them is that they bias the probabilities of their qubits to
read out the correct answer *more often than at random*, for many classes
of problems. You (likely) won't get the correct answer immediately.
https://en.wikipedia.org/wiki/Quantum_computing
Quoting Wikipedia:
> An algorithm is composed of a fixed sequence of quantum logic gates and a
problem is encoded by setting the initial values of the qubits, similar to
how a classical computer works. The calculation usually ends with a
measurement, collapsing the system of qubits into one of the 2 n
{\displaystyle 2^{n}} 2^{n} pure states, where each qubit is zero or one,
decomposing into a classical state. The outcome can therefore be at most n
{\displaystyle n} n classical bits of information (or, if the algorithm did
not end with a measurement, the result is an unobserved quantum state).
Quantum algorithms are often probabilistic, in that they provide the
correct solution only with a certain known probability.
A non programmed QC is essentially an RNG driven by quantum effects. You
just get random bits.
A programmed one will need to run the and program over and over until you
can derive the correct answer from one of its outputs. How fast this goes
depends on the problem and the algorithm.
Most people here have heard of Grover's algorithm, it would crack a
symmetric 256 bit key in approximately 2^128 QC cycles - completely
impractical. Shor's algorithm is the dangerous one for ECC since it cracks
current keys at "practical" speeds.
https://eprint.iacr.org/2017/598 - resource estimates, in terms of size of
the QC. Does not address implementation speed.
I can't seem to find specific details, but I remember having seen estimates
of around 2^40 cycles in practical implementations for 256 bit ECC (this
assumes use error correction schemes, QC machines with small some
imperfections, and more). Unfortunately I can't find a source for this
estimate. I've seen lower estimates too, but they seem entirely
theoretical.
Read-out time for QC:s is indeed insignificant, in terms of measuring the
state of the qubits after a complete cycle.
Programming time, time to prepared for readout, reset, reprogramming, etc,
that will all take a little longer. In particular with more qubits
involved, since they all need to be in superposition and be coherent at
some point. Also, you still have to parse all the different outputs (on a
classical computer) to find your answer among them.
Very very optimistic cycle speeds are in the GHz range, and then that's
still on the order of ~15 minutes for 2^40 cycles. Since we don't even have
a proper general purpose QC yet, nor one with usable amounts of qubits, we
don't even know if we can make them run at a cycle per second, or per
minute...
However if somebody *does* build a fast QC that's nearly ideal, then
Bitcoin's typical use of ECC would be in immediate danger. The most
optimistic QC plausible would indeed be able to crack keys in under a
minute. But my own wild guess is that for the next few decades none will be
faster than a runtime measured in weeks for cracking keys.
---
Sidenote, I'm strongly in favor of implementing early support for the
Fawkes scheme mentioned previously.
We could even patch it on top of classical transactions - you can only
break ECC with a known public key, so just commit to the signed transaction
into the blockchain before publishing it. Then afterwards you publish the
transaction itself, with a reference to the commitment. That transaction
can then be assumed legit simply because there was no room to crack the key
before the commitment, and the transaction matches the commitment.
Never reuse keys, and you're safe against QC:s.
Sidenote: There's a risk here with interception, insertion of a new
commitment and getting the new transaction into the blockchain first.
However, I would suggest a mining policy here were two known conflicting
transactions with commitments are resolved such that the one with the
oldest commitment wins. How to address detection of conflicting
transactions with commitments older than confirmed transactions isn't
obvious. Some of these may be fully intentional by the original owner, such
as a regretted transaction.
Another sidenote: HD wallets with hash based hardened derivation should
also be safe in various circumstances, near completely safe in the case
where they're defined such that knowing an individual private key, which is
not the root key, is not enough to derive any other in your wallet.
HD schemes that only prevent derivation of parent keypairs in the tree
would require that you never use a key derived from another already used or
published public key.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180124/10b6b113/attachment-0001.html>

2023-06-07 18:09:48

- reply

📅 Original date posted:2018-01-18
📝 Original message:A large miner would only need to divide his hardware setup into clusters
that pretend to be different independent miners to create these "miner
tokens", as explained before, to significantly raise his chances that he on
nearly every single round would be able to mine.
Once each individual token is about the expire, the number just dedicates a
fraction of his mining power to renew it. At the same time he can even
create multiple new tokens given enough hardware.
This does not reduce energy use. The only notable effect is to delay income
for new miners. This makes profitability calculations more annoying.
Long term, it only behaves like an artificially raised difficulty target.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180118/fde019fe/attachment.html>

2023-06-07 18:08:43

- reply

📅 Original date posted:2017-12-14
📝 Original message:Reposting /u/BashCo's post on reddit here, for visibility:
---8<---------------------------------------------------------------
> Before anyone says 'bits' are too confusing because it's a computer
science term, here's a list of homonyms [https://en.wikipedia.org/
wiki/List_of_true_homonyms] that you use every day. Homonyms are fine
because our brains are able to interpret language based on context, so it's
a non-argument.
This ignores the fact that there exists multiple meanings of bits *within
the same context*, and that beginners likely can't tell them apart.
Feel free to try it yourself - talk about Bitcoin "bits" of a particular
value with somebody who doesn't understand Bitcoin. Then explain that the
cryptography uses 256 bit keys. I would be surprised if you could find
somebody who would not be confused by that.
Let's say a website says a song is 24 bits. Was that 24 bit audio
resolution or 24 bit price? Somebody writes about 256 bit keys, are that
their size or value?
You guys here can probably tell the difference. Can everybody...? Bits will
cause confusion, because plenty of people will not be able to tell these
apart. They will not know WHEN to apply one definition or the other.
https://www.reddit.com/r/bitcoin/comments/24m3nb/_/ch8gua7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171214/75a7967d/attachment.html>

2023-06-07 18:04:50

- reply

📅 Original date posted:2017-08-17
📝 Original message:Couldn't scripts like this have a standardized "hardfork unroll" mechanism,
where if a hardfork is activated and signaled to its clients, then those
commitments that are only meant for their original chain can be reversed
and undone just on the hardfork? Then the users involved would just send an
unroll transaction which is only valid on the hardfork.
- Sent from my phone
Den 17 aug. 2017 14:52 skrev "Conrad Burchert via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
> Some notes:
>
> Hardforks like Bitcoin ABC without a malleability fix are very unlikely to
> have payment channels, so the problem does not exist for those.
>
> The designers of a hardfork which does have a malleability fix will
> probably know about payment channels, so they can just build a replay
> protection that allows the execution of old commitments. That needs some
> kind of timestamping of commitments, which would have to be integrated in
> the channel design. The easiest way would be to just write the time of
> signing the commitment in the transaction and the replay protection accepts
> old commitments, but rejects one's which were signed after the hardfork.
> These timestamps can essentially be one bit (before or after a hardfork)
> and if the replay protection in the hardfork only accepts old commitments
> for something like a year, then it can be reused for more hardforks later
> on. Maybe someone comes up with an interesting way of doing this without
> using space.
>
> Nevertheless hardforking while having channels open will always be a mess
> as an open channel requires you to watch the blockchain. Anybody who is
> just not aware of the hardfork or is updating his client a few days too
> late, can get his money stolen by an old commitment transaction where he
> forgets to retaliate on the new chain. As other's can likely figure out
> your client version the risk of retaliation is not too big for an attacker.
>
>
>
> 2017-08-17 13:31 GMT+02:00 Bryan Bishop via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
>>
>> ---------- Forwarded message ----------
>> From: Christian Decker <decker.christian at gmail.com>
>> Date: Thu, Aug 17, 2017 at 5:39 AM
>> Subject: Re: [Lightning-dev] Lightning in the setting of blockchain
>> hardforks
>> To: Martin Schwarz <martin.schwarz at gmail.com>,
>> lightning-dev at lists.linuxfoundation.org
>>
>>
>> Hi Martin,
>>
>> this is the perfect venue to discuss this, welcome to the mailing list :-)
>> Like you I think that using the first forked block as the forkchain's
>> genesis block is the way to go, keeping the non-forked blockchain on the
>> original genesis hash, to avoid disruption. It may become more difficult in
>> the case one chain doesn't declare itself to be the forked chain.
>>
>> Even more interesting are channels that are open during the fork. In
>> these cases we open a single channel, and will have to settle two. If no
>> replay protection was implemented on the fork, then we can use the last
>> commitment to close the channel (updates should be avoided since they now
>> double any intended effect), if replay protection was implemented then
>> commitments become invalid on the fork, and people will lose money.
>>
>> Fun times ahead :-)
>>
>> Cheers,
>> Christian
>>
>> On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz <martin.schwarz at gmail.com>
>> wrote:
>>
>>> Dear all,
>>>
>>> currently the chain_id allows to distinguish blockchains by the hash of
>>> their genesis block.
>>>
>>> With hardforks branching off of the Bitcoin blockchain, how can
>>> Lightning work on (or across)
>>> distinct, permanent forks of a parent blockchain that share the same
>>> genesis block?
>>>
>>> I suppose changing the definition of chain_id to the hash of the first
>>> block of the new
>>> branch and requiring replay and wipe-out protection should be
>>> sufficient. But can we
>>> relax these requirements? Are slow block times an issue? Can we use
>>> Lightning to transact
>>> on "almost frozen" block chains suffering from a sudden loss of
>>> hashpower?
>>>
>>> Has there been any previous discussion or study of Lightning in the
>>> setting of hardforks?
>>> (Is this the right place to discuss this? If not, where would be the
>>> right place?)
>>>
>>> thanks,
>>> Martin
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>>
>>
>> --
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507 <(512)%20203-0507>
>>
>> _______________________________________________
>> 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/20170817/95edf34c/attachment-0001.html>

2023-06-07 18:00:48

- reply

📅 Original date posted:2017-05-08
📝 Original message:Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
I'll soon present a solution to encourage full nodes to store the
blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS)
Proving that you're holding your own copy of the blockchain, not shared
with other nodes? I don't think that's possible to do securely. It falls on
that the whole blockchain is both public and static, while any such proof
of independence needs to rely on unique capabilities per node.
All you can do with a challenge-response protocol is to prevent honest
nodes from being unwitting backends to dishonest transparent proxy nodes
(by binding the challenge to cryptographic node identities).
Even latency bounding protocols can't stop you from putting multiple
*seemingly independent* nodes in front of the same backend with one single
copy of the blockchain.
I believe best you can do is to force somebody to hold multiple copies
locally on multiple hardware units to not run out of memory I/O when
creating proofs for multiple remote nodes, through using memory heavy
functions for the proof of storage, forcing quick random access. However
somebody willing to put enough RAM in a server rack to hold the full
blockchain could still easily pretend to be multiple regular nodes with
independent copies.
Any kind of attempt at forcing the full copy of the blockchain to be in
memory close to the CPU will either rule out most nodes from passing or
will be cheatable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170508/fd49c403/attachment-0001.html>

2023-06-07 18:00:42

- reply

📅 Original date posted:2017-05-03
📝 Original message:Den 3 maj 2017 16:05 skrev "Erik Aronesty via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
> But as you've observed, the failure probabilities are rather high,
> especially if an active attacker targets nodes carrying less commonly
> available blocks.
Wouldn't the solution be for nodes to use whatever mechanism an attacker
uses to determine less commonly available blocks and choose to store a
random percentage of them as well as their deterministic random set?
IE X blocks end of chain (spv bootstrap), Y% deterministic random set, Z%
patch/fill set to deter attacks
Then he uses Sybil attacks to obscure what's actually rare and not. Even
proof of storage isn't enough, you need proof of INDEPENDENT storage, which
is essentially impossible, as well as a way of determining which nodes are
run by the same people (all the AWS nodes should essentially count as one).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170503/c4844326/attachment.html>

2023-06-07 18:00:30

- reply

📅 Original date posted:2017-04-18
📝 Original message:To expand on this below;
Den 18 apr. 2017 00:34 skrev "Natanael" <natanael.l at gmail.com>:
IMHO the best option if we change PoW is an algorithm that's moderately
processing heavy (we still need reasonably fast verification) and which
resists partial state reuse (not fast or fully "linear" in processing like
SHA256) just for the sake of invalidating asicboost style attacks, and it
should also have an existing reference implementation for hardware that's
provably close in performance to the theoretical ideal implementation of
the algorithm (in other words, one where we know there's no hidden
optimizations).
[...] The competition would mostly be about packing similar gate designs
closely and energy efficiency. (Now that I think about it, the proof MAY
have to consider energy use too, as a larger and slower but more efficient
chip still is competitive in mining...)
What matters for miners in terms of cost is primarily (correctly computed)
hashes per joule (watt-seconds). The most direct proxy for this in terms of
algorithm execution is the number of transistor (gate) activations per
computed hash (PoW unit).
To prove that an implementation is near optimal, you would show there's a
minimum number of necessary transistor activations per computed hash, and
that your implementation is within a reasonable range of that number.
We also need to show that for a practical implementation you can't reuse
much internal state (easiest way is "whitening" the block header,
pre-hashing or having a slow hash with an initial whitening step of its
own). This is to kill any ASICBOOST type optimization. Performance should
be constant, not linear relative to input size.
The PoW step should always be the most expensive part of creating a
complete block candidate! Otherwise it loses part of its meaning. It should
however still also be reasonably easy to verify.
Given that there's already PoW ASIC optimizations since years back that use
deliberately lossy hash computations just because those circuits can run
faster (X% of hashes are computed wrong, but you get Y% more computed
hashes in return which exceeds the error rate), any proof of an
implementation being near optimal (for mining) must also consider the
possibility of implementations of a design that deliberately allows errors
just to reduce the total count of transistor activations per N amount of
computed hashes. Yes, that means the reference implementation is allowed to
be lossy.
So for a reasonably large N (number of computed hashes, to take batch
processing into consideration), the proof would show that there's a
specific ratio for a minimum number of average gate activations per
correctly computed hash, a smallest ratio = X number of gate activations /
(N * success rate) across all possible implementations of the algorithm.
And you'd show your implementation is close to that ratio.
It would also have to consider a reasonable range of time-memory tradeoffs
including the potential of precomputation. Hopefully we could implement an
algorithm that effectively makes such precomputation meaningless by making
the potential gain insignificant for any reasonable ASIC chip size and
amount of precomputation resources.
A summary of important mining PoW algorithm properties;
* Constant verification speed, reasonably fast even on slow hardware
* As explained above, still slow / expensive enough to dominate the costs
of block candidate creation
* Difficulty must be easy to adjust (no problem for simple hash-style
algorithms like today)
* Cryptographic strength, something like preimage resistance (the algorithm
can't allow forcing a particular output, the chance must not be better than
random within any achievable computational bounds)
* As explained above, no hidden shortcuts. Everybody has equal knowledge.
* Predictable and close to constant PoW computation performance, and not
linear in performance relative to input size the way SHA256 is (lossy
implementations will always make it not-quite-constant)
* As explained above, no significant reusable state or other reusable work
(killing ASICBOOST)
* As explained above, no meaningful precomputation possible. No unfair
headstarts.
* Should only rely on just transistors for implementation, shouldn't rely
on memory or other components due to unknowable future engineering results
and changes in cost
* Reasonably compact implementation, measured in memory use, CPU load and
similar metrics
* Reasonably small inputs and outputs (in line with regular hashes)
* All mining PoW should be "embarrassingly parallel" (highly
parallellizable) with minimal or no gain from batch computation,
performance scaling should be linear with increased chip size & cycle
speed.
What else is there? Did I miss anything important?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170418/64d7218b/attachment-0001.html>

2023-06-07 18:00:16

- reply

📅 Original date posted:2017-04-17
📝 Original message:Den 17 apr. 2017 16:14 skrev "Erik Aronesty via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
It's too bad we can't make the POW somehow dynamic so that any specialized
hardware is impossible, and only GPU / FPGA is possible.
Maybe a variant of Keccak where the size of the sponge is increased along
with additional zero bits required. Seems like this would either have to
resist specialized hardware or imply sha3 is compromised such that the size
of the sponge does not incerase the number of possible output bits as
expected.
Technically SHA3 (keccak) already has the SHAKE mode, an extensible output
function (XOF). It's basically a hash with arbitary output length (with
fixed state size, 256 bits is the common choice). A little bit like hooking
a hash straight into a stream cipher.
The other modes should *probably* not allow the same behavior, though. I
can't guarantee that however.
You may be interested in looking at parameterizable ciphers and if any of
them might be applicable to PoW.
IMHO the best option if we change PoW is an algorithm that's moderately
processing heavy (we still need reasonably fast verification) and which
resists partial state reuse (not fast or fully "linear" in processing like
SHA256) just for the sake of invalidating asicboost style attacks, and it
should also have an existing reference implementation for hardware that's
provably close in performance to the theoretical ideal implementation of
the algorithm (in other words, one where we know there's no hidden
optimizations).
Anything relying on memory or other such expensive components is likely to
fall flat eventually as fast memory is made more compact, cheaper and moves
closer to the cores.
That should be approximately what it takes to level out the playing field
in ASIC manufacturing, because then we would know there's no fancy tricks
to deploy that would give one player unfair advantage. The competition
would mostly be about packing similar gate designs closely and energy
efficiency. (Now that I think about it, the proof MAY have to consider
energy use too, as a larger and slower but more efficient chip still is
competitive in mining...)
We should also put a larger nonce in the header if possible, to reduce the
incentive to mess with the entropy elsewhere in blocks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170418/d2274892/attachment-0001.html>

2023-06-07 18:00:09

- reply

📅 Original date posted:2017-04-15
📝 Original message:Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
Not sure if you missed my previous reply to you, but I'm curious about
your thoughts on this particular point. I contend that for any UASF,
orphaning non-signalling blocks on the flag date is [maybe] safer [for
those in on the UASF fork] than just
considering the fork active on the flag date.
Note my additions.
Enforcement by orphaning non-compliance makes it harder to reverse a buggy
softfork, since you necessarily increase the effort needed to return enough
mining power to the safe chain since you now have mostly unmonitored mining
hardware fighting you actively, whose operators you might not be able to
contact. You'd practically have to hardfork out of the situation.
There's also the risk of the activation itself triggering concensus bugs
(multiple incompatible UASF forks), if there's multiple implementations of
it in the network (or one buggy one). We have already seen something like
it happen. This can both happen on the miner side, client side or both
(miner side only would lead to a ton of orphaned blocks, client side means
netsplit).
It is also not economically favorable for any individual miner to be the
one to mine empty blocks on top of any surviving softfork-incompatible
chain. As a miner you would only volunteer to do it if you believe the
softfork is necessary or itself will enable greater future profit.
Besides that, I also just don't believe that UASF itself as a method to
activate softforks is a good choice. The only two reliable signals we have
for this purpose in Bitcoin are block height (flag day) and standard miner
signaling, as every other metric can be falsified or gamed.
But there's also more problems - a big one is that we have no way right now
for a node to tell another "the transaction you just relayed to me is
invalid according to an active softfork" (or "will become invalid". This
matters for several reasons.
The first one that came to my mind is that we have widespread usage of
zero-confirmation payments in the network.
This was already dangerous for other reasons, but this UASF could make it
guaranteed cost-free to exploit - because as many also know, we ALSO
already have a lot of nodes that do not enforce the non-default rejection
policies (otherwise we'd never see such transactions on blocks), including
many alternative Bitcoin clients.
The combination of these factors means that you can present an UASF invalid
transaction to a non-updated client that is supposedly protected by the
deliberate orphaning effort, and have it accept this as a payment. To never
see it get confirmed, or to eventually see it doublespent by an UASF-valid
transaction.
I would not at all be surprised if it turned out that many
zero-confirmation accepting services do not reject non-default
transactions, or if they aren't all UASF-segwit aware.
This is why a flag day or similar is more effective - it can't be ignored
unlike "just another one of those UASF proposals" that you might not have
evaluated or not expect to activate.
This is by the way also a reason that I believe that all nodes and services
should publish all concensus critical policies that they enforce. This
would make it far easier to alert somebody that they NEED TO prepare for
whatever proposal that might conflict with their active policies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170415/31ad5f51/attachment.html>

2023-06-07 17:58:50

- reply

📅 Original date posted:2017-04-01
📝 Original message:Den 1 apr. 2017 16:07 skrev "Jorge Timón" <jtimon at jtimon.cc>:
On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanael.l at gmail.com> wrote:
>
>
> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org>:
>
> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>
>
> That would make it a hardfork, not a softfork, if done exactly as you say.
>
> Segwit only separates out signature data. The 1 MB limit remains, but
would
> now only cover the contents of the transaction scripts. With segwit that
> means we have two (2) size limits, not one. This is important to remember.
> Even with segwit + MAST for large complex scripts, there's still going to
be
> a very low limit to the total number of possible transactions per block.
And
> not all transactions will get the same space savings.
No, because of the way the weight is calculated, it is impossible to
create a block that old nodes would perceive as bigger than 1 mb
without also violating the weight limit.
After segwit activation, nodes supporting segwit don't need to
validate the 1 mb size limit anymore as long as they validate the
weight limit.
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size
Huh, that's odd. It really does still count raw blockchain data blocksize.
It just uses a ratio between how many units each byte is worth for block
data vs signature data, plus a cap to define the maximum. So the current
max is 4 MB, with 1 MB of non-witness blockchain data being weighted to 4x
= 4 MB. That just means you replaced the two limits with one limit and a
ratio.
A hardfork increasing the size would likely have the ratio modified too.
With exactly the same effect as if it was two limits...
Either way, there's still going to be non-segwit nodes for ages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170401/831f0f43/attachment-0001.html>

2023-06-07 17:58:50

- reply

📅 Original date posted:2017-04-02
📝 Original message:My point, if you missed it, is that there's a mathematical equivalence
between using two limits (and calculating the ratio) vs using one limit and
a ratio. The output is fully identical. The only difference is the order of
operations. Saying there's no blocksize limit with this is pretty
meaningless, because you're just saying you're using an abstraction that
doesn't make the limit visible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170402/11f9c875/attachment.html>

2023-06-07 17:58:49

- reply

📅 Original date posted:2017-04-01
📝 Original message:Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
That would make it a hardfork, not a softfork, if done exactly as you say.
Segwit only separates out signature data. The 1 MB limit remains, but would
now only cover the contents of the transaction scripts. With segwit that
means we have two (2) size limits, not one. This is important to remember.
Even with segwit + MAST for large complex scripts, there's still going to
be a very low limit to the total number of possible transactions per block.
And not all transactions will get the same space savings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170401/a30e2efd/attachment.html>

2023-06-07 17:58:42

- reply

📅 Original date posted:2017-04-01
📝 Original message:Den 1 apr. 2017 01:13 skrev "Eric Voskuil via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote:
> If the obsession with every personal computer being able to run a
> fill node continues then bitcoin will be consigned to the dustbin
> of history,
The cause of the block size debate is the failure to understand the
Bitcoin security model. This failure is perfectly exemplified by the
above statement. If a typical personal computer cannot run a node
there is no security.
If you're capable of running and trusting your own node chances are you
already have something better than a typical personal computer!
And those who don't have it themselves likely know where they can run or
access a node they can trust.
If you're expecting average joe to trust the likely not updated node on his
old unpatched computer full of viruses, you're going to have a bad time.
The real solution is to find ways to reduce the required trust in a
practical manner.
Using lightweight clients with multiple servers have already been
mentioned, Zero-knowledge proofs (if the can be made practical and stay
secure...) is another obvious future tool, and hardware wallets helps
against malware.
If you truly want everybody to run their own full nodes, the only plausible
solution is managed hardware in the style of Chromebooks, except that you
could pick your own distribution and software repository. Meaning you're
still trusting the exact same people whose nodes you would otherwise rely
on, except now you're mirroring their nodes on your own hardware instead.
Which at most improves auditability.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170401/d37e06c6/attachment-0001.html>

2023-06-07 17:58:42

- reply

📅 Original date posted:2017-04-01
📝 Original message:Den 1 apr. 2017 16:35 skrev "Eric Voskuil via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/31/2017 11:18 PM, Jared Lee Richardson wrote:
>> If a typical personal computer cannot run a node there is no
>> security.
>
> If you can't describe an attack that is made possible when typical
> personal computers can't run nodes, this kind of logic has no place
> in this discussion.
"Governments are good at cutting off the heads of a centrally
controlled networks..."
That's what's so great about Bitcoin. The blockchain is the same
everywhere.
So if you can connect to private peers in several jurisdictions, chances
are they won't all be lying to you in the exact same way. Which is what
they would need to do to fool you.
If you run your own and can't protect it, they'll just hack your node and
make it lie to you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170401/7833b665/attachment.html>

2023-06-07 17:58:32

- reply

📅 Original date posted:2017-03-30
📝 Original message:Den 30 mars 2017 12:04 skrev "Luke Dashjr" <luke at dashjr.org>:
I don't see a purpose to this proposal. Miners always mine as if it's their
*only* chance to get the fee, because if they don't, another miner will. Ie,
after 1 block, the fee effectively drops to 0 already.
I believe that with correctly configured incentives, you can make it more
profitable to delay some transactions with lower fees but still include
them in the next block then to include them all at once. This would smooth
out the inclusion of transactions.
This may require changing the difficulty scaling from using a simple
logarithm to a function that first behaves like a logarithm up to some
multiple of the standard block size, after which difficulty starts
increasing faster and reaches a greater-than-linear ratio in expected
required hash per mined bit. Perhaps tipping over at around a blocksize 3x
the standard blocksize. Since the standard blocksize increases with
continous load after retargeting, the blocksize at which this happens also
increases.
Also, together with the above the fee pool does slightly counteract what
you say, as they'll get a share via the pool when there's less transactions
available the next time they create a block (like insurance).
For a user, what's the incentive to pay an individual miner the fee
directly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/ccbd4893/attachment.html>

2023-06-07 17:58:32

- reply

📅 Original date posted:2017-03-31
📝 Original message:Sorry for sending a double, hit the wrong button...
Den 31 mars 2017 06:14 skrev "Natanael" <natanael.l at gmail.com>:
>
>
> Den 30 mars 2017 11:34 skrev "Natanael" <natanael.l at gmail.com>:
>
> Block size dependent difficulty scaling. Hardfork required.
>
> Larger blocks means greater difficulty - but it doesn't scale linearly,
> rather a little less than linearly. That means miners can take a penalty in
> difficulty to claim a greater number of high fee transactions in the same
> amount of time (effectively increasing "block size bitrate"), increasing
> their profits. When such profitable fees aren't available, they have to
> reduce block size.
>
> In other words, the users literally pay miners to increase block size (or
> don't pay, which reduces it).
>
>
> This can be simplified if we do get a fee pool (less hardfork code, more
> softfork code), except that the effect will be partially reduced by the
> mining subsidy until it approximately reaches parity with average total
> fees.
>
> We don't need to alter difficulty calculation.
> Instead we alter the percentage of the fees that the miner gets to claim
> VS what he have to donate to the pool based on the size of the block he
> generated.
> Larger block = smaller percentage of fees. This is another way to pay for
> blocksize. The effect of this is that on average, miners that generate
> smaller blocks takes a share of what otherwise would be part of the mining
> profits of those generating larger blocks.
>
> We would need to keep pieces of the section from above on expected
> blocksize calculation. Because the closer you are to the expected
> blocksize, the more you keep. And thus we need to adjust it according to
> usage.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/19564c56/attachment.html>

2023-06-07 17:58:32

- reply

📅 Original date posted:2017-03-30
📝 Original message:Den 30 mars 2017 11:34 skrev "Natanael" <natanael.l at gmail.com>:
Block size dependent difficulty scaling. Hardfork required.
Larger blocks means greater difficulty - but it doesn't scale linearly,
rather a little less than linearly. That means miners can take a penalty in
difficulty to claim a greater number of high fee transactions in the same
amount of time (effectively increasing "block size bitrate"), increasing
their profits. When such profitable fees aren't available, they have to
reduce block size.
In other words, the users literally pay miners to increase block size (or
don't pay, which reduces it).
This can be simplified if we do get a fee pool (less hardfork code, more
softfork code), except that the effect will be partially reduced by the
mining subsidy until it approximately reaches parity with average total
fees.
We don't need to alter difficulty calculation.
Instead we alter the percentage of the fees that the miner gets to claim VS
what he have to donate to the pool based on the size of the block he
generated.
Larger block = smaller percentage of fees. This is another way to pay for
blocksize. The effect of this is that on average, miners that generate
smaller blocks takes a share of what otherwise would be part of the mining
profits of those generating larger blocks.
We would need to keep pieces of the section from above on expected
blocksize calculation. Because the closer you are to the expected
blocksize, the more you keep. And thus we need to adjust it according to
usage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/051be6af/attachment.html>

2023-06-07 17:58:32

- reply

📅 Original date posted:2017-03-31
📝 Original message:Den 30 mars 2017 11:34 skrev "Natanael" <natanael.l at gmail.com>:
Block size dependent difficulty scaling. Hardfork required.
Larger blocks means greater difficulty - but it doesn't scale linearly,
rather a little less than linearly. That means miners can take a penalty in
difficulty to claim a greater number of high fee transactions in the same
amount of time (effectively increasing "block size bitrate"), increasing
their profits. When such profitable fees aren't available, they have to
reduce block size.
In other words, the users literally pay miners to increase block size (or
don't pay, which reduces it).
This can be simplified if we do get a fee pool (less hardfork code, more
softfork code), except that the effect will be partially reduced by the
mining subsidy until it approximately reaches parity with average total
fees.
We don't need to alter difficulty calculation.
Instead we alter the percentage of the fees that the miner gets to claim VS
what he have to donate to the pool based on the size of the block he
generated.
Larger block = smaller percentage of fees. This is another way to pay for
blocksize. The effect of this is that on average, miners that generate
smaller blocks takes a share of what otherwise would be part of the mining
profits of those generating larger blocks.
We would need to keep pieces of the section from above on expected
blocksize calculation. Because the closer you are to the expected
blocksize, the more you keep. And thus we need to adjust it according to
usage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/507bf8de/attachment-0001.html>

2023-06-07 17:58:31

- reply

📅 Original date posted:2017-03-30
📝 Original message:I had these following ideas as I was thinking about how to allow larger
blocks without incentivizing the creation of excessively large blocks. I
don't know how much of this is novel, I'd appreciate if anybody could link
to any relevant prior art. I'm making no claims on this, anything novel in
here is directly released into public domain.
In short, I'm trying to rely on simple but direct incentives to improve the
behavior of Bitcoin.
Feedback requested. Some simulations requested, see below if you're willing
to help. Any questions are welcome.
---
Expedience fees. Softfork compatible.
You want to really make sure your transaction gets processed quickly?
Transactions could have a second fee type, a specially labeled
anyone-can-spend output with an op_return value defining a "best-before"
block number and some function describing the decline of the fee value for
every future block, such that before block N the miners can claim the full
expedience fee + the standard fee (if any), between block N+1 and N+X the
miner can claim a reduced expedience fee + standard fee, afterwards only
the standard fee.
When a transaction is processed late such that not the full expedience fee
can be claimed, the remainder of the expedience fee output is returned to
the specified address among the inputs/outputs (could be something like
in#3 for the address used by the 3rd UTXO input). This would have to be
done for all remaining expedience fees within the last transaction in the
block, inserted there by the miner.
These additional UTXO:s does increase overhead somewhat, but hopefully not
by too much. If we're going to modify the transaction syntax eventually,
then we could take the chance to design for this to reduce overhead.
My current best idea for how to handle returned expedience fees in
multiuser transactions (coinjoin, etc) is to donate it to an agreed upon
address. For recurring donation addresses (the fee pool included!), this
reduces the number of return UTXO:s in the fee processing transaction.
The default client policy may be to split the entire fee across an
expedience fee and a fee pool donation, where the donation part becomes
larger the later the transaction gets processed. This is expected to slow
down the average inclusion speed of already delayed transactions, but they
remain profitable to include.
The dynamics here is simple, a miner is incentivized to process a
transaction with an expedience fee before a standard fee of the same
value-per-bit in order to not reduce the total value of the available fees
of all standing transactions they can process. The longer they wait, the
less total fees available.
Sidenote: a steady stream of expedience fees reduces the profitability of
block withholding attacks (!), at some threshold it should make it entirely
unprofitable vs standard mining. This is due to the increased risk of
losing valuable expedience fees added after you finished your first block
(as the available value will be reduced in your block #2, vs what other
miners can claim while still mining on that previous block).
(Can somebody verify this with simulations?)
---
Fee pool. Softfork compatible.
We want to smooth out fee payments too for the future when the subsidy
drops, to prevent deliberate forking to steal fees. We can introduce a
designated P2SH anyone-can-spend fee pool address. The miner can never
claim the full fees from his block or claim the full amount in the pool,
only some percentage of both. The remainder goes back into the pool (this
might be done at the end of the same expedience fee processing transaction
described above). Anybody can deliberately pay to the pool.
The fee pool is intended to act as a "buffer" such that it remains
profitable to not try to steal fees but to just mine normally, even during
relatively extreme fee value variance (consider the end of a big
international shopping weekend).
The fee value claimed by the miners between blocks is allowed to vary, but
we want to avoid order-of-magnitude size variation (10x). We do however
want the effect of expedience fees to have an impact. Perhaps some
logarithmic function can smooth it out? Forcing larger fees to be
distributed over longer time periods?
---
Block size dependent difficulty scaling. Hardfork required.
Larger blocks means greater difficulty - but it doesn't scale linearly,
rather a little less than linearly. That means miners can take a penalty in
difficulty to claim a greater number of high fee transactions in the same
amount of time (effectively increasing "block size bitrate"), increasing
their profits. When such profitable fees aren't available, they have to
reduce block size.
In other words, the users literally pay miners to increase block size (or
don't pay, which reduces it).
(Sidenote: I am in favor of combining this with the idea of a 32 MB max
blocksize (or larger), with softforked scheduled lower size caps (perhaps
starting at 4 MB max) that grows according to a schedule. This reduces the
risk of rapidly increasing load before we have functional second layer
scaling in place.)
In order for a miner to profit from adding additional transactions, their
fees must exceed the calculated cost of the resulting difficulty penalty to
make it worth it to create a larger block. Such loads are expected during
international shopping weekends.
With only a few available high value transactions the incentive becomes the
reverse, to create a smaller block with lower difficulty to faster claim
those fees.
To keep the average 10 minute block rate and to let this mechanism shift
the "block size bitrate" as according to the fee justified block size
changes, we set an Expected blocksize value that changes over time, and we
change the difficulty target into the Standard difficulty target, where
each block must reach a Scaled difficulty target .
In terms of math we do something like this:
Scaled difficulty = Standard difficulty * f(blocksize), where f would
likely be some logarithmic function, and blocksize is defined in terms of
units of Expected blocksize (a block 1.5x larger than Expected blocksize
gets a value of 1.5).
When we retarget the Standard difficulty and Expected blocksize we do this:
Standard difficulty = Network hashrate per 10 minutes (approximately same
as before, but now we take the Scaled difficulty of the last period's
previous blocks into consideration)
Standard blocksize = Recent average effective block bitrate = (sum of
recent (weighted!) block sizes / length of timeperiod) / number of blocks
in a retargeting period.
Thus, generating larger blocks drives up the long term standard block
bitrate, smaller blocks reduces it, in both cases we strive to average 1
block per 10 minutes.
Combining this with expedience fees makes it even more effective;
There's always a cutoff for where a miner stops including unprocessed
transactions and let the rest remain for the next block. For standard fees,
this would result in a fairly static block size and transactions backlog.
With expedience fees your transaction can bypass standard fees with same
value-per-bit, as explained above, because otherwise the miners reduces the
value of their future expected fees. The more people that do this, the
greater incentive to not delay transactions and instead increase the
blocksize. (Can somebody help with the math here? I want simulations of
this.)
(Sidenote: I'm in favor of RBF, replace-by-fee. This makes the above work
much more smoothly. Anybody relying on the security of unconfirmed
transactions for any significant value *have to* rely on some kind of
incentive protected multisignature transaction, including LN type second
layer schemes. The other option is just not secure.)
If load is low then you can add a high expedience fee to incentivize the
creation of a smaller block with your transaction, since difficulty will be
reduced for the smaller block. This means the miner has a higher chance of
beating the competition. Adding additional lower fee transactions may
reduce his average value-per-bit to become less profitable.
Miners simply aim to maximize their fees-per-bit, while also paying as
little as possible in mining costs.
To make this work as intended for those willing to explicitly pay to reduce
block size, one could tag such an expedience fee with a maximum allowed
blocksize (where the fee will be claimed in such a smaller block if it is
the more profitable option), such that it won't be countered by others
making more high expedience fees to increase blocksize. Note: I'm not
particularly in favor of this idea, just mentioning the possibility.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/823b7763/attachment.html>

2023-06-07 17:56:00

- reply

📅 Original date posted:2017-02-05
📝 Original message:Den 5 feb. 2017 16:33 skrev "John Hardy via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
Currently in order to signal support for changes to Bitcoin, only miners
are able to do so on the blockchain through BIP9.
One criticism is that the rest of the community is not able to participate
in consensus, and other methods of assessing community support are fuzzy
and easily manipulated through Sybil.
I was trying to think if there was a way community support could be
signaled through transactions without requiring a hard fork, and without
increasing the size of transactions at all.
My solution is basically inspired by hashcash and vanity addresses
Censorship by miners isn't the only problem. Existing and normal
transactions will probabilistically collide with these schemes, and most
wallets have no straightforward way of supporting it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170205/019c529b/attachment-0001.html>

2023-06-07 17:55:50

- reply

📅 Original date posted:2017-01-28
📝 Original message:Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
Satoshi envisioned a system where full nodes could publish proofs of invalid
blocks that would be automatically verified by SPV nodes and used to ensure
even they maintained the equivalent of full node security so long as they
were
not isolated. But as a matter of fact, this vision has proven impossible,
and
there is to date no viable theory on how it might be fixed. As a result, the
only way for nodes to have full-node-security is to actually be a true full
node, and therefore the plan of only having full nodes in datacenters is
simply not realistic without transforming Bitcoin into a centralised system.
Beside Zero-knowledge proofs, which is capable of proving much so more than
just validity, there are multi types of fraud proofs that only rely on the
format of the blocks. Such as publishing the block header + the two
colliding transactions included in it (in the case of double spending), or
if the syntax or logic is broken then you just publish that single
transaction.
There aren't all that many cases where fraud proofs are unreasonably large
for a networked system like in Bitcoin. If Zero-knowledge proofs can be
applied securely, then I can't think of any exceptions at all for when the
proofs would be unmanageable. (Remember that full Zero-knowledge proofs can
be chained together!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170128/faab5c67/attachment.html>

2023-06-07 17:55:39

- reply

📅 Original date posted:2017-01-25
📝 Original message:Den 25 jan. 2017 08:22 skrev "Johnson Lau" <jl2012 at xbt.hk>:
Assuming Alice is paying Bob with an old style time-locked tx. Under your
proposal, after the hardfork, Bob is still able to confirm the time-locked
tx on both networks. To fulfil your new rules he just needs to send the
outputs to himself again (with different tx format). But as Bob gets all
the money on both forks, it is already a successful replay
Why would Alice be sitting on an old-style signed transaction with UTXO:s
none of which she controls (paying somebody else), with NO ability to
substitute the transaction for one where she DOES control an output,
leaving her unable to be the one spending the replay protecting child
transaction?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170125/3a1d6361/attachment.html>

2023-06-07 17:55:38

- reply

📅 Original date posted:2017-01-24
📝 Original message:Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
B. For transactions created before this proposal is made, they are not
protected from anti-replay. The new fork has to accept these transactions,
as there is no guarantee that the existing fork would survive nor maintain
any value. People made time-locked transactions in anticipation that they
would be accepted later. In order to maximise the value of such
transactions, the only way is to make them accepted by any potential
hardforks.
This can be fixed.
Make old-format transactions valid *only when paired with a fork-only
follow-up transaction* which is spending at least one (or all) of the
outputs of the old-format transaction.
(Yes, I know this introduces new statefulness into the block validation
logic. Unfortunately it is necessary for maximal fork safety. It can be
disabled at a later time if ever deemed no longer necessary.)
Meanwhile, the old network SHOULD soft-fork in an identical rule with a
follow-up transaction format incompatible with the fork.
This means that old transactions can not be replayed across forks/networks,
because they're not valid when stand-alone. It also means that all wallet
clients either needs to be updated OR paired with software that intercepts
generated transactions, and automatically generates the correct follow-up
transaction for it (old network only).
The rules should be that old-format transactions can't reference new-format
transactions, even if only a softfork change differ between the formats.
This prevents an unnecessary amount of transactions pairs generated by old
wallets. Thus they can spend old outputs, but not spend new ones.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170125/48d948aa/attachment.html>

2023-06-07 17:55:38

- reply

📅 Original date posted:2017-01-25
📝 Original message:Den 25 jan. 2017 08:06 skrev "Johnson Lau" <jl2012 at xbt.hk>:
What you describe is not a fix of replay attack. By confirming the same tx
in both network, the tx has been already replayed. Their child txs do not
matter.
Read it again.
The validation algorithm would be extended so that the transaction can't be
replayed, because replaying it in the other network REQUIRES a child
transaction in the same block that is valid, a child transaction the is
unique to the network. By doing this policy change simultaneously in both
networks, old pre-signed transactions *can not be replayed by anybody but
the owner* of the coins (as he must spend them immediately in the child
transaction).
It means that as soon as spent, the UTXO sets immediately and irrevocably
diverges across the two networks. Which is the entire point, isn't it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170125/14eae723/attachment.html>

2023-06-07 17:53:52

- reply

📅 Original date posted:2016-10-11
📝 Original message:Den 12 okt. 2016 01:33 skrev "John Hardy via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
> Sidechains seem an inevitable tool for scaling. They allow Bitcoins to be
transferred from the main blockchain into external blockchains, of which
there can be any number with radically different approaches.
>
> In current thinking I have encountered, sidechains are isolated from each
other. To move Bitcoin between them would involve a slow transfer back to
the mainchain, and then out again to a different sidechain.
>
> Could we instead create a protocol for addressable blockchains, all using
a shared proof of work, which effectively acts as an Internet of
Blockchains?
More of a treechain / clusterchain, then?
> Instead of transferring Bitcoin into individual sidechains, you move them
into the master sidechain, which I'll call Angel. The Angel blockchain sits
at the top of of a tree of blockchains, each of which can have radically
different properties, but are all able to transfer Bitcoin and data between
each other using a standardised protocol.
>
> Each blockchain has its own address, much like an IP address. The Angel
blockchain acts as a registrar, a public record of every blockchain and its
properties. Creating a blockchain is as simple as getting a
createBlockchain transaction included in an Angel block, with details of
parameters such as block creation time, block size limit, etc. A
decentralised DNS of sorts.
>
> Mining in Angel uses a standardised format, creating hashes which allow
all different blockchains to contribute to the same Angel proof of work.
Miners must hash the address of the blockchain they are mining, and if they
mine a hash of sufficient difficulty for that blockchain they are able to
create a block.
>
> Blockchains can have child blockchains, so a child of Angel might have
the address aa9, and a child of aa9 might have the address aa9:e4d. The
lower down the tree you go, the lower the security, but the lower the
transaction fees. If a miner on a lower level produces a hash of sufficient
difficulty, they can use it on any parents, up to and including the Angel
blockchain, and claim fees on each.
>
> Children always synchronise and follow all parents (and their
reorganisations), and parents are aware of their children. This allows you
to do some pretty cool things with security. If a child tries to withdraw
to a parent after spending on the child (a double spend attempt) this will
be visible instantly, and all child nodes will immediately be able to
broadcast proof of the double spend to parent chain nodes so they do not
mine on those blocks. This effectively means children can inherit a level
of security from their parents without the same PoW difficulty.
>
> There are so many conflicting visions for how to scale Bitcoin. Angel
allows the free market to decide which approaches are successful, and for
complementary blockchains with different use cases, such as privacy, high
transaction volume, and Turing completeness to more seamlessly exist
alongside each other, using Bitcoin as the standard medium of exchange.
>
> I wrote this as a TLDR summary for a (still evolving) idea I had on the
best approach to scale Bitcoin infinitely. I've written more of my thoughts
on the idea at
https://seebitcoin.com/2016/09/introducing-buzz-a-turing-complete-concept-for-scaling-bitcoin-to-infinity-and-beyond/
>
> Does anybody think this would be a better, more efficient way of
implementing sidechains? It allows infinite scaling, and standardisation
allows better pooling of resources.
I've got a similar idea since quite a while back, but I've never really
written it down in full. Here one link:
http://www.metzdowd.com/pipermail/cryptography/2015-January/024338.html
Some thoughts on how to design it;
The basic idea is to compress the validation data maximally, and yet
achieve Turing completeness for an arbitary number of interacting chains,
or "namespaces".
The whole thing is checkpointed and uses Zero-knowledge proofs to enable
secure pruning, making it essentially a rolling blockchain with complete
preservation of history. It grows approximately linearly with
non-deprecated state.
This latest checkpoint's header + the following headers and accompanying
Zero-knowledge proofs would together act as the root for the system.
Having that is all you would need to confirm that any particular piece of
data from the blockchain is correct, given that it comes with enough
metadata to trace it all the way to the root. (Merkle tree hashes, ZKP:s,
etc).
Every chain would be registered under a unique name (the root chain would
essentially just deal with registering chain names + their rules), and
would define its own external API towards other chains, and it would define
its own rules for how its data can be updated and when. Every single
interaction with a chain is done by an atomic program (transaction), and
all sets of validated changes must be conflict-free (especially across
chains). Everything would practically be composed of a hierarchy of
interacting programs.
Every set of programs (transactions) can be transformed into a "diff" on
the blockchain state plus an accompanying Zero-knowledge proof. The proofs
can even be chained, such that groups of users of one chain can create a
proof for their own changes, submit it to some chain coordinator who does
another compressing merge and proof generation, to then send it to the
miners who merges the collective changes for all chains and generates a
proof for the root.
Obviously that validation can get inefficient if many chains interact, as
you can't simply just look for conflicting UTXO:s in programs (unless the
chain designers are *really* smart with their conflict resolution
mechanisms). Either you have to use programmatic locking, very slow block
rates or chose to not guarantee that any particular action has succeeded
(essentially turning validated programs (transactions) into *requests* to
the API up towards the root, to eventually be resolved later with responses
propagated back down, instead of having them be direct changes to the
state).
The latter option requires a lot more interaction by the client to get the
intended behavior in many circumstances. The first two can both kill
performance (nobody wants small programs with a few round-trips to take a
week to execute).
I really do hope it can be resolved effectively. I'm guessing some serious
restrictions on the API:s would be necessary. You would want most programs
to be provably independent (such as not accessing the same resources) to be
able to easily just create a small checkpoint of the global state and
generate a proof for it. Programs simultaneously accessing resources that
don't guarantee commutativity for all actions would likely be to be rate
limited.
Best case scenario: some genius manages to create the equivalent of
Lightning Network (with in-chain arbitration authority assigned to chosen
servers in the chain definitions, and cross-chain negotiation between those
authorities when programs use the API) for processing the programs in near
real-time, and quickly settling on what changes to commit to the root.
Programs would practically need to be designed to be networked
(multi-stage) so that the servers can let them negotiate over their API:s
across all chains, until the server has a complete set of changes without
conflicts to commit to the root.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161012/303bc6d5/attachment-0001.html>

2023-06-07 17:49:27

- reply

📅 Original date posted:2016-03-02
📝 Original message:To say that Bitcoin is strongly consistent is to say that the memory pool
and the last X blocks aren't part of Bitcoin. If you want to avoid making
that claim, you can at best argue that Bitcoin has both a strongly
consistent component AND an eventually consistent component.
The entire point of the definition of eventually consistency is that your
computer system is running continously and DO NOT have a final state, and
therefore you must be able to describe the behavior when your system either
may give responses to queries across time that are either perfectly
consistent *or not* perfectly consistent.
And Bitcoin by default *does not* ignore the contents of the last X blocks.
A Bitcoin node being queried about the current blockchain state WILL give
inconsistent answers when there's block rearrangements = no strong
consistency. Not to mention that your definition ignores the nonzero
probability of a block rearrangement extending beyond your constant omega.
Bitcoin provides a probabilistic, accumulative probability. Not a perfect
one.
Den 2 mar 2016 04:04 skrev "Emin Gün Sirer" <
bitcoin-dev at lists.linuxfoundation.org>:
>
> There seems to be a perception out there that Bitcoin is eventually
> consistent. I wrote this post to describe why this perception is completely
> false.
>
> Bitcoin Guarantees Strong, not Eventual, Consistency
>
> http://hackingdistributed.com/2016/03/01/bitcoin-guarantees-strong-not-eventual-consistency/
>
> I hope we can lay this bad meme to rest. Bitcoin provides a strong
> guarantee.
> - egs
>
>
> _______________________________________________
> 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/20160302/2d24eda8/attachment.html>

2023-06-07 17:47:11

- reply

📅 Original date posted:2015-12-20
📝 Original message:Wouldn't block withhold be fixed by not letting miners in pools know which
block candidates are valid before the pool knows? (Note: I haven't read any
other proposals for how to fix it, this may already be known)
As an example, by having the pool use the unique per-miner nonces sent to
each miner for effective division of labor as a kind of seed / commitment
value, where one in X block candidates will be valid, where X is the
current ratio between partial PoW blocks sent as mining proofs and the full
difficulty?
The computational work of the pool remains low (checking this isn't harder
than the partial PoW validation already performed), they pool simply looks
at which commitment value from the pool that the miner used, looks up the
correct committed value and hashes that together with the partial PoW. If
it hits the target, the block is valid.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/1fa589e5/attachment.html>

2023-06-07 17:47:01

- reply

📅 Original date posted:2015-12-20
📝 Original message:Den 20 dec 2015 12:38 skrev "Tier Nolan via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
>
> On Sun, Dec 20, 2015 at 5:12 AM, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> An attacker pool (A) can take a certain portion of its hashpower,
>> use it to mine on behalf of victim pool (B), furnish partial proofs of
work
>> to B, but discard any full blocks it discovers.
>
> I wonder if part of the problem here is that there is no pool identity
linked to mining pools.
>
> If the mining protocols were altered so that miners had to indicate their
identity, then a pool couldn't forward hashing power to their victim.
Our approaches can be combined.
Each pool (or solo miner) has a public key included in their blocks that
identifies them to their miners (solo miners can use their own unique
random keys every time). This public key may be registered with DNSSEC+DANE
and the pool could point to their domain in the block template as an
identifier.
For each block the pool generates a nonce, and for each of every miner's
workers it double-hashes that nonce with their own public key and that
miner's worker ID and the previous block hash (to ensure no accidental
overlapping work is done).
The double-hash is a commitment hash, the first hash is the committed value
to be used by the pool as described below. Publishing the nonce reveals how
the hashes were derived to their miners.
Each miner puts this commitment hash in their blocks, and also the public
key of the pool separately as mentioned above.
Here's where it differs from standard mining: both the candidate block PoW
hash and the pool's commitment value above determines block validity
together.
If total difficulty is X and the ratio for full blocks to candidate blocks
shared with the pool is Y, then the candidate block PoW now has to meet X/Y
while hashing the candidate block PoW + the pool's commitment hash must
meet Y, which together makes for X/Y*Y and thus the same total difficulty.
So now miners don't know if their blocks are valid before the pool does, so
withholding isn't effective, and the public key identifiers simultaneously
stops a pool from telling honest but naive miners to attack other pools
using whatever other schemes one might come up with.
The main differences are that there's a public key identifier the miners
are told about in advance and expect to see in block templates, and that
that now the pool has to publish this commitment value together with the
block that also contains the commitment hash, and that this is verified
together with the PoW.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/f952cf21/attachment.html>

2023-06-07 17:39:04

- reply

📅 Original date posted:2015-09-01
📝 Original message:Den 2 sep 2015 00:03 skrev "Btc Drak via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
>
> I think it gets worse. Who are the copyright owners (if this actually
> applies). You've got people publishing transaction messages, you've
> got miners reproducing them and publishing blocks. Who are all the
> parties involved? Then to take pedantry to the next level, does a
> miner have permission to republish messages? How do you know? What if
> the messages are reproducing others copyright/licensed material? It's
> not possible to license someone else's work. There are plenty rabbit
> holes to go down with this train of thought.
Worse yet - transaction malleability creates derative works with multiple
copyright holders (the original one, plus the author of the modification).
Is that even legal to do? What to do if a miner unknowingly accepts an
illegally modified transaction in a block? And can he who modified it ALSO
sue anybody replicating the block for infringement?
Better just put everything in public domain, or the closest thing to it you
can get. Copyright in the blockchain is essentially the DVDCSS illegal
prime mess all over again, but in a P2P network.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150902/9dcf77bc/attachment.html>

2023-06-07 17:39:01

- reply

📅 Original date posted:2015-09-01
📝 Original message:Creative Commons Zero, if anything at all.
It essentially emulates public domain in jurisdictions that do not
officially have a public domain.
- Sent from my tablet
Den 1 sep 2015 15:30 skrev "Ahmed Zsales via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
> Hello,
>
> We believe the network requires a block chain licence to supplement the
> existing MIT Licence which we believe only covers the core reference client
> software.
>
> Replacing or amending the existing MIT Licence is beyond the scope of this
> draft BIP.
>
> Rationale and details of our draft BIP for discussion and evaluation are
> here:
>
>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>
> Regards,
>
> Ahmed
>
> _______________________________________________
> 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/20150901/2d1ba353/attachment.html>

2023-06-07 17:37:54

- reply

📅 Original date posted:2015-08-29
📝 Original message:My current idea:
* There's a scheduled hardcap that goes up over time.
* Miners vote on the blocksize limit within the hardcap, choosing the new
votecap. No particular idea for scheduling change. The 2016 block period
seems a bit long though, in case of sudden peak load.
(I'd suggest rolling vote over X blocks, enacted Y blocks later (with votes
counted from block A to block B = block A+X, the change is enacted at block
C = B+Y = A+X+Y). I'm fine with fixed-period schedules too if they span a
reasonable time, such as IMHO 2 days - we need rapid peak adjustment. No
suggestion on vote result calculation mechanism.)
* Casting votes are free.
* The mean (average) blocksize over the last time period X is calculated
for every block, or at the end of every fixed-length period (depending on
what scheduling is used for votes).
* Creating blocks larger than the mean but below the votecap raises the
difficulty target for the miner (and slightly raises the mean for future
blocks).
* The degree of difficulty raise depends on where between the mean and
votecap that the size of the given block is (and it follows that lots of
votes for large raise reduces per-extra-Kb penalty, allowing for cheaper
peak load adjustment if a large miner majority agrees). The degree of
increase may be either linear or logarithmic, I've got no suggestion
currently on any particular metric.
(Some might think this is an easy way for miners to collude to make large
blocks cheaper. If so, you could commit to only pay fee to miners that
don't vote for a block size above the size you accept, as a
counter-incentive.)
* Question: When the votecap is lowered, should the calculated mean be
forced down to follow (forcing a penalty for making blocks close to the
votecap straight after the change)? If so, how? Or should it be allowed to
fall naturally as new blocks with size below the votecap are created?
This is how miners would pay for actually creating larger blocks, and
leaves us with three methods of keeping the size in check (hardcap, votecap
and softcap). The softcap mechanism is then our third check to use if
deemed necessary (orphaning valid blocks if considered problematically
large). This third option do not need coordination with miners, they just
need to be aware which block size is accepted by the community.
I can't think of any sensible non-miner mechanism of deciding max block
size outside of using a community coordinated softcap, anything else will
not work reliably. Too hard to measure objectively and judge fairly.
The community would thus agree on a hardcap schedule in advance, and have
the option to threaten orphaning blocks via softfork later on if
circumstances would change and the votecap is too large.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/a985f3e6/attachment.html>

2023-06-07 17:37:46

- reply

📅 Original date posted:2015-08-31
📝 Original message:One last comment here on this topic;
For anybody who wants to discuss decentralized communication mechanisms in
general, they can come to www.reddit.com/r/p2pcomms (up until these
decentralized forums have become stable and common).
I've seen quite a few more of these projects lately, I want to make a list
of them and would definitely like to contribute to making them not just
usable, but good enough to gain popularity on their own.
(And in case you wonder about my approach to moderation: let every user
pick which moderators / filters / servers he trusts, and let them share
their subscription preferences in place of sharing links to centralized
forums.)
- Sent from my phone
Den 31 aug 2015 10:45 skrev "NxtChg via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
>
> >I am creating a de-centralized forum, and I mean truly decentralized as I
> nor anyone else will be able to control it.
>
> Zander is working on the same thing:
> https://www.reddit.com/r/AetheralResearch/
>
> But it's actually quite difficult to make it truly censorship-resistant:
> both in solving the theymos factor and spam/abuse/overloading as an attack.
>
>
> >There is no doubt that the centralization and censorship of the Bitcoin
> community is massively inhibiting the advance of Bitcoin
> >and also the growth of the Bitcoin economy. We are scaring away
> intellectuals, businessman, and newbies that are just getting started.
>
> We have /r/bitcoinxt and so far it has been great. But we also need a
> regular forum.
>
> Roger Ver controls bitcoin.com, as I understand?
> https://bitcoin.com/forum/ would be nice.
>
> And it must be a real community, not "say whatever you want because free
> speech". We've seen how that turned out to be.
>
> Something like battle.net or Steam forums: heavily moderated, not for
> opinions, but for spam/noise/insults.
>
> Again, this needs leadership. Anyone can install a forum software, what is
> needed is an "official seal of approval" and regular presence of top XT
> people there.
>
> And a will to setup proper moderation. Then people will move.
>
> _______________________________________________
> 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/20150831/49ef2b6e/attachment.html>

2023-06-07 17:34:17

- reply

📅 Original date posted:2015-08-07
📝 Original message:Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
>
> Mark,
> It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have this dialogue. So 5 minutes is a lot of
time.
>
> Obviously this is not a technical response to the technical issues you
argue. But "minutes" is a time scale we humans use to measure time very
often.
But what's more likely to matter is seconds. What you need then is some
variant of multisignature notaries (Greenaddress.it, lightning network),
where the combination of economic incentives and legal liability gives you
the assurance of doublespend protection from the time of publication of the
transaction to the first block confirmation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/17be29f3/attachment.html>

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-22
📝 Original message:- Sent from my tablet
Den 22 jul 2015 17:51 skrev "Thomas Voegtlin via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
>
> Hello,
>
> Although Electrum clients connect to several servers in order to fetch
> block headers, they typically request address balances and address
> histories from a single server. This means that the chosen server knows
> that a given set of addresses belong to the same wallet. That is true
> even if Electrum is used over TOR.
>
> There have been various proposals to improve on that, but none of them
> really convinced me so far. One recurrent proposal has been to create
> subsets of wallet addresses, and to send them to separate servers. In my
> opinion, this does not really improve anonymity, because it requires
> trusting more servers.
>
> Here is an idea, inspired by TOR, on which I would like to have some
> feedback: We create an anonymous routing layer between Electrum servers
> and clients.
Why not look at something like Dissent? http://dedis.cs.yale.edu/dissent/
This protocol reduces the impact of Sybil attacks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/55192dba/attachment.html>

2023-06-07 15:41:13

- reply

📅 Original date posted:2015-06-29
📝 Original message:Den 30 jun 2015 03:00 skrev "Tom Harding" <tomh at thinlink.com>:
>
> On 6/29/2015 5:51 PM, Natanael wrote:
>>
>> What you ask to see implemented will trivially fall to a sybil attack.
It isn't securable. It is running on the honor system exclusively. It will
be attacked, it will fail, losses will be had, the attackers will walk away
with embarrassingly large sums.
>
>
> Oh please. Checking that a node does relay something is not much
different than banning it for relaying garbage.
>
> It just happens to require that you have two nodes and coordinate them
somehow. I didn't offer a complete design, don't claim magical properties,
and certainly didn't mean to imply that nodes passing a test could be
trusted (as you suggest with your "accountable parties").
But the check means nothing at all to you since no information which you
can learn from doing so can be trusted for use in decision making of any
kind, so why do it? Unless you pay for hosting of that particular node
which you test, you have no reason to care for any reason other than simple
statistics.
The claims I made is based on simple economic analysis - if *to be able to
attack* first requires effort and risk that exceed the payoff, you're
unlikely to try. Being legally accountable and identified in advance and
having to build reputation before being trusted with attack-worthy sums is
strongly discouraging.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150630/4f0ff3aa/attachment.html>

2023-06-07 15:41:13

- reply

📅 Original date posted:2015-06-29
📝 Original message:Den 30 jun 2015 02:21 skrev "Tom Harding" <tomh at thinlink.com>:
>
> On 6/28/2015 10:07 PM, Peter Todd wrote:
>>
>> Worryingly large payment providers have shown
>> willingness(4) to consider extreme measures such as entering into legal
>> contracts directly with large miners to ensure their transactions get
mined.
>> This is a significant centralization risk and it is not practical or even
>> possible for small miners to enter into these contracts, leading to a
situation
>> where moving your hashing power to a larger pool will result in higher
profits
>> from hashing power contracts; if these payment providers secure a
majority of
>> hashing power with these contracts inevitably there will be a temptation
to
>> kick non-compliant miners off the network entirely with a 51% attack.
>>
>
> Your incomprehensible meddling with successful usage patterns threatens
to have unintended consequences directly in opposition to your own stated
goal of decentralization. And yet you persist.
>
> As we deliberately break things and turn the P2P network into a
completely unpredictable hodge-podge of relay policies, we should expect
many more participants to bypass the P2P network entirely.
What you are asking for is TSA style reactive security and unverifiable and
fundamentally untrustable security mechanisms, rejecting proactive security
on the grounds that it is inconvenient.
What you ask to see implemented will trivially fall to a sybil attack. It
isn't securable. It is running on the honor system exclusively. It will be
attacked, it will fail, losses will be had, the attackers will walk away
with embarrassingly large sums.
You want verifiable behavior? Incentives to tell the truth? Incentives to
be consistent? Multisignature notaries (Greenaddress.it), payment channel
based hub-and-spokes (LN, Stroem), etc... Trusting the P2P network is
futile. You need one accountable party that is actually capable of
enforcing the behavior you ask for, one that can build a reputation over
time - the P2P nodes you wish to hold accountable are on the other hand
powerless to stop an actual attack, their reputations are therefore
meaningless and irrelevant. Multisignature notaries aren't, as they can
stop an attack, and they can be sued for breach of contract if they don't -
neither of those applies to P2P nodes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150630/725125ab/attachment.html>

2023-06-07 15:41:04

- reply

📅 Original date posted:2015-06-27
📝 Original message:Old versions of software that can't be sandboxed from the world by design
must eventually die. The reason is simple - otherwise it will be abused,
exploited and end up actively countering its own intended purpose. Either
through security holes or other means of abusing the outdated code's
behavior.
Full nodes in Bitcoin validate all new transactions against their own
embedded policies and rules. Eventually the global concensus will agree on
a change of rules, as the current ruleset isn't perfect - this will toss
incompatible old full nodes off the greatest-PoW blockchain. This is
inevitable - not all instances of the software will get updated. Scanning
the Internet for Internet accessible hardware will reveal tons of outdated
software versions.
There is however currently no simple way to tell a node that it is
outdated. Even if you just incremented block versions, it will only lead to
some kind of alert (IIRC) for some versions. I'm suggesting behaviors that
would simplify transition to new versions over time with minimal
disruption.
* Expiration dates. Nodes so old that they are behind by numerous soft
forks and likely are to be deprecated by a hard fork should switch to SPV
mode automatically while also alerting the node owner. This behavior
extends the lifetime while not by itself breaking anything with minimal
disruption. It also allows node owners which look at the status of their
nodes but don't think of updating (maybe it is automatically deployed old
software images) to realize an update is sin necessary. SPV mode also needs
to have an expiration date before complete node shutdown. Expiration dates
also minimize risk for political disagreement regarding how and when to
take any manual action to trigger necessary alerts. 3 years to SPV is a
reasonable default IMHO, with node shutdown after 5 years. Any other
suggestions?
* Explicit declaration of block policy / rules in blocks, including miner
votes for changes, and explicit declaration of incompatibility with old
versions. Having votes visible in the blocks for implementing changes
incompatible with the policy and rules your node runs allows it to alert
the node owner of impending necessity to update. Switching to SPV mode
again provides for minimal disruption. Please take note that even old SPV
nodes may eventually be deprecated through data structure changes, this too
should be declared and then cause alerts and halt / shutdown of those
nodes.
This also protects against another issue - an old abandoned node will not
automatically trust a fresh longer chain (likely malicious) using its own
policy if it remembers an earlier fork voting for change, instead it
prompts for the node owner to either update (or stick to SPV on the
new-policy chain) or to accept this fresh fork. Nodes on a chain with its
own policy seeing a fork with a vote for change should look at the PoW
first. If it is close, alert the user (he might have brought the node
online just after the vote finished, to first see the fork that is on his
old policy), so he can investigate. If the PoW is far behind it may be
ignored, or simply logged.
Seeing a block also explicitly declare being incompatible with the policy a
node follows including for SPV nodes, rather than just using version
numbers, simplifies things too. It ensures the nodes know they can't
validate the blocks with their old code, which simultaneously ensures that
behavior changes that doesn't violate the old validation code but yet
causes incompatibility then will not silently fork the network, instead it
will let the node owners know their nodes are incompatible with the main
chain. This allows them to investigate and update of necessary.
---
The primary reason for me suggesting switching to SPV mode is simple - it
buys time for everybody. Hard forks no longer become a critical deadline
for getting the ENTIRE network upgraded - you just need to worry about the
miners and major players in the short term. Long term you do need
information campaigns to get SPV fallback nodes updated, but it won't need
to be rushed. The information campaigns no longer need to be FULLY
completed BEFORE deployment.
Feedback?
- Sent from my tablet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/e38a4379/attachment.html>

2023-06-07 15:32:11

- reply

📅 Original date posted:2015-03-18
📝 Original message:Den 18 mar 2015 23:38 skrev "Dennis Sullivan" <dennis.jm.sullivan at gmail.com
>:
>
> Hello. This is my first time posting to this list. I wanted to ask your
opinions on something relating to confirmation times.
>
> I recently read about a "transaction locking" proposal which claims to
make it possible to accept 0-conf transactions with guarantee they will get
mined. This seems rather dubious to me, because if there was merit to the
system, I would have already expected to see discussion on this list
regarding it.
Sounds like it would be weak to sybil attacks (deterministically choosing
my own nodes sounds great!), and of course Finney attacks (single-block
reversal) and defecting miners (what are you gonna do, punish miners with
limited network connectivity as well? You'll risk forking the network).
Zero-conf is only safe if nobody's actively trying to attack you. It has no
inherent security in and of itself. For low values the risk is usually
tolerated. For large values there's too much risk of making yourself a
target.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150318/89142b7c/attachment.html>

2023-06-07 15:31:52

- reply

📅 Original date posted:2015-03-13
📝 Original message:Den 13 mar 2015 20:57 skrev "Kalle Rosenbaum" <kalle at rosenbaum.se>:
>
> Hi all,
>
> I've been thinking about how a person can prove that she has made a
payment. I came up with an idea I call Proof of Payment (PoP) and I would
highly appreciate your comments. Has something like this been discussed
somewhere before?
>
> Use cases
>
> There are several scenarios in which it would be useful to prove that you
have paid for something. For example:
> A pre-paid hotel room where your PoP functions as a key to the door.
> An online video rental service where you pay for a video and watch it on
any device.
> An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. During
this period you can upload new content to the sign whenever you like using
PoP.
> A lottery where all participants pay to the same address, and the winner
of the T-shirt is selected among the transactions to that address. You
exchange the T-shirt for a PoP for the winning transaction.
>
> These use cases can be achieved without any personal information (no
accounts, no e-mails, etc) being involved.
>
> Desirable properties:
> A PoP should be generated on demand.
> It should only be usable once to avoid issues due to theft.
> It should be able to create a PoP for any payment, regardless of script
type (P2SH, P2PKH, etc.).
Relevant: https://idemix.wordpress.com/
Anonymous Credentials allows an issuer to declare that you have certain
rights. For example, upon paying the service provider could issue you the
credentials for using their service up until a certain date.
When challenged to prove a statement about what credentials you have, you
can prove the fact that you've got the right credentials without revealing
anything else. You don't even reveal you're the same person as the last
time, if you prove the right to access a VPN multiple times there's no data
in it that links the different sessions together.
The main difference is that issuance of Anonymous Credentials aren't
"atomic" with the payment transactions, which can open up the risk for
certain types of dishonest behavior by the seller. You could however use a
proof in court of having paid for the credentials but not getting them
issued to you (maybe throw in usage of Factom to log issuance of
credentials?). With this construction of using both these methods, you add
stronger privacy for the usage of the services while simultaneously keeping
a degree of accountability for the payment.
The Zerocoin developers also got a paper on a blockchain version,
"Distributed Anonymous Credentials".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/d6964566/attachment.html>

2023-06-07 15:31:46

- reply

📅 Original date posted:2015-03-08
📝 Original message:Den 8 mar 2015 02:36 skrev "Pavol Rusnak" <stick at gk2.sk>:
>
> On 07/03/15 16:53, Mem Wallet wrote:
[...]
> I am currently in process of implementing a SignIdentity message for
> TREZOR, which will be used for HTTPS/SSH/etc. logins.
>
> See PoC here:
>
https://github.com/trezor/trezor-emu/commit/9f612c286cc7b8268ebaec4a36757e1c19548717
>
> The idea is to derive the BIP32 path from HTTPS/SSH URI (by hashing it
> and use m/46'/a'/b'/c'/d' where a,b,c,d are first 4*32 bits of the hash)
> and use that to derive the private key. This scheme might work for GPG
> keys (just use gpg://user@host.com for the URI) as well.
Reminds me of FIDO's U2F protocol.
http://fidoalliance.org/specifications
https://www.yubico.com/products/yubikey-hardware/fido-u2f-security-key/
It ties into the browser SSL session to make sure only the correct server
can get the correct response for the challenge-response protocol, so that
credentials phishing is blocked and worthless. A unique keypair is
generated for each service for privacy, so that you can't easily be
identified across services from the usage of the device alone (thus safe
for people with multiple pseudonyms).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150308/df137ccd/attachment.html>

2023-06-07 15:31:33

- reply

📅 Original date posted:2015-03-12
📝 Original message:Den 12 mar 2015 19:52 skrev "Andreas Schildbach" <andreas at schildbach.de>:
>
> I'm afraid this will never fly. Wallets are just too different and
> that's a good thing! For example, by design choice Bitcoin Wallet and
> bitcoinj doesn't support multiple accounts. How would it ever import
> wallets from MultiBit or Mycelium?
I think I covered that with the "importing wallet says what sections it
supports" part. Then you'd only ask for the library to give you the
addresses from the first branch in the main HD wallet. The user would be
told that you by design can't manage the other parts. The user would be
alerted and get the recommendation to send the funds over manually if they
want to switch their wallet. The user might however just want to export
that one single branch if he's a "power user", so he would proceed to use
it that way.
At export, I recommend the wallet will tell the user what extensions and
standards are in use (and which are necessary to recover how much of their
funds in the target wallet). The user would be asked to confirm that the
target wallet client supports these. The user should be given the option to
hand the list of supported functionality in the target wallet (like a list
of BIP numbers?), and tell the wallet to move the funds around so that the
target wallet can successfully import everything and recover all funds.
Actually, thinking about it I think what we really need first is a standard
synchronization / transition protocol. Right now we don't have more than
the address label syncing plugin for Electrum. We need something for
wallets to synchronize state, with the option for having one wallet tell
the other how to send over all funds (for when they use completely
different standards for managing funds). As the most simple option, the
target wallet would provide a list of addresses to the sending wallet when
you switch (this would satisfy Bryan's request).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/75ba39b6/attachment.html>

2023-06-07 15:31:33

- reply

📅 Original date posted:2015-03-12
📝 Original message:Den 12 mar 2015 17:48 skrev "Mike Hearn" <mike at plan99.net>:
>>
>> b) "Creation date" is just a short-term hack.
>
>
> I agree, but we need things to be easy in the short term as well as the
long term :)
>
> The long term solution is clearly to have the 12 word seed be an
encryption key for a wallet backup with all associated metadata. We're
heading in that direction one step at a time. Unfortunately it will take
time for wallets to start working this way, and all the pieces to fall into
place. Restoring from the block chain will be a semi regular operation for
users until then.
This have been mentioned a few times before, and what I think is necessary
is to create a common file format that can be interpreted by a library
which all wallets can use. I see it as similar as the work to create
libconsensus for parsing the blockchain.
We need something extensible that can describe how to derive all addresses
used by the user. What HD branches to derive and how, with block numbers
(or bloom filters of block hashes or similar) to note where all previously
known transactions related to the wallet have occurred, and the last known
block (so only new blocks need to be scanned).
A way to describe one HD tree as a multisignature wallet tied to a hardware
wallet if you have that (could include serial number or MAC of the device
for simple identification by the wallet client). A way to describe another
set of addresses as using a custom extension. A way to denote one private
key as being used for stealth addresses together with details for how to
identify the transactions (prefix, mailbox to look in, etc). Labels for
transactions. P2SH script templates so those addresses can be recovered. A
way to describe Copay style multisignature wallets and what server to use
for coordinating with the other coowners. A way to describe threshold
crypto group signature wallets and how to coordinate. Computer parsable
descriptions of HD branches as change addresses, as being used for
receiving payments in merchant payment systems, etc... Also, you should
really be talking to people like accountants and auditors to see what
features they'd like to see when it comes to things like how company
wallets could have rules defined for how to use the various HD branches.
And so on... I think you get my point by now.
The basic idea is that the wallet uses the library to parse the wallet file
and tells the user which sections it understands (can't expect all wallets
to handle custom extensions or stealth addresses, etc), then proceeds to
scan the blockchain for those addresses. Then the user also won't be
surprised that not all funds are found and won't think they're lost.
I think it should be referred to as an import/export format, more than as a
backup format.
You always want the most recent metadata the wallet of origin can provide
when importing, to reduce unnecessary extra work. You don't want really old
backup files. If people add new seeds and various new extensions that can't
be automatically recovered from old wallet backups, they need new backups.
You might as well use the wallet's own internal formats for backup, as the
wallet developer might better know how to optimize for the use cases he
have designed for. But at the same time we should ask wallet developers to
offer conversion tools to generate export format files from custom wallet
data files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/8331a17a/attachment.html>

2023-06-07 15:31:02

- reply

📅 Original date posted:2015-02-23
📝 Original message:Den 23 feb 2015 08:38 skrev "Andy Schroder" <info at andyschroder.com>:
>
> I agree that NFC is the best we have as far as a trust anchor that you
are paying the right person. The thing I am worried about is the privacy
loss that could happen if there is someone passively monitoring the
connection. So, in response to some of your comments below and also in
response to some of Eric Voskuil's comments in another recent e-mail:
>From the sources I can find NFC don't provide full privacy, but some
modulations are MITM resistant to varying degrees, some aren't at all, and
they are all susceptible to denial of service via jammers.
If the merchant system monitors the signal strength and similar metrics, a
MITM that alters data (or attempts to) should be detectable, allowing it to
shut down the connection.
Using NFC for key exchange to establish an encrypted link should IMHO be
secure enough.
http://resources.infosecinstitute.com/near-field-communication-nfc-technology-vulnerabilities-and-principal-attack-schema/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/4bea3a57/attachment.html>

2023-06-07 15:30:56

- reply

📅 Original date posted:2015-02-22
📝 Original message:Den 22 feb 2015 14:29 skrev "Natanael" <natanael.l at gmail.com>:
>
>
> Den 22 feb 2015 13:36 skrev "Peter Todd" <pete at petertodd.org>:
>
> > Implementing it as a general purpose scripting language improvement has
> > a lot of advantages, not least of which is that you no longer need to
> > rely entirely on inherently unreliable P2P networking: Promise to never
> > create two signatures for a specific BIP32 root pubkey and make
> > violating that promise destroy and/or reallocate a fidelity bond whose
> > value is locked until some time into the future. Since the fidelity bond
> > is a separate pool of funds, detection of the double-spend can happen
> > later.
>
> Somebody sent me a zero-confirmation transaction, or one that got
orphaned after one block. I created a transaction spending that UTXO, and
another.
>
> So at that point I have UTXO_orphaned based on the sender's UTXO_origin
and my UTXO_old (because I've had it unspent for a long time), both in one
transaction, creating UTXO_new.
>
> Now he doublespend UTXO_origin to create a UTXO_doublespend (which
conflicts with UTXO_orphaned). He conspires with a miner to get it into a
block.
>
> Now what? Can my UTXO_old effectively be tainted forever because UTXO_new
got invalidated together with UTXO_orphaned? Will that transaction be a
valid proof of doublespend against a new UTXO_replacement I created?
>
> Or otherwise, if only transactions where all UTXO's are currently valid
works as doublespend proofs, aren't you still just left without protection
against any one miner that conspires with doublespend attempting thieves?
>
> In other words, you are unprotected and potentially at greater risk if
you create a transaction depending on another zero-confirmation transaction.
Additional comments:
If you punish the creation of UTXO_replacement, you will punish people who
was lead to think zero-confirmation transactions were safe and thus that
chains of zero-confirmation transactions also were safe.
If you don't, but STILL accept chains of zero-confirmation transactions
were not all of them are covered by fidelity bonds, then you failed to
protect yourself against thieves who creates chains of unconfirmed
transactions.
Another question: if all transactions in the chain are covered by fidelity
bonds for their own value, which one pays out to who? Does only the first
one pay out, and only to the last party in the chain? Or to every
subsequent party after him? In full or just a fraction? Why, why not? You
might not know which of these serviced their customers in full without
getting full value back in exchange due to the doublespend.
What if the fidelity bond is too small, do you stop accepting it as a
zero-confirmation transaction?
Do you even accept chains of unconfirmed transactions at all?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/f3b31e8e/attachment.html>

2023-06-07 15:30:55

- reply

📅 Original date posted:2015-02-22
📝 Original message:- Sent from my tablet
Den 22 feb 2015 17:25 skrev "Justus Ranvier" <justusranvier at riseup.net>:
>
> You just disproved your own argument.
>
> It is possible to predict risk, and therefore to price the risk.
Your fault is that you assume the predictions can be reliable and
trustable.
They can not be.
The data you have available has none of the indicators you actually NEED to
make predictions. You're making extrapolations from the past, not
calculations based on recent trends and behavior globally.
> You also noted that for some Bitcoin users, the price of that risk is
> too high for the types of transactions in which wish to engage.
>
> In what way does that translated into a universal requirement for
> everybody to use multisignature notaries?
It isn't universal. It is just the most practical solution if you need
instant confirmation for high value transactions with customers you don't
yet trust.
> Surely the users who can afford the risk can use zero conf if they
> like, and those who can't can use multisig notaries?
Use whatever you want. I don't care. I will warn you about the risks and
make suggestions, but I won't force you to do anything differently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/62c2a89e/attachment.html>

2023-06-07 15:30:54

- reply

📅 Original date posted:2015-02-22
📝 Original message:Den 22 feb 2015 17:00 skrev "Justus Ranvier" <justusranvier at riseup.net>:
>
> On 02/22/2015 07:50 AM, Matt Whitlock wrote:
> > This happened to one of the merchants at the Bitcoin 2013
> > conference in San Jose. They sold some T-shirts and accepted
> > zero-confirmation transactions. The transactions depended on other
> > unconfirmed transactions, which never confirmed, so this merchant
> > never got their money.
> >
> > I keep telling people not to accept transactions with zero
> > confirmations, but no one listens.
>
> A better solution is to track the failure rate of zero confirmation
> transactions, and adjust prices accordingly to cover the expected loss.
>
> This is what every merchant *already does* since no payment method has
> a 0% fraud rate.
>
> Even physical cash has a probability of being counterfeit, and the
> prices you pay for things at a convenience store already have that
> risk priced in.
>
> The idea that zero confirmation transactions require a 100% guarantee
> is a strawman, especially since there exists no number of
> confirmations the actually produce a 100% irreversibility guarantee.
The problem with this approach is that it is worthless as a predictor. We
aren't dealing with traffic safety and road design - we are dealing with
adaptive attackers and malicious miners and pools.
Anything which does not invalidate blocks carrying doublespends WILL allow
malicious miners and pools to conspire with thieves to steal money. The
probability of being hit will then be (their proliferation in your business
area) * (their fraction of the mining power).
That might seem to give small numbers for most sets of reasonable
assumptions. But the problem is that's only an average, and the people
being hit might have small profit margins - one successful attack can place
hundreds of merchants in red numbers and force them to shut down.
You should never expose yourself to attacks which you can't defend against
and which can be fatal. In particular not if there's nothing in the
environment that is capable of limiting the size or numbers of any attacks.
And there's no such thing today in Bitcoin.
This is why I sketched out the multisignature notary approach, and why some
decided to extend that approach with collateral (NoRiskWallet) to further
reduce trust in the notary. This is the single most practical approach I
know of today to achieve ACTUAL SECURITY for unconfirmed transactions.
Don't like it? See if you can do better!
Just don't rely on zero-confirmation transactions!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/68d5018c/attachment.html>

2023-06-07 15:30:53

- reply

📅 Original date posted:2015-02-22
📝 Original message:Den 22 feb 2015 13:36 skrev "Peter Todd" <pete at petertodd.org>:
> Implementing it as a general purpose scripting language improvement has
> a lot of advantages, not least of which is that you no longer need to
> rely entirely on inherently unreliable P2P networking: Promise to never
> create two signatures for a specific BIP32 root pubkey and make
> violating that promise destroy and/or reallocate a fidelity bond whose
> value is locked until some time into the future. Since the fidelity bond
> is a separate pool of funds, detection of the double-spend can happen
> later.
Somebody sent me a zero-confirmation transaction, or one that got orphaned
after one block. I created a transaction spending that UTXO, and another.
So at that point I have UTXO_orphaned based on the sender's UTXO_origin and
my UTXO_old (because I've had it unspent for a long time), both in one
transaction, creating UTXO_new.
Now he doublespend UTXO_origin to create a UTXO_doublespend (which
conflicts with UTXO_orphaned). He conspires with a miner to get it into a
block.
Now what? Can my UTXO_old effectively be tainted forever because UTXO_new
got invalidated together with UTXO_orphaned? Will that transaction be a
valid proof of doublespend against a new UTXO_replacement I created?
Or otherwise, if only transactions where all UTXO's are currently valid
works as doublespend proofs, aren't you still just left without protection
against any one miner that conspires with doublespend attempting thieves?
In other words, you are unprotected and potentially at greater risk if you
create a transaction depending on another zero-confirmation transaction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/6d890d99/attachment.html>

2023-06-07 15:30:17

- reply

📅 Original date posted:2015-02-12
📝 Original message:On Thu, Feb 12, 2015 at 8:52 PM, Justus Ranvier
<justusranvier at riseup.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/12/2015 07:47 PM, Allen Piscitello wrote:
>> Nothing will stop that. Bitcoin needs to deal with those issues,
>> not stick our heads in the sand and pretend they don't exist out of
>> benevolence. This isn't a pet solution, but the rules of the
>> protocol and what is realistically possible given the nature of
>> distributed consensus. Relying on altruism is a recipe for
>> failure.
>
> If there's a risk of fire burning down wooden buildings, pass out fire
> extinguishers and smoke detectors, not matches.
>
> The latter makes one an arsonist.
Controlled fires is a valid tactic when necessary to reduce harm. It
is frequently used in areas with periods of extreme heat including
Australia. By burning off grids, you isolate the majority of flammable
matter into "islands". An accident fire would cause much more damage.
Placing yourself in the way of the fire and asking them to find
another solution isn't that bright. It is only a matter of time until
a fire starts, controlled or not! If you want another solution, go
figure one out yourself!
More to the point, it is unreasonable to knowingly expose yourself to
risk of harm and blame everybody else who isn't making your life
easier without you having to change anything. If the majority decides
that the best option to reduce harm for everybody requires that you
move out of the way and find another way to do things, you're better
off moving.
Telling people it is fine to keep being careless when there's a fire
hazard is "the real crime", because that would cause more harm than
what those who try to get the system changed does.

2023-06-07 15:30:14

- reply

📅 Original date posted:2015-02-12
📝 Original message:Den 12 feb 2015 16:42 skrev "Mike Hearn" <mike at plan99.net>:
> Remember that you aren't paying the bad pool, the bad pool is paying you.
Whichever pool benefits from the scorched earth protocol can simply pick an
address out of the transaction it perceived as starting the protocol, and
pay that.
My counterargument: with zero-conf but no replace-by-fee scorched earth,
there would instead be a market which thieves use where pools would offer
to execute doublespends that pay the thief and the pool, and where the
pools would set what terms and payouts they ask for.
All bidding pools with acceptable terms get a doublespend transaction that
pays that specific pool and the thief, the first to mine theirs win (and
the merchant loses).
Your protocol requires less setup, but that's the only notable difference
(besides risk of paying non-participating pools with scorched earth).
No notable difference in security for merchants.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/e4e44b31/attachment.html>

2023-06-07 15:30:13

- reply

📅 Original date posted:2015-02-12
📝 Original message:Den 12 feb 2015 16:15 skrev "Mike Hearn" <mike at plan99.net>:
>
> The first is that this setup means miners can steal arbitrary payments if
they work together with the sender of the money. The model assumes this
collaboration won't happen, but it will. Because no existing wallet has a
"double spend this" button, to make the scheme work the dishonest miners
must create and distribute such a wallet that implements the whole
scorched-earth protocol. At that point it's easy for miners to reward the
payment fraudster with some of the stolen money the merchant lost, meaning
it now makes sense for the fraudster to always do this. The situation isn't
stable at all.
>
> The second is that it incentivises competitors to engage in payment fraud
against each other. A big rich coffee shop chain that is facing competition
from a small, scrappy newcomer can simply walk into the new shop and buy
things, then trigger the "scorched earth". Even with no miner
collaboration, this means the big company is down the cost of the product
but so is the little company who lost everything. Whoever can outspend the
other wins.
>
> We don't really need game theory to tell us that this plan is a bad idea.
Just imagine trying to explain it to an actual shop keeper. They would
think you were crazy. Bitcoin is already a hard enough concept to
understand without throwing into the mix "anyone can burn the money they
gave you after walking out of the shop".
I see no fundamental difference in outcome from miner collusion in
scorched-fee (which isn't guaranteed to pay the "right" pool!) and miner
collusion in knowingly mining a doublespend transaction.
Both outcomes pay the miner and thief equally when successful. The merchant
loses in both.
Zero-conf needs something else for security. A guarantee it can not be
doublespent in the relevant time frame.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/1da9aa24/attachment.html>

2023-06-07 15:30:10

- reply

📅 Original date posted:2015-02-12
📝 Original message:Den 12 feb 2015 15:53 skrev "Mike Hearn" <mike at plan99.net>:
>>
>> > So you're just arguing that a notary is different to a miner, without
spelling out exactly why.
>
> I'm afraid I still don't understand why you think notaries would build
long term businesses but miners wouldn't, in this model.
>
> I think you are saying because notaries have identity, brand awareness
and because they have big up front bonds, that means they will be
trustworthy.
Miners aren't contractors, they don't have to care about repeat business.
Individual miners don't have enough impact to have a negative impact on
their own capital investment. Zero-conf transactions also aren't that tied
to the Bitcoin valuation.
Multisignature notaries need to convince people to select them. They want
to know that even with collateral, their funds won't be temporarily locked
up and unspendable for days at a time.
What services would miners provide here, do you think?
> Well, sure. It's the same model governments use and is why being a money
transmitter in the USA is so difficult: you need to put up large sums of
money as collateral and have your fingerprints taken 48 times. Then you can
start advertising to get customers!
Obviously you need to have collateral to provide collateral. Can't make
cryptographic verifiable guarantees if you don't have the resources to back
them.
> The reason mining is such a nice model is it doesn't have these sorts of
requirements.
And also can't make these assurances. Any minority miner can be overrun.
>> As notaries can be small operations ..... [snip] ...... (almost every
large organization in the world have some unallocated funds somewhere).
>
> Which is it? Are notaries small operations or large operations?
The operation itself is small. A few people maintaining a few servers.
The collateral needed depends on how many and how large simultaneous
transactions they want to provide assurances for, so they can chose to be a
small player for one niche market or large and global if they have the
funds for it.
> I think exploring new consensus models with semi-trusted notaries is
interesting, but it's not Bitcoin.
Methods for decentralized consensus that aren't PoW also aren't Bitcoin.
> Please don't try and apply this logic in the real world :( Rephrased:
>
> "That's a nice house. I noticed it's made of wood. I'm going to start
fires until it burns down, because there is no guarantee your house won't
burn down in future and it's important you understand that wooden houses
aren't safe. Really I'm just doing you a favour."
Actually that IS often a bad idea. But fortunately the risk and threat is
low, and mitigation is well understood.
> I'm really not a fan of Peter's approach, which is "hey let's try and
cause as many problems as possible to try and prove a point, without having
created any solutions". Replace-by-fee-scorched-earth doesn't work and
isn't a solution. Miners can easily cut payment fraudsters in on the stolen
money, and as they'd need to distribute custom double-spending wallets to
make the scheme work it'd be very easy to do.
Security analysis requires having the mindset of an attacker. Sometimes
that reveals suboptimal choices. Then you want them changed to more stable
choices such that once the incentives change, the risk already is gone.
Minimization of damage, simply put.
>> Your also ssume people will expect the Bitcoin network to keep zero-conf
safe forever and that Bitcoin valuation is tied to that. Given the options
available and current state of things, I'm assuming that's wrong.
>
> Why? You think ability to make payments in a few seconds is some
irrelevant curiousity?
No. But you can't be certain it is secure without having a solid reliable
mechanism to provide such a guarantee.
You want zero-conf to stay safe without involvement of servers? Then
please, try to find a way to secure it. Right now you're assuming it can
remain safe based on circumstances which can change and assumptions about
market participant's valuations that likely aren't true.
> Let's put it this way. If BitPay's business model evaporates tomorrow,
along with all the merchants they support, do you think that'd have any
effect on Bitcoin's value? If not, why not?
It would. They'd tank. But you're assuming too much about the basis for
valuation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/437c2f0a/attachment.html>

2023-06-07 15:30:09

- reply

📅 Original date posted:2015-02-12
📝 Original message:Den 12 feb 2015 14:44 skrev "Mike Hearn" <mike at plan99.net>:
>>
>> You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.
>
> There have been lots of e-cash schemes proposed in the academic
literature that work like this, or variants of it. Schemes where
participants are anonymous until they double spend are popular.
>
> Let's re-write your proposal but substituting the word notary for miner:
>
>> To profit, the miner would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.
>
> That's the exact argument we're having. The assertion is that a
"rational" notary would kill his own business to increase his profits in
the next few hours. So you're just arguing that a notary is different to a
miner, without spelling out exactly why.
>
> Does the notary have to make a big up front investment? If so, why is
that different to mining investment?
Miners are transient. You don't depend on any given subset of them.
Centralized e-currency give you no choice but to trust one set of notaries.
The notary don't have any large maintenance costs. The initial investment
is small, they don't need more than a few servers and maybe a HSM and some
office. In the non-collateral version, they're a centralized entity. Note
that in the fully centralized model, if the notary goes bad you're screwed.
Your tokens are useless or maybe gone.
Essentially you can't know if you're up for the long con or not.
Anybody can set up a miner with capital investments. No individual miner
has a large impact on the system as a whole.
In Bitcoin, you aren't dependent on any one multisignature notary. One
going gown only represents a small loss and done temporarily locked funds.
Anybody can set up a multisignature notary, but people won't trust you
unless you show you're trustable - you need to market yourself to get to
the point where a malicious doublespend can be profitable.
You can't really replicate the collateralized multisignature notary model
in centralized systems. Because having the e-currency bank be the notary
means they have the same powers a 51% miner would have - they can block the
transaction claiming the collateral, they can censor any other transactions
at will, and all your funds depend on them and the market's trust in them.
> Is the notary non-anonymous and afraid of being charged with payment
fraud? If so, note that big miners do lots of non-anonymous things too,
like renting warehouses and importing specialised equipment.
As notaries can be small operations, they can perform the doublespend as
they escape across the border.
> Is it because of the big up front collateral they're meant to have lying
around? If so, how do you ensure a fluid market for notaries?
With collateralized multisignature notaries, my assumption is that
organizations that are related to Bitcoin transactions that has sufficient
sums of unallocated funds would use them for collateral in a scheme like
this (almost every large organization in the world have some unallocated
funds somewhere).
As sellers have almost no risk of losing money to them, any notary backed
by somebody they know and trust would be good enough
As buyers also have no risk, they'd use them when they want to make quick
payments.
-----
You seem to be making a lot of arguments from the status quo. I don't care
what people have been doing, preserving every habit isn't a sacred goal. I
care about stable incentives and long term predictability regarding what
behavior is safe. Behavior that becomes unsafe if incentives change is bad
and shouldn't be relied on.
Also, Bitcoin is the concensus mechanism. As mentioned, trying to provide a
guarantee for what will end up in the blocks without servers involved is to
reinvent Bitcoin within Bitcoin. I can go Xzibit on you all day long if you
like! What you consider an attack is irrelevant. You assume a certain
behavior is desired without first making sure it is reliable.
Depending on that which isn't guaranteed is baaaad, and breaking other
people's assumptions is by itself NOT an attack if there never was a
guarantee or even as little as an implicit understanding it is safe.
Your also assume people will expect the Bitcoin network to keep zero-conf
safe forever and that Bitcoin valuation is tied to that. Given the options
available and current state of things, I'm assuming that's wrong.
Besides, zero-conf will never be secure if you don't add external
contextual information as a requirement when validating blocks. Otherwise
defecting miners will frequently doublespend against you. And adding such
information is messy and probably not secure in itself, as it opens up for
gaming the system through network level attacks.
And your remarks against game theory seems unwarranted.
The game theorists that are wrong are typically wrong for one of the
following reasons;
* Their model is wrong. The system, the actors and/or the options available
are misunderstood.
* The actors don't understand the avaliable incentives and go for trial and
error (the most optimal choices for attack and defense are found at random
or not at all, and not always adopted until it has stood the test of time).
* That option is on the to-do list, just wait.
* There's easier and/or more profitable attacks (a variant of #1 if the
game theorist said it is certain to happen).
You should NOT EVER rely on security-through-opportunity-cost for the
attacker or assume you can always keep doing what you always did. Once the
bigger targets are gone, you're next.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/2ad0cc1c/attachment.html>

2023-06-07 15:30:09

- reply

📅 Original date posted:2015-02-12
📝 Original message:Den 12 feb 2015 13:49 skrev "Mike Hearn" <mike at plan99.net>:
>>
>> Are you not counting collateralized multisignature notaries? Its an
extended version of the Greenaddress.it model.
>
> It makes unconfirmed transactions useless in the classical Bitcoin model.
Obviously if you introduce a trusted third party you can fix things, but
then you're back to having the disadvantages of centralised trust.
That trust you put in them is extremely limited, and temporary.
First of all, the standard multisignature notary model applies like how I
originally described it in my blog post over a year ago.
You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.
After confirmation in the blockchain, you have standard Bitcoin transaction
security.
To profit, the notary would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.
To provide security for high value transactions, NRW adds a collateral
transaction that the notary stands for and signs in advance, and gives to
the seller. The key here is that it is constructed such that if the
original payment gets doublespent, then this collateral transaction to the
seller becomes spendable.
So there is two outcomes - either the customer or the notary pays the
seller. The customer can't force a doublespend. The notary can't steal or
freeze funds (due to nlocktime fund recovery option). The seller knows
he'll get the funds for sure before delivering the goods. Nobody is at
risk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/be689276/attachment.html>

2023-06-07 15:30:08

- reply

📅 Original date posted:2015-02-12
📝 Original message:Den 12 feb 2015 12:58 skrev "Mike Hearn" <mike at plan99.net>:
[...]
> Your "scorched earth" plan is aptly named, as it's guaranteed to make
unconfirmed payments useless.
Are you not counting collateralized multisignature notaries? Its an
extended version of the Greenaddress.it model.
NoRiskWallet: https://github.com/baleato/bitcoin-hackathon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/ccc97086/attachment.html>

2023-06-07 15:30:03

- reply

📅 Original date posted:2015-02-11
📝 Original message:Den 11 feb 2015 09:55 skrev "Hector Chu" <hectorchu at gmail.com>:
>
> A proposal for stemming the tide of mining centralisation -- Requiring a
> miner's signature in the block header (the whole of which is hashed), and
> paying out coinbase to the miner's public key.
>
> Please comment on whether this idea is feasible, has been thought of
before,
> etc., etc. Thank you.
>
> Motivation
> ----------
>
> Mining is centralising to a handful of pool operators. This is bad for a
> number of political reasons, which we won't go into right now. But I have
> always believed that some years down the line, they could hold the users
> hostage and change the rules to suit themselves. For instance by
eliminating
> the halving of the block reward.
[...]
> I propose that we require each miner to sign the block header prior to
> hashing. The signature will be included in the data that is hashed.
Further,
> the coinbase for the block must only pay out to the public key
counterpart of
> the private key used to sign the block header.
[...]
> This will make it difficult to form a cooperating pool of miners who may
not
> trust each other, as the block rewards will be controlled by disparate
parties
> and not by the pool operator. Only a tight clique of trusted miners would
be
> able to form their own private pool in such an environment.
People already trust things like cloud mining, so your solution with
increasing technical trust requirements won't help. But you will however
break P2Pool instead.
Also, note that threshold signatures (group signatures) could probably be
used by an actual distrusting pool's miners. There are already a proof of
concept for this implemented with secp256k1 that works with Bitcoin clients
silently. This wouldn't prevent such a pool from working.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150211/c0686825/attachment.html>

2023-06-07 15:30:02

- reply

📅 Original date posted:2015-02-10
📝 Original message:> In what universe is that simple? Your solution: browser extension +
> wallet + comminucation API + all the wallets need to implement it
> Our solution: just browser extension.
Browser extension would only be required until browsers add native support
for detecting the tag and prompting a wallet client. This probably won't
happen in the near future, though.
Also, the kind of browser extension you're talking about would be limited
to just one device or require manually configured syncing between your
devices, and would also likely be limited to just a few platforms.
The communication is done between the wallet and merchant the same as
always with BIP70, but with some extra BIP70 extensions for this purpose.
It just starts talking earlier.
It supports graceful degradation just fine, if the browser or wallet don't
support it or the wallet isn't linked to that computer's browser, then
nothing out of the ordinary happens. The browser extension really don't do
anything special, it just relays the details in the HTML tag.
> > As one example, your browser could ask your hardware wallet over BLE for
> > this data. This way you barely have to trust the computer you're using
at
> > all, as everything it does is confirmed on the hardware wallet before
> > payment (assuming it has a screen, which it should). Linking your
hardware
> > wallet over BLE to new devices which you then use for browsing and
shopping
> > could be trivial and yet allow secure auto-fill of this kind.
>
> This looks more interesting but is information about your location
> really so secret that you need to hold it in HW wallet? Because if so,
> you probably don't want to use untrusted machine anyway. (Or just use
> Qubes OS.)
It isn't necessarily top secret, but why not be protective by default? Your
hardware wallet is already designed to keep secrets. Lets say you're at a
library computer, or at a friend's house, why not let your hardware wallet
deal with all the security?
In this scenario it is likely already functioning as a central point for
all your Bitcoin related purchases anyway, so it might as well be the
device that remembers all your shopping preferences for you. So let's make
it simple to use!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150210/28fa9de6/attachment.html>

2023-06-07 15:30:02

- reply

📅 Original date posted:2015-02-10
📝 Original message:Den 10 feb 2015 12:08 skrev "Mike Hearn" <mike at plan99.net>:
>
> We can certainly imagine many BIP70 extensions, but for things like
auto-filling shipping addresses, is the wallet the best place to do it? My
browser already knows how to fill out this data in credit card forms, it
would make sense to reuse that for Bitcoin.
>
> It sounds like you want a kind of Star-Trek negotiation agent thing,
where your computer knows how to seek out the best deal because all the
metadata is standardised. Such a thing would be an interesting project, but
it's probably not best done in BIP70 given how it's deployed and used
today. Rather, I'd suggest looking at the various HTML5 data standards
which would allow merchants to advertise things like where they ship to in
a machine readable and crawlable form.
BIP70 doesn't have to be the place, but not needing to make sure the device
in question have that information stored already would be an improvement.
What protocol is used doesn't matter much, I just thought reusing BIP70
would simplify implementation.
HTML5 elements could definitely be supported, through adding a tag in the
HTML form that says "prompt the Bitcoin wallet about the following payment
details".
As one example, your browser could ask your hardware wallet over BLE for
this data. This way you barely have to trust the computer you're using at
all, as everything it does is confirmed on the hardware wallet before
payment (assuming it has a screen, which it should). Linking your hardware
wallet over BLE to new devices which you then use for browsing and shopping
could be trivial and yet allow secure auto-fill of this kind.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150210/0b68ce7b/attachment.html>

2023-06-07 15:30:01

- reply

📅 Original date posted:2015-02-10
📝 Original message:Den 10 feb 2015 11:48 skrev "MⒶrtin HⒶboⓋštiak" <martin.habovstiak at gmail.com
>:
>
> I still don't understand. The website can have this information
> available. This is exactly what e-bay does - it displays shipping
> information to my country before I do anything. What's the problem?
>
> Also with other stuff, website can do it and browser extension can do
> it too without messing with Bitcoin.
1: IP isn't guaranteed to work correctly both because you might be using a
VPN out Tor.
2: Yes, the site can display all options right away, but are you willing to
read all of them too?
3: Detailed information is not necessary, nor does it have to be
unprompted. It doesn't need to tell you more than which country you are in.
It can even prompt you with a popup that has a slider that shows exactly
how much information and of what kind you're about to share (including
none, if that's your choice).
4: It doesn't need to share raw data. Take a look at anonymous credentials:
http://www.zurich.ibm.com/idemix/
https://eprint.iacr.org/2013/622.pdf
5: It can wait for prompting until you add the first item to the cart.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150210/78a386c4/attachment.html>

2023-06-07 15:30:00

- reply

📅 Original date posted:2015-02-10
📝 Original message:Den 10 feb 2015 11:34 skrev "MⒶrtin HⒶboⓋštiak" <martin.habovstiak at gmail.com
>:
>
> Why would anyone want to do anything about payment before choosing
> what he wants to buy and for what price? I've never used Amazon but
> isn't filling a form with shipping information enough?
That's not what this is about.
BIP70 isn't just payment, it is about communication the terms of the sale.
Let's say you're visiting an international webshop. But they don't ship to
your country. Wouldn't you want to know that before your start filling the
cart? With this, your wallet / browser extension could tell you right away
that you can't shop there. No time wasted!
That's just one requirement of many where you would benefit from being told
right away if it is acceptable for both parties or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150210/e3d47eb0/attachment.html>

2023-06-07 15:30:00

- reply

📅 Original date posted:2015-02-10
📝 Original message:BIP70 is a protocol for getting a user's wallet client communicate with a
merchant's server in order to agree on details like where to send the
payment, how much to send, what the shipping address is, sending a receipt
back, and much more using various extensions that adds more functionality.
There could even be advanced functionality for automatically negotiating
terms. One example could be selecting a multisignature arbitrator both
sides trust. Another could be to agree on the speed and type of delivery.
Many more types of decisions could be automatically agreed upon.
But as it is now, it is designed to be initiated at the time of payment. If
you always want next-day delivery from online stores then you won't always
know if that's an option until you've filled the digital basket and gone
through checkout. If you only want to shop with an arbitrator involved same
thing applies.
Everything that BIP70 enables happens at the last step only, as it is right
now.
If there could be a BIP70 HTML tag on web shops that automatically
triggered your wallet as soon as you visit the page, it would be possible
for a browser extension that talks to your wallet to tell you right away if
the web shop you're currently looking at has terms you consider acceptable
or not (note: if your wallet client isn't installed on or linked to that
same machine, a visible Qr code would be an acceptable alternative which
you can scan in advance before you start shopping). This notification can
even be automatically updated as you add and remove things from your cart
and details like shipping options change.
This would massively simplify the shipping experience and make every web
shop feel like Amazon.
Of course this has privacy implications and increases exposure to potential
wallet exploits, but the wallet can ask you if you intend to shop or not at
each site before it even connects and send any information at all in order
to mitigate both of those problems. This way it should be reasonably safe.
Another option would be to automatically connect but limit what data is
sent in order to remain privacy preserving, until the user agrees to send
private information.
This second method would also open up for the merchant to other send
relevant information such as details about various certifications from
third parties, which can include a certification that shows they have been
been audited and approved by by entity X for purpose Y. If your wallet has
that entity whitelisted it will show you that certificate (for example
"Acme Audits have audited and approves of Merchant M's privacy policy and
data protection"). With a list of predefined types of certifications that
the wallet understand and accepts, it could (by choice of the user) require
a certificate to be present to even allow you to make a purchase (lack of
required certifications would result in automatic denial). No certificate =
your wallet never proceed to send private information.
Thoughts?
- Sent from my tablet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150210/db065fa8/attachment.html>

2023-06-07 15:29:12

- reply

📅 Original date posted:2015-01-31
📝 Original message:Den 1 feb 2015 00:05 skrev "Brian Erdelyi" <brian.erdelyi at gmail.com>:
>>
>> See vanitygen. Yes, 8 characters can be brute forced.
>
> Thank you for this reference. Interesting to see that there is a tool to
generate a vanity bitcoin address.
>
> I am still researching viruses that are designed to manipulate a bitcoin
address. I suspect they are primitive in that they use a hardcoded rogue
bitcoin address as opposed to dynamically generating one.
>
> As a start, this would help protect against malware that uses a static
rogue bitcoin address. The next thing would be for the malware to
brute-force the legitimate bitcoin address and generate a rogue bitcoin
address that would produce the same 8 digit code. Curious to know how long
this brute force would take? Or perhaps, before converting to 8 digits
there is some other hashing function that is performed.
>
> Brian Erdelyi
To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000 tries.
log(50M)/log(2) = 25.6 bits of entropy.
One try = generate a random number, use it to generate an ECDSA keypair,
SHA256 and RIPEMD160 hash the public key per Bitcoin specs, then run that
OCRA hashing code, then compare strings. Considering the ECDSA operations
is by a large margin slower than all the hash functions, consider them to
just add a small percentage in performance drop vs regular vanitygen usage.
My non-gaming laptop performed IIRC at *a few million keys per second* with
OpenCL. I've used it to search for 6 character strings in the base58
Bitcoin addresses with it in 15 minutes to half an hour or so. That's about
35 bits of entropy (rough estimate, there's some details with padding in
the base58 representation that alters it).
So 2^(35-26) ~= 1 in 500 of that time, and that's if you use a laptop
instead of a GPU rig. Seconds at worst. Milliseconds if done on a rig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150201/aaf8f5e0/attachment.html>

2023-06-07 15:29:12

- reply

📅 Original date posted:2015-01-31
📝 Original message:Den 31 jan 2015 23:17 skrev "Brian Erdelyi" <brian.erdelyi at gmail.com>:
>
> Hello all,
>
> The number of incidents involving malware targeting bitcoin users
continues to rise. One category of virus I find particularly nasty is when
the bitcoin address you are trying to send money to is modified before the
transaction is signed and recorded in the block chain. This behaviour
allows the malware to evade two-factor authentication by becoming active
only when the bitcoin address is entered. This is very similar to how
man-in-the-browser malware attack online banking websites.
>
> Out of band transaction verification/signing is one method used with
online banking to help protect against this. This can be done in a variety
of ways with SMS, voice, mobile app or even security tokens. This video
demonstrates how HSBC uses a security token to verify transactions online.
https://www.youtube.com/watch?v=Sh2Iha88agE.
>
> Many Bitcoin wallets and services already use Open Authentication (OATH)
based one-time passwords (OTP). Is there any interest (or existing work)
in in the Bitcoin community adopting the OATH Challenge-Response Algorithm
(OCRA) for verifying transactions?
>
> I know there are other forms of malware, however, I want to get thoughts
on this approach as it would involve the use of a decimal representation of
the bitcoin address (depending on particular application). In the HSBC
example (see YouTube video above), this was the last 8 digits of the
recipient’s account number. Would it make sense to convert a bitcoin
address to decimal and then truncate to 8 digits for this purpose? I
understand that truncating the number in some way only increases the
likelihood for collisions… however, would this still be practical or could
the malware generate a rogue bitcoin address that would produce the same 8
digits of the legitimate bitcoin address?
See vanitygen. Yes, 8 characters can be bruteforced.
You need about 100 bits of security for strong security, and at the very
least NOT less than ~64 (see distributed bruteforce projects attacking 64
bit keys for reference, you can find plenty via Google).
You shouldn't rely on mechanisms intended to be used for one-shot auth
where the secret is supposed to be unguessable for another system where the
attacker knows what the target string is and have a fair amount of time to
attempt bruteforce.
Use something more like HMAC instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150131/9343c650/attachment.html>

2023-06-07 15:29:12

- reply

📅 Original date posted:2015-01-31
📝 Original message:Den 1 feb 2015 00:37 skrev "Natanael" <natanael.l at gmail.com>:
>
> To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000
tries. log(50M)/log(2) = 25.6 bits of entropy.
Oops. Used the wrong number in the entropy calculation. Add one bit, the
division by 2 wasn't supposed to be used in the entropy calculation.
Doesn't change the equation much, though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150201/3fc6dca4/attachment.html>

2023-06-07 15:24:24

- reply

📅 Original date posted:2014-07-25
📝 Original message:Probably because the network isn't designed for interactive proofs. Most
interactive algoritms AFAICT requires that some machine holds a secret
state (or at least continuous and untampered state, but you still need to
verify you're falling to the right machine), otherwise the machine can be
mimicked and "rewound" to earlier states. Without a challenge-response that
can't be faked, you've got problems.
There's no trusted machines here that you can rely on. The certainty of
having the right blockchain is a statistical one over longer periods of
time, not enough for a PIN you want verified right now. So you can always
be shown an old copy, and if your node isn't up to date yet then it can
also be shown fake chains further into the future.
Maybe you could throw in some kind of Secure Multiparty Computation among
the miners to enable challenge-response, with state saved in the blockchain
(so it can't be rolled back), but that would be fragile. How do you select
what nodes may participate? How do you prevent the secret state from
leaking? And performance would be absolutely horrible, and reliability is a
huge problem.
Den 25 jul 2014 18:03 skrev "Mike Hearn" <mike at plan99.net>:
> Sorry, you're right. I'd have hoped a delay that doubles on failure each
> time up to some max would be good enough, relying on the p2p network to
> unlock a PIN feels weird, but I can't really quantify why or what's wrong
> with it so I guess it's just me :-)
>
>
> On Fri, Jul 25, 2014 at 4:45 PM, Aaron Voisine <voisine at gmail.com> wrote:
>
>> The problem is if someone moves system time forward between app launches.
>> The lockout period doesn't have to be all that precise, it just makes you
>> wait for the next block, then 5, then 25, and so on. Using a well
>> known time server over https would also be a good option, but the wallet
>> app already has the chain height anyway.
>>
>>
>> On Friday, July 25, 2014, Mike Hearn <mike at plan99.net> wrote:
>>
>>> Given that the speed at which the block chain advances is kind of
>>> unpredictable, I'd think it might be better to just record the time to disk
>>> when a PIN attempt is made and if you observe time going backwards, refuse
>>> to allow more attempts until it's advanced past the previous attempt.
>>>
>>>
>>> On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine <voisine at gmail.com>
>>> wrote:
>>>
>>>> It's based on the block height, not the block's timestamp. If you have
>>>> access to the device and the phone itself is not pin locked, then you
>>>> can jailbreak it and get access to the wallet seed that way. A pin
>>>> locked device however is reasonably secure as the filesystem is
>>>> hardware aes encrypted to a combination of pin+uuid. This was just an
>>>> easy way to prevent multiple pin guesses by changing system time in
>>>> settings, so that isn't the weakest part of the security model.
>>>>
>>>> Aaron Voisine
>>>> breadwallet.com
>>>>
>>>>
>>>> On Thu, Jul 24, 2014 at 8:21 PM, William Yager <will.yager at gmail.com>
>>>> wrote:
>>>> > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell at gmail.com
>>>> >
>>>> > wrote:
>>>> >>
>>>> >>
>>>> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
>>>> >> this sounds like security theater.... I attach a debugger to the
>>>> >> process (or modify the program) and ignore the block sourced time.
>>>> >>
>>>> >
>>>> > It's an iOS application. I would imagine it is substantially more
>>>> difficult
>>>> > to attach to a process (which, at the very least, requires root, and
>>>> perhaps
>>>> > other things on iOS) than to convince the device to change its system
>>>> time.
>>>> >
>>>> > That said, the security benefits might not be too substantial.
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> > Want fast and easy access to all the code in your enterprise? Index
>>>> and
>>>> > search up to 200,000 lines of code with a free copy of Black Duck
>>>> > Code Sight - the same software that powers the world's largest code
>>>> > search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> > http://p.sf.net/sfu/bds
>>>> > _______________________________________________
>>>> > Bitcoin-development mailing list
>>>> > Bitcoin-development at lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>>
>>
>> --
>>
>> Aaron Voisine
>> breadwallet.com
>>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140725/73dd20cb/attachment.html>

2023-06-07 15:22:50

- reply

📅 Original date posted:2014-06-18
📝 Original message:Den 17 jun 2014 17:59 skrev "Isidor Zeuner" <cryptocurrencies at quidecco.de>:
>
> quote:
> > Mike Hearn, why don't we just have all nodes report attempted double
spends
> > through the node network. No need to involve the miners at all really,
or
> > do your suggestion but also report the double spend attempt. By waiting
> > maybe 10-60 seconds (instead of 10 minutes for first conf), merchants
can
> > be more sure that a double spend attack was not tried. Attacker would
have
> > to hold back second tx by 10-60 seconds and hope that that second tx
(with
> > higher fee) get's into a solved block before the first one. This forced
> > delay time ought to make the attack less successful (but not
impossible).
> >
>
> What prevents the following steps from happening:
>
> 1. attacker sends first transaction, paying to the merchant
>
> 2. merchant waits 10-60 seconds
>
> 3. merchant confirms the payment as received
>
> 4. attacker sees merchant's confirmation
>
> 5. attacker sends double spend
>
> The security improvement seems to be pretty much exactly the chance
> that during the 10-60 seconds, a block is solved. Am I missing
> something?
>
> Regarding "reporting double spends", this would only help if it comes
> with some kind of penalty for the double spend. Now what if the double
> spend was not done on malicious motives? Maybe someone posted a
> transaction which does not confirm for some reason, and wants to
> recover his funds? Should we regard transactions which do not confirm
> as forever lost, in order to get to an "every double spend is a
> misbehaviour" policy?
>
> Best regards,
>
> Isidor
With 2-of-2 multisignature notaries, the doublespend (the set of
conflicting transactions) would be published and propagated together as
evidence of the notary being malicious. This is trivial and self-evident
self-contained proof.
But there should be no direct penalty IMHO in the Bitcoin protocol itself.
If a transaction would have to be replaced honestly because of being wrong
or simply not confirming, then I think there should be some means of
showing the second transaction is "legitimate". Don't ask me how exactly it
would work in practice, but one method could be through showing the
original recipients have signed off on it (showing they agree it should be
reversed).
If you can't get the original recipient to sign, then you're stuck with
either not replacing it or the notary trying to prove the replacing
transaction was legitimate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140618/527586ea/attachment.html>

2023-06-07 15:21:36

- reply

📅 Original date posted:2014-05-18
📝 Original message:The problem with not involving any electronics is that somebody needs to
generate a recoverable private key that we have to trust haven't recovered
the private key.
The only plausible solution is multisignature P2SH addresses where you
trust several independent entities to not collude instead, where you
combine their paper notes into one piece. And then you still don't know if
all the private keys are recoverable to you (failed print?).
- Sent from my phone
Den 18 maj 2014 20:48 skrev "Alex Kotenko" <alexykot at gmail.com>:
> Erm, few things here.
> - I can't see really how to embed electronics capable to run an SPV
> client into printed paper. I know that passive NFC tags can be printed on
> paper, but not actual chips and/or power modules. So we are talking about a
> completely different things here.
> - even with paper notes printed proprietarily by some business the notes
> itself still can have routes for independent blockchain-based verification,
> and you won't need to trust anybody to test it. You will have to trust
> security of the notes itself, but this is same as when you trust the phone
> manufacturer when you're putting your bitcoin wallet on it.
>
> So really I see only issues of technical security in here, and this is
> the problem I'm seeking solutions for.
>
>
> Best regards,
> Alex Kotenko
>
>
> 2014-05-18 14:50 GMT+01:00 Natanael <natanael.l at gmail.com>:
>
>> Now you are talking about Trusted Platform Modules. Like smartcards,
>> actually. Devices that won't leak their keys but let the holder spend the
>> coins. It could even have it's own simple SPV wallet client to make it
>> easier to handle. And they'd use the attestation features provided by the
>> TPM to prove the software it's unmodified top the current holder.
>>
>> But then you still have to trust the manufacturer of the device, and you
>> have to trust it has no exploitable side channels.
>>
>> - Sent from my phone
>> Den 18 maj 2014 13:52 skrev "Alex Kotenko" <alexykot at gmail.com>:
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140518/5b4cc866/attachment.html>

2023-06-07 15:21:35

- reply

📅 Original date posted:2014-05-18
📝 Original message:Now you are talking about Trusted Platform Modules. Like smartcards,
actually. Devices that won't leak their keys but let the holder spend the
coins. It could even have it's own simple SPV wallet client to make it
easier to handle. And they'd use the attestation features provided by the
TPM to prove the software it's unmodified top the current holder.
But then you still have to trust the manufacturer of the device, and you
have to trust it has no exploitable side channels.
- Sent from my phone
Den 18 maj 2014 13:52 skrev "Alex Kotenko" <alexykot at gmail.com>:
> I had a long discussion recently with somebody who wants and has resources
> to do exactly this - paper currency representing bitcoins. Yet we've been
> thinking mostly about a centralized solution, where one party is producing
> and maintaining paper currency, with bitcoins tied to each note verifiable
> via blockchain.
>
> The points we've ended up is that it needs to be:
> - reloadable
> - NFC based
> So anybody can verify any notes instantly by just touching it with his
> phone, and so merchants could redeem the notes at the moment of accepting
> it, convert it into fully online bitcoins and avoid costs of maintaining
> paper money turnover. Probably merchant would sell back redeemed
> empty notes to the issuer for a price of the note issue, and issuer will
> recharge it and put back into circulation.
>
> One problem we couldn't figure out here though - how to protect the notes
> from unauthorized redeem. Like if someone else tries to reach your wallet
> with his own NFC - how can we distinguish between deliberate redeem by
> owner and fraudulent redeem by anybody else with custom built long
> range NFC antenna? Any ideas?
>
>
> Best regards,
> Alex Kotenko
>
>
> 2014-05-17 17:40 GMT+01:00 Gregory Maxwell <gmaxwell at gmail.com>:
>
>> On Sat, May 17, 2014 at 9:07 AM, Chris Pacia <ctpacia at gmail.com> wrote:
>> > I can't really just hand someone the note and walk away
>> > because they have to scan it to see if it is actually valid.
>>
>> Not just scan it, but they actually must successfully sweep it—
>> otherwise they can be trivially double spent. This is especially bad
>> since any prior bearer can perform such an attack. E.g. record the
>> private key of everyone that passes through your hands and then
>> doublespend race any redemption that happens >24 hours after you spend
>> them. The wrong person would likely be blamed and even if you were
>> blamed you could plausibly deny it ("Must have been the guy that gave
>> it to me!").
>>
>> Othercoin seems to have much better properties in the space of offline
>> transactions: https://bitcointalk.org/index.php?topic=319146.0
>>
>> Separately, Cassius also ran into some regulatory issues selling
>> physical bitcoin artifacts. Especially printing things that seem to be
>> redeemable for a named USD value sounds especially problematic.
>>
>> Some random comments— The base58 encoding is fairly human unfriendly.
>> It's fine for something being copy and pasted, but I've found typing
>> or reading it works poorly due to mixed case. I expect the A/B side
>> to be difficult to educate users about. "This side is private" is more
>> easily understood, you could just pick one of your sides and call it
>> private. I find it kind of odd that this design seems to have no
>> facility for checking its txouts without recovering the private key,
>> though considering no one should rely on such a measurement without
>> sweeping perhaps thats for the best.
>>
>> (As far as the numbering goes, I think you should be calling these
>> draft-felix-paper-currency etc. As a matter of hygienic practice I
>> will not assign a matching bip number for something that went public
>> with a number outside of the assignment.)
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform
>> available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140518/62c97e9d/attachment.html>

2023-06-07 15:18:54

- reply

📅 Original date posted:2014-04-22
📝 Original message:I am in favor of xbit, my only concern is if average Joes will consider
that name "stupid" (like various attempts at "cool" branding with unusual
letters like Q, X, Z, etc). We should see if we can get support for it in
the community and if there would be any notable opposition against it or
not. If there's no significant opposition and most people are in favor, I'd
say go ahead.
- Sent from my phone
Den 21 apr 2014 11:38 skrev "Tamas Blummer" <tamas at bitsofproof.com>:
> Thomas V:
>
> Your proposal misses the points that:
>
> - this is about a unit with 1e-6 Bitcoins or 100 satoshis.
> - it is not about people who know Bitcoin and are techies, but about those
> who don’t and aren’t.
>
> The reasons for such a unit are more than shifting the comma some places
> for convinience,
> but to align Bitcoin with capabilities of existing financial software and
> customs of finance and average people,
> and ISO standard of currency abbreviations.
>
> bit and XBT seems to check the boxes.
>
> I would love to have some feedback on xbit as per my previous mail.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/101e72c4/attachment.html>

2023-06-07 15:18:10

- reply

📅 Original date posted:2014-04-09
📝 Original message:This could probably be done fairly easily by bundling Stratum (it's
not just for pools!) and allowing SPV wallets to ask Bitcoind to start
it (if you don't use it, there's no need to waste the resources), and
then connect to it. The point of using Stratum is that it already is
being used by Electrum, and that it might be an easier way to support
SPV clients than creating a new API in bitcoind for it since Stratum
itself already relies on bitcoind to provide it's services.
On Wed, Apr 9, 2014 at 5:29 PM, Wladimir <laanwj at gmail.com> wrote:
> Hello,
>
> This is primarily aimed at developers of SPV wallets.
>
> The recently reported decrease in number of full nodes could have several
> reasons, one of them that less people are running Bitcoin Core for the
> wallet because the other wallets are getting ahead in both features and
> useability.
>
> It's great to see innovation in wallets, but it's worrying that the number
> of full nodes decreases.
>
> It may be that lots of people would support the network by running a full
> node, but don't want to go through the trouble of installing bitcoin core
> separately (and get confused because it's a wallet, too).
>
> Hence I'd like to explore the idea of adding an option to popular SPV
> wallets, to spin a bitcoind process in the background. This could be pretty
> much transparent to the user - it would sync in the background, the wallet
> could show statistics about the node, but is not dependent on it.
>
> In exchange the user would get increased (full node level) security, as the
> SPV wallet would have a local trusted node.
>
> Does this sound like a good idea?
>
> Is there any way that Bitcoin Core can help to accomedate this 'embedded'
> usage? Specific Interfaces, special builds - maybe add a walletless bitcoind
> build to gitian - bindings, dlls, etc?
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:16:48

- reply

📅 Original date posted:2014-03-31
📝 Original message:This sounds like Namecoin. You can already register profiles with it,
including keypairs. onename.io is a web-based client you can use to
register on the Namecoin blockchain.
On Mon, Mar 31, 2014 at 1:14 PM, Chris D'Costa <chris.dcosta at meek.io> wrote:
> Security of transmission of person-to-person pay-to addresses is one of the use cases that we are addressing on our hardware wallet.
>
> I have yet to finish the paper but in a nutshell it uses a decentralised ledger of, what we refer to as, "device keys".
>
> These keys are not related in any way to the Bitcoin keys, (which is why I'm hesitating about discussing it here) neither do they even attempt to identify the human owner if the device. But they do have a specific use case and that is to provide "advanced knowledge" of a publickey that can be used for encrypting a message to an intended recipient, without the requirement for a third-party CA, and more importantly without prior dialogue. We think it is this that would allow you to communicate a pay-to address to someone without seeing them in a secure way.
>
> As I understand it the BlockChain uses "time" bought through proof of work to establish a version of the truth, we are using time in the reverse sense : advanced knowledge of all pubkeys. Indeed all devices could easily check their own record to identify problems on the ledger.
>
> There is of course more to this, but I like to refer to the "distributed ledger of device keys" as the "Web-of-trust re-imagined" although that isn't strictly true.
>
> Ok there you have it. The cat is out of the bag, feel free to give feedback, I have to finish the paper, apologies if it is not a topic for this list.
>
> Regards
>
> Chris D'Costa
>
>
>> On 31 Mar 2014, at 12:21, vv01f <vv01f at riseup.net> wrote:
>>
>> Some users on bitcointalk[0] would like to have their vanity addresses
>> available for others easily to find and verify the ownership over a kind
>> of WoT. Right now they sign their own addresses and quote them in the
>> forums.
>> As I pointed out there already the centralized storage in the forums is
>> not secury anyhow and signed messages could be swapped easily with the
>> next hack of the forums.
>>
>> Is that use case taken care of in any plans already?
>>
>> I thought about abusing pgp keyservers but that would suit for single
>> vanity addresses only.
>> It seems webfinger could be part of a solution where servers of a
>> business can tell and proof you if a specific address is owned by them.
>>
>> [0] https://bitcointalk.org/index.php?topic=502538
>> [1] https://bitcointalk.org/index.php?topic=505095
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:16:47

- reply

📅 Original date posted:2014-03-31
📝 Original message:Does't BIP70 cover this already via Certificate Authorities?
On Mon, Mar 31, 2014 at 12:21 PM, vv01f <vv01f at riseup.net> wrote:
> Some users on bitcointalk[0] would like to have their vanity addresses
> available for others easily to find and verify the ownership over a kind
> of WoT. Right now they sign their own addresses and quote them in the
> forums.
> As I pointed out there already the centralized storage in the forums is
> not secury anyhow and signed messages could be swapped easily with the
> next hack of the forums.
>
> Is that use case taken care of in any plans already?
>
> I thought about abusing pgp keyservers but that would suit for single
> vanity addresses only.
> It seems webfinger could be part of a solution where servers of a
> business can tell and proof you if a specific address is owned by them.
>
> [0] https://bitcointalk.org/index.php?topic=502538
> [1] https://bitcointalk.org/index.php?topic=505095
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:16:44

- reply

📅 Original date posted:2014-03-29
📝 Original message:Den 29 mar 2014 19:15 skrev "Matt Whitlock" <bip at mattwhitlock.name>:
>
> On Saturday, 29 March 2014, at 2:08 pm, Alan Reiner wrote:
> > Regardless of how SSSS does it, I believe that obfuscating that
> > information is bad news from a usability perspective. Undoubtedly,
> > users will make lots of backups of lots of wallets and think they
> > remember the M-parameter but don't. They will accidentally mix in some
> > 3-of-5 fragments with their 2-of-4 not realizing they are incompatible,
> > or not able to distinguish them. Or they'll distribute too many
> > thinking the threshold is higher and end up insecure, or possibly not
> > have enough fragments to restore their wallet thinking the M-value was
> > lower than it actually was.
> >
> > I just don't see the value in adding such complexity for the benefit of
> > obfuscating information an attacker might be able to figure out anyway
> > (most backups will be 2-of-N or 3-of-N) and can't act on anyway (because
> > he doesn't know where the other frags are and they are actually in
> > safe-deposit boxes)
>
> Okay, you've convinced me. However, it looks like the consensus here is
that my BIP is unneeded, so I'm not sure it would be worth the effort for
me to improve it with your suggestions.
I think it should be made an option (with the default being that the
threshold is given and verification is applied. There could certainly be a
few cases where the threshold is set high, you maybe don't have access to a
great enough variety of hiding spots or secure enough hiding spots, and you
want deter an attempt to find all the shares (with the idea being that the
risk of detection would be too high, in particular when you use tamper
evident seals). But for the majority it would be better to find a few
different safeboxes to put the shares in and rely on physical security.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/d96201a7/attachment.html>

2023-06-07 15:15:40

- reply

📅 Original date posted:2014-03-14
📝 Original message:Regarding (ISO standards) currency symbols, XBT is already used as
equivalent to 1 Bitcoin in numerous places, and XBC is taken and BT*
belongs to Bhutan (and X** is already the default for non-national currency
common items of trade), so IMHO we should define something like XUB as
microbitcoins so we can have a symbol that doesn't require changing any
existing systems and that can be standardized globally. Then those with
accounting software that needs to deal with something that has two decimals
maximum without losing precision can use that while following well defined
standards. And those who don't like large numbers can still chose to show
mBTC.
- Sent from my phone
Den 14 mar 2014 18:18 skrev "vv01f" <vv01f at riseup.net>:
> I think
> * if we change to mBTC because your state currencys price for bitcoin
> make this a valid option we will change again in future
> * users do not like changes
> * we should keep a good standard
>
> A good standard should be
> * built on standards (e.g. SI)
> * backed by best practice: never force the user to take an option he
> cannot change
> * do not make changes without users permission
> * take care of users at fault when entering 5.967 ot should be pointed
> out before sending that e.g.
> the sw understood 5967.000 000 00 BTC
> instead of 5.967 000 00 BTC
> because the user failed to use the correct delimiter.
>
> For now a good standard is
> * simply bitcoin as BTC with eight decimal places
> or could be
> * uBTC as SI prefix, probably using XBT as a symbol for compatibility
> with other software
> * satoshis (w. SI prefixes if numbers are to big) for regions where
> decimal places in prices are uncommon
>
> So I'd prefer:
> Make the choice transparent to users and set a standard that the user
> alway should be empowered to use all available decimal places.
> And there should be a set of official test-cases for wallet software and
> the desired behavior.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140314/563f1dde/attachment.html>

2023-06-07 15:14:46

- reply

📅 Original date posted:2014-03-06
📝 Original message:You've heard of TRESOR?
No, not Trezor.
https://en.wikipedia.org/wiki/TRESOR
Signing on the CPU, without touching RAM.
- Sent from my phone
Den 6 mar 2014 09:41 skrev "Mike Hearn" <mike at plan99.net>:
> I'm wondering about whether (don't laugh) moving signing into the kernel
> and then using the MTRRs to disable caching entirely for a small scratch
> region of memory would also work. You could then disable pre-emption and
> prevent anything on the same core from interrupting or timing the signing
> operation.
>
> However I suspect just making a hardened secp256k1 signer implementation
> in userspace would be of similar difficulty, in which case it would
> naturally be preferable.
>
>
> On Wed, Mar 5, 2014 at 11:25 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
>
>> On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo <elombrozo at gmail.com>
>> wrote:
>> > Everything you say is true.
>> >
>> > However, branchless does reduce the attack surface considerably - if
>> nothing else, it significantly ups the difficulty of an attack for a
>> relatively low cost in program complexity, and that might still make it
>> worth doing.
>>
>> Absolutely. I believe these things are worth doing.
>>
>> My comment on it being insufficient was only that "my signer is
>> branchless" doesn't make other defense measures (avoiding reuse,
>> multsig with multiple devices, not sharing hardware, etc.)
>> unimportant.
>>
>> > As for uniform memory access, if we avoided any kind of heap
>> allocation, wouldn't we avoid such issues?
>>
>> No. At a minimum to hide a memory timing side-channel you must perform
>> no data dependent loads (e.g. no operation where an offset into memory
>> is calculated). A strategy for this is to always load the same values,
>> but then mask out the ones you didn't intend to read... even that I'd
>> worry about on sufficiently advanced hardware, since I would very much
>> not be surprised if the processor was able to determine that the load
>> had no effect and eliminate it! :) )
>>
>> Maybe in practice if your data dependencies end up only picking around
>> in the same cache-line it doesn't actually matter... but it's hard to
>> be sure, and unclear when a future optimization in the rest of the
>> system might leave it exposed again.
>>
>> (In particular, you can't generally write timing sign-channel immune
>> code in C (or other high level language) because the compiler is
>> freely permitted to optimize things in a way that break the property.
>> ... It may be _unlikely_ for it to do this, but its permitted— and
>> will actually do so in some cases—, so you cannot be completely sure
>> unless you check and freeze the toolchain)
>>
>> > Anyhow, without having gone into the full details of this particular
>> attack, it seems the main attack point is differences in how squaring and
>> multiplication (in the case of field exponentiation) or doubling and point
>> addition (in the case of ECDSA) are performed. I believe using a branchless
>> implementation where each phase of the operation executes the exact same
>> code and accesses the exact same stack frames would not be vulnerable to
>> FLUSH+RELOAD.
>>
>> I wouldn't be surprised.
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries. Built-in WAN optimization and
>> the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/0e7136db/attachment.html>

2023-06-07 15:14:38

- reply

📅 Original date posted:2014-03-08
📝 Original message:You can always use a secure multiparty computation algorithm to do it.
https://en.wikipedia.org/wiki/Secure_multi-party_computation
But those aren't the fastest algorithms in the world, and usually both
participants needs to be online at the same time. I guess most people would
prefer a two-step algorithm that can be performed asynchronously.
- Sent from my phone
Den 8 mar 2014 18:44 skrev "Adam Back" <adam at cypherspace.org>:
> Also the other limitation for ECDSA is that there is no known protocol to
> create a signture with a+b (where keys P=aG, Q=bG, R=P+Q=(a+b)G). without
> either a sending its private key to b or viceversa (or both to a third
> party).
>
> With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a
> (secure)
> direct multiparty signature quite difficult.
>
> ps probably only 1 party needs to hash their key
>
> P=aG
> H(P) ->
>
> <- Q=bG
>
> P ->
>
> Adam
>
> On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote:
> > If both parties insist on seeing a hash of the other party's public key
> > before they'll show their own public key, they can be sure that the
> > public key is not chosen based on the public key they themselves
> > presented.
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140308/7bff5314/attachment.html>

2023-06-07 15:13:27

- reply

📅 Original date posted:2014-02-20
📝 Original message:You could pregenerate entire "trees" of alternative outcomes where you pick
one branch / chain to broadcast based on the real world events as they
happen.
But I see another problem regarding use of oracles, if you have a P2SH
address with 2-of-3 signatures or similar in the chain, amd some
transactions following it, then the oracle needs to pregenerate both
transactions for both outcomes in advance. But the oracle probably don't
want to actually share it in advance to any third party before the event
happened.
This can be solved if the oracle only shares the transaction hash in
advance and then hands out a Zero-knowledge proof of that transaction with
the given hash is following the agreed upon rules, so you can trust the
transaction chain anyway and still being able to pregenerate a full tree of
transactions.
And then the oracle will release one of the possible transactions after the
event in question has happened, so you can broadcast the chain of choice.
This unfortunately breaks down if the number of possible outcomes becomes
too many as you would need to both generate and store a tree of possible
outcomes that is massive.
- Sent from my phone
Den 20 feb 2014 02:29 skrev "Allen Piscitello" <allen.piscitello at gmail.com>:
> This is somewhat problematic in my use case since some parts need to be in
> the chain earlier than others and have the same ID as expected.
>
> https://bitcointalk.org/index.php?topic=260898.10
>
> I haven't gone back to see if there are any ways around it, but the main
> problem here is I need the Contract TX to be in the chain much earlier than
> redeeming, but I need the refund transaction to be in the chain much
> earlier. Perhaps there are some tricks to pull off to get it to work, but
> I haven't been working on this for a while so I'm a bit rusty in that area.
>
> This might be helpful enough to help a lot of use cases, but shouldn't be
> final.
>
> -Allen
>
> On Wed, Feb 19, 2014 at 6:22 PM, Natanael <natanael.l at gmail.com> wrote:
>
>> Regarding chains of transactions intended to be published at once
>> together, wouldn't it be easier to add a "only-mine-with-child flag"?
>>
>> That way the parent transactions aren't actually valid unless spent
>> together with the transaction that depends on it, and only the original
>> will have a child referencing it.
>>
>> Then malleability is not an issue at all for transaction chains if you
>> only need to broadcast your full transaction chain once, and don't need to
>> extend it in two or more occasions, *after* broadcasting subchains to the
>> network, from the same set of pregenerated transactions.
>>
>> If you need to broadcast pregenerated subchains separately, then you need
>> the last child in the chain to be non-malleable.
>>
>> This would require all miners to start to respect it at once in order to
>> avoid forking the network.
>>
>> - Sent from my phone
>> Den 19 feb 2014 22:13 skrev "Pieter Wuille" <pieter.wuille at gmail.com>:
>>
>> On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager at mac.com>
>>> wrote:
>>> > I think that we could guarantee fewer incidents by making version 1
>>> transactions unmalleable and then optionally introduce a version 3 that
>>> supported the malleability feature. That way most existing problematic
>>> implementations would be fixed and no doors were closed for people
>>> experimenting with other stuff - tx v 3 would probably then be called
>>> experimental transactions.
>>>
>>> Just to be clear: this change is not directly intended to avoid
>>> "incidents". It will take way too long to deploy this. Software should
>>> deal with malleability. This is a longer-term solution intended to
>>> provide non-malleability guarantees for clients that a) are upgraded
>>> to use them b) willing to restrict their functionality. As there are
>>> several intended use cases for malleable transactions (the sighash
>>> flags pretty directly are a way to signify what malleabilities are
>>> *wanted*), this is not about outlawing malleability.
>>>
>>> While we could right now make all these rules non-standard, and
>>> schedule a soft fork in a year or so to make them illegal, it would
>>> mean removing potential functionality that can only be re-enabled
>>> through a hard fork. This is significantly harder, so we should think
>>> about it very well in advance.
>>>
>>> About new transaction and block versions: this allows implementing and
>>> automatically scheduling a softfork without waiting for wallets to
>>> upgrade. The non-DER signature change was discussed for over two
>>> years, and implemented almost a year ago, and we still notice wallets
>>> that don't support it. We can't expect every wallet to be instantly
>>> modified (what about hardware wallets like the Trezor, for example?
>>> they may not just be able to be upgraded). Nor is it necessary: if
>>> your software only spends confirmed change, and tracks all debits
>>> correctly, there is no need.
>>>
>>> --
>>> Pieter
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140220/00054c41/attachment.html>

2023-06-07 15:13:26

- reply

📅 Original date posted:2014-02-19
📝 Original message:Regarding chains of transactions intended to be published at once together,
wouldn't it be easier to add a "only-mine-with-child flag"?
That way the parent transactions aren't actually valid unless spent
together with the transaction that depends on it, and only the original
will have a child referencing it.
Then malleability is not an issue at all for transaction chains if you only
need to broadcast your full transaction chain once, and don't need to
extend it in two or more occasions, *after* broadcasting subchains to the
network, from the same set of pregenerated transactions.
If you need to broadcast pregenerated subchains separately, then you need
the last child in the chain to be non-malleable.
This would require all miners to start to respect it at once in order to
avoid forking the network.
- Sent from my phone
Den 19 feb 2014 22:13 skrev "Pieter Wuille" <pieter.wuille at gmail.com>:
> On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager at mac.com>
> wrote:
> > I think that we could guarantee fewer incidents by making version 1
> transactions unmalleable and then optionally introduce a version 3 that
> supported the malleability feature. That way most existing problematic
> implementations would be fixed and no doors were closed for people
> experimenting with other stuff - tx v 3 would probably then be called
> experimental transactions.
>
> Just to be clear: this change is not directly intended to avoid
> "incidents". It will take way too long to deploy this. Software should
> deal with malleability. This is a longer-term solution intended to
> provide non-malleability guarantees for clients that a) are upgraded
> to use them b) willing to restrict their functionality. As there are
> several intended use cases for malleable transactions (the sighash
> flags pretty directly are a way to signify what malleabilities are
> *wanted*), this is not about outlawing malleability.
>
> While we could right now make all these rules non-standard, and
> schedule a soft fork in a year or so to make them illegal, it would
> mean removing potential functionality that can only be re-enabled
> through a hard fork. This is significantly harder, so we should think
> about it very well in advance.
>
> About new transaction and block versions: this allows implementing and
> automatically scheduling a softfork without waiting for wallets to
> upgrade. The non-DER signature change was discussed for over two
> years, and implemented almost a year ago, and we still notice wallets
> that don't support it. We can't expect every wallet to be instantly
> modified (what about hardware wallets like the Trezor, for example?
> they may not just be able to be upgraded). Nor is it necessary: if
> your software only spends confirmed change, and tracks all debits
> correctly, there is no need.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140220/d3b847d3/attachment.html>

2023-06-07 15:13:00

- reply

📅 Original date posted:2014-02-04
📝 Original message:Because it's trivial to create collisions! You can choose exactly what
output you want. That's why XOR is a very bad digest scheme.
- Sent from my phone
Den 4 feb 2014 14:20 skrev "Peter Todd" <pete at petertodd.org>:
> On Tue, Feb 04, 2014 at 02:13:12PM +0100, Mike Hearn wrote:
> > Hah, good point. If nobody completes the homework, I'll post a fixed
> > version tomorrow :)
>
> Heh, here's another 25mBTC while we're at it:
>
>
> https://github.com/opentimestamps/opentimestamps-client/commit/288f3c17626974de7eaef4f1c9b5cd93eecf40f6
>
> Why is that a bad idea?
>
> Bonus question: What was I smoking? (hint: where do I live?)
>
> > On Tue, Feb 4, 2014 at 2:03 PM, Peter Todd <pete at petertodd.org> wrote:
> >
> > > On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote:
> > > > Hello,
> > > >
> > > > I'm pleased to announce the release of bitcoinj 0.11, a library for
> > > writing Bitcoin applications that run on the JVM. BitcoinJ is widely
> used
> > > across the Bitcoin community; some users include Bitcoin Wallet for
> > > Android, MultiBit, Hive, blockchain.info, the biteasy.com block
> explorer
> > > (written in Lisp!), Circle, Neo/Bee (Cypriot payment network),
> bitpos.me,
> > > Bitcoin Touch, BlueMatt's relay network and DNS crawler, academic
> advanced
> > > contracts research and more.
> > > >
> > > > The release-0.11 git tag is signed by Andreas Schildbach's GPG key.
> The
> > > commit hash is 410d4547a7dd. This paragraph is signed by the same
> Bitcoin
> > > key as with previous releases (check their release announcements to
> > > establish continuity). Additionally, this email is signed using DKIM
> and
> > > for the first time, a key that was ID verified by the Swiss government.
> > > >
> > > > Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m
> > > > Signature for last paragraph:
> > >
> H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg=
> > >
> > > The above makes for a great homework problem for budding
> cryptographers:
> > > Why did the three forms of signature, DKIM, long-lived bitcoin address,
> > > and Official Swiss Government Identity fail to let you actually verify
> > > you have the right code? (but make for great security theater)
> > >
> > > Bonus question: Who has the smallest work-factor for such an attack?
> > >
> > > Two rewards of 25mBTC for correct responses to each question from a
> > > crypto newbie.
> > >
> > > > Thanks to Mike Belshe, the wallet can now send to P2SH addresses.
> > >
> > > Thanks
> > >
> > > > Generated signatures now use canonical S values. This will aid a
> future
> > > hard-forking rule change which bans malleable signatures.
> > >
> > > Soft-forking rule change.
> > >
> > > --
> > > 'peter'[:-1]@petertodd.org
> > > 000000000000000075829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0
> > >
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000075829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140204/a609d169/attachment.html>

2023-06-07 15:12:26

- reply

📅 Original date posted:2014-01-22
📝 Original message:Couldn't we also use the type of zkSNARK's that Zerocoin adopted to
prove that the hash-only blocks only have valid transactions in it,
since they are small and quite efficient to verify? The trouble is
that they're still inefficient to generate, but given powerful enough
computers that compiles the hashes for the block and it could likely
still be done fast enough to handle large amounts of transactions. The
computer is likely not going to be the most expensive part anyway by a
far margin.
zkSNARK = zero-knowledge Succinct Non-interactive ARgument of Knowledge
On Wed, Jan 22, 2014 at 10:06 PM, bc <bc at bcdev.net> wrote:
> Pdf version:
> http://bcdev.net/data/bitcoin_big_tx_with_coin_join.pdf
>
>
> == Combining big transactions with hash-only blocks to improve tps. ==
>
> ==== Abstract: ====
> I've heard people talk about including only hashes in a block to speed
> up the network and also about using CoinJoin to improve privacy. I've
> not heard anyone talk about implications of combining these two
> techniques. I think that it would both improve network's anonymity, but
> also improve tps by a few orders of magnitude.
>
> I propose two optimizations:
> 1. Keep only hashes of transactions included in a block. Transfer all tx
> separately.
> 2. Use CoinJoin to merge transactions from many users for online
> shopping and banking.
> 3. Use Jumbo transactions as a fallback for applications where CoinJoin
> is inappropriate.
>
> ==== Keeping only hashes of tx in a block: ====
> Currently every bitcoin block includes a copy of all transactions. This
> is redundant and unnecessary, since after the transaction gets
> transmitted, every node learns about it in seconds.
> By keeping only transaction hashes in block, we can keep block
> propagation time from increasing.
> Assuming a typical tx with one or two inputs and two outputs [typically
> 300 bytes], current 1MiB block can contain about [assuming a block every
> 10 minutes]:
> 1MiB / 300 bytes = 3300tx = 5.5tps
>
> By keeping only hashes in a block [32 bytes per hash]:
> 1MiB / 32 bytes = 31000tx = 50tps
>
> == Benefits: ==
> This method allows to achieve more tps without increasing the block
> propagation time, which is critical for mining decentralization.
> It removes redundancy, since every tx has to be transmitted only once.
> It leads to a more consistent bandwidth utilization [large transactions
> are transmitted all the time, while blocks are kept small and easy to
> propagate].
> Because a block size is a constant, mining fees would not depend on the
> size of a transaction. Obviously to limit the network flood, there
> should be a transaction size limit.
>
> == Problems: ==
> Selfish miner can keep a subset of transactions only for yourself and
> release them only with a new block. This problem can be mitigated by
> making nodes verify all transactions before propagating a block. The
> incentive will then be to mine only a well-distributed transactions to
> lower orphan rate.
> The miner can try to sneak up invalid transaction in a block. This
> problem is also mitigated by not accepting a block before it gets verified.
>
> ==== CoinJoin: ====
> If the block size keeps only hashes, a transaction can be much bigger.
> Since CoinJoin allows many people to send coins with one transaction,
> the effective transaction rate can be increased considerably.
>
> == Example: ==
> Let's assume the transaction size limit of 50KiB. Limit of this size
> allows for a CoinJoin transaction between 50KiB / 300b = 170 participants.
> So for a block of 1MiB, it would allow for 50tps *
> 170effective_transactions/tx = 8500tps.
>
> == Benefits: ==
> There would be an incentive for users to use CoinJoin by default [lower
> tx fees per effective transaction], which would greatly increase
> anonymity of the network.
> Since block size stays the same, block propagation time also stays the same.
> It doesn't require any changes to the protocol. CoinJoin transactions
> were always supported in bitcoin.
>
> == Problems: ==
> 1) CoinJoin requires collaboration between many users in real-time. It
> means, that transaction must be distributed to every CoinJoin
> participant, and every participant has to sign it before it can be
> released. Therefore it induces delays, which can take some time.
> It wouldn't be an issue with Internet banking or on-line shopping [where
> even 10 minutes per transaction is fast enough], however even 20 seconds
> can make the system unsuitable for POS payments.
> Potential solution: Use bigger CoinJoin user base for online payments
> [with smaller fees], and a smaller one for POS payments [with larger fees].
>
> 2) Signing a CoinJoin transaction requires to transfer a whole
> transaction for a user to sign.
> This can sometimes take up to a few minutes on a very slow networks.
>
> 3) CoinJoin transactions are limited. They are good enough for money
> transfer, but for more advanced appliances CoinJoin might be inadequate.
>
> ==== Jumbo transactons: ====
> I propose another tx type as a fallback where CoinJoin is not Combining
> big transactions with hash-only blocks to improve tps.applicable. It
> would remove the CoinJoin induced delays, while keeping transaction
> sizes big.
>
> Image: http://bcdev.net/data/jubo_transaction_description.png
>
> Transaction joiner is a service that collects transactions from clients
> and publishes them as a Jumbo transaction.
> Jumbo pubkey prevents transaction from being modified. It can only be
> accepted or rejected by the miner as a whole, which should limit
> discrimination.
>
> == Algorithm: ==
> 1) Transaction joiner sends a Jumbo pubkey hash to the client.
> 2) Client creates a transaction, includes a Jumbo pubkey hash and signs it.
> 3) Transaction joiner waits until there are enough transactions and
> releases a Jumbo transaction to the network.
> 4) A miner includes only a hash of a Jumbo transaction in a block, he
> cannot cherry-pick individual transactions from the bulk.
> 5) The network checks if every transaction inside a Jumbo transaction
> includes a Jumbo pubkey hash and if every transaction inside is valid.
>
> == Benefits: ==
> Since the block size stays the same, block propagation time also stay
> the same.
> There is no need to wait for every participant to sign the transaction.
> It's therefore more suitable for POS payments.
> No additional network overhead for a thin client compared to a standard tx.
> Backwards compatibility with current transaction system.
>
> == Problems: ==
> 1) Jumbo transactions don't mix coins. Anonymity of the network is not
> increased.
> 2) There would be an incentive to use this transaction type by default
> [compared to CoinJoin].
>
> Potential solution:
> Make Jumbo transaction size limit lower than CoinJoin. That would make
> fees for these transactions higher, thus creating an incentive to only
> use them when necessary.
>
> 3) Transaction joiner has to wait for a Jumbo transaction to be big
> enough before it gets released.
> It's not a big problem. When the network load is low, the fee required
> for a tx to be included should be lower, allowing for smaller Jumbo
> transactions. When the network load is high, it takes less time to fill
> a Jumbo transaction.
>
> ==== References: ====
> Increasing the Network Hashing Power by reducing block propagation time
> https://bitcointalk.org/index.php?topic=145066.0
>
> CoinJoin: Bitcoin privacy for the real world
> https://bitcointalk.org/index.php?topic=279249.0
>
> Bitcoin: A Peer-to-Peer Electronic Cash System
> http://bitcoin.org/bitcoin.pdf
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:11:47

- reply

📅 Original date posted:2014-01-17
📝 Original message:So far I've only liked the original name "Stealth address" and the
suggestion "routing address".
Should we put this up for some kind of informal vote with comments allowed?
Like a Google docs form?
- Sent from my phone
Den 17 jan 2014 10:18 skrev "Mike Hearn" <mike at plan99.net>:
> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
>
> https://www.google.com/search?tbm=isch&q=stealth
>
> But everyone loves privacy.
>
>
> On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak at zikula.org> wrote:
>
>> Peter I agree with you about "reusable addresses", but aren't we also
>> trying to get away from the word "address" entirely? How about calling it
>> a "payment key" or "reusable payment key" instead? using "stealth" is just
>> asking for bad press imo.
>>
>>
>> On 16 January 2014 21:28, Peter Todd <pete at petertodd.org> wrote:
>>
>>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>>> > Might I propose "reusable address".
>>> >
>>> > I think that describes it best to any non-programmer, and even more
>>> > so encourages wallets to present options as 'one time use' vs
>>> > 'reusable'.
>>> >
>>> > It definitely packs a marketing punch which could help drive
>>> > adoption. The feature is only useful if/when broadly adopted.
>>>
>>> I'm very against the name "reusable addresses" and strongly belive we
>>> should stick with the name stealth addresses.
>>>
>>> You gotta look at it from the perspective of a user; lets take standard
>>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>>> times as I want and everything works just great. I also can enter the
>>> address on blockchain.info's search box, and every transaction related
>>> to the address, and the balance of it, pops up immediately.
>>>
>>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>>> Transactions associated with them appear to be public knowledge.
>>>
>>> Now I upgrade my wallet software and it says I now have a "reusable"
>>> address. My reaction is "Huh? Normal addresses are reusable, what's
>>> special about this weird reusable address thing that my buddy Bob's
>>> wallet software couldn't pay." I might even try to enter in a "reusable"
>>> address in blockchain.info, which won't work, and I'll just figure
>>> "must be some new unsupported thing" and move on with my life.
>>>
>>> On the other hand, suppose my wallet says I now have "stealth address"
>>> support. I'm going to think "Huh, stealth? I guess that means privacy
>>> right? I like privacy." If I try searching for a stealth address on
>>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>>> It said stealth addresses are private, so maybe the transactions are
>>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>>> in my browser? So like, there's no history being kept for others to
>>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>>> help, so I should learn more about that"
>>>
>>> Finally keep in mind that stealth addresses have had a tonne of very
>>> fast, and very wide reaching PR. The name is in the public conciousness
>>> already, and trying to change it now just because of vague bad
>>> associations is going to throw away the momentum of that good PR and
>>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>>> based on conversations there with people there, technical and
>>> non-technical, almost everyone had heard about them and almost everyone
>>> seemed to understand the basic idea of why they were a good thing. That
>>> just wouldn't have happened with a name that tried to hide what stealth
>>> addresses were for, and by changing the name now we risk people not
>>> making the connection when wallet software gets upgraded to support
>>> them.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>> Critical Workloads, Development Environments & Everything In Between.
>>> Get a Quote or Start a Free Trial Today.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140117/0b612dbf/attachment.html>