<unnamed>

Public Key

npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjt

Profile Code

nprofile1qqs0zneuwxjwvwsjeppwffgywynr4kjtdn77pylukevgdya8y6umqxqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds4y9vng

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 18:10:45 UTC

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

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

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

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

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

- 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 17:58:42 UTC

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

- 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:56:00 UTC

- 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:47:01 UTC

- 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:37:54 UTC

- 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 15:49:18 UTC

- reply

2023-06-07 15:42:43 UTC

- 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:31:33 UTC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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:18:54 UTC

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

- 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:15:40 UTC

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

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

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

- 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:11:47 UTC

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