Kristov Atlas [ARCHIVE]

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

Public Key

npub1arzmapjcjg2yf3hpe6e5h407mn3ry662vhmjhdpe5tft2nelhd9sk5ksrm

Profile Code

nprofile1qqsw33d7sevfy9zycmsuav6t6hldec3jdd9xtaetksu69544fulmkjckqp42r

Author Public Key

npub1arzmapjcjg2yf3hpe6e5h407mn3ry662vhmjhdpe5tft2nelhd9sk5ksrm

Show more details

Last Notes

2023-06-07 17:50:52

- reply

📅 Original date posted:2016-05-19
📝 Original message:I've updated the language of the BIP. New version:
<pre>
BIP: TBD
Title: Best Practices for Heterogeneous Input Script Transactions
Author: Kristov Atlas <kristov at openbitcoinprivacyproject.org>
Status: Draft
Type: Informational
Created: 2016-02-10
</pre>
==Abstract==
The privacy of Bitcoin users with respect to graph analysis is reduced when
a transaction is created that contains inputs composed from different
scripts. However, creating such transactions is often unavoidable.
This document proposes a set of best practice guidelines which minimize the
adverse privacy consequences of such unavoidable transaction situations
while simultaneously maximising the effectiveness of user protection
protocols.
==Copyright==
This BIP is in the public domain.
==Definitions==
* '''Heterogenous input script transaction (HIT)''': A transaction
containing multiple inputs where not all inputs have identical scripts
(e.g. a transaction spending from more than one Bitcoin address)
* '''Unavoidable heterogenous input script transaction''': An HIT created
as a result of a user’s desire to create a new output with a value larger
than the value of his wallet's largest existing unspent output
* '''Intentional heterogenous input script transaction''': An HIT created
as part of a user protection protocol for reducing uncontrolled disclosure
of personally-identifying information (PII)
==Motivations==
The recommendations in this document are designed to accomplish three goals:
# Maximise the effectiveness of user-protecting protocols: Users may find
that protection protocols are counterproductive if such transactions have a
distinctive fingerprint which renders them ineffective.
# Minimise the adverse consequences of unavoidable heterogenous input
transactions: If unavoidable HITs are indistinguishable from intentional
HITs, a user creating an unavoidable HIT benefits from ambiguity with
respect to graph analysis.
# Limiting the effect on UTXO set growth: To date, non-standardized
intentional HITs tend to increase the network's UTXO set with each
transaction; this standard attempts to minimize this effect by
standardizing unavoidable and intentional HITs to limit UTXO set growth.
In order to achieve these goals, this specification proposes a set of best
practices for heterogenous input script transaction creation. These
practices accommodate all applicable requirements of both intentional and
unavoidable HITs while maximising the effectiveness of both in terms of
preventing uncontrolled disclosure of PII.
In order to achieve this, two forms of HIT are proposed: Standard form and
alternate form.
==Standard form heterogenous input script transaction==
===Rules===
An HIT is Standard form if it adheres to all of the following rules:
# The number of unique output scripts must be equal to the number of unique
inputs scripts (irrespective of the number of inputs and outputs).
# All output scripts must be unique.
# At least one pair of outputs must be of equal value.
# The largest output in the transaction is a member of a set containing at
least two identically-sized outputs.
===Rationale===
The requirement for equal numbers of unique input/output scripts instead of
equal number of inputs/outputs accommodates user-protecting UTXO selection
behavior. Wallets may contain spendable outputs with identical scripts due
to intentional or accidental address reuse, or due to dusting attacks. In
order to minimise the adverse consequences of address reuse, any time a
UTXO is included in a transaction as an input, all UTXOs with the same
spending script should also be included in the transaction.
The requirement that all output scripts are unique prevents address reuse.
Restricting the number of outputs to the number of unique input scripts
prevents this policy from growing the network’s UTXO set. A standard form
HIT transaction will always have a number of inputs greater than or equal
to the number of outputs.
The requirement for at least one pair of outputs in an intentional HIT to
be of equal value results in optimal behavior, and causes intentional HITs
to resemble unavoidable HITs.
==Alternate form heterogenous input script transactions==
The formation of a standard form HIT is not possible in the following cases:
# The HIT is unavoidable, and the user’s wallet contains an insufficient
number or size of UTXOs to create a standard form HIT.
# The user wishes to reduce the number of utxos in their wallet, and does
not have any sets of utxos with identical scripts.
When one of the following cases exist, a compliant implementation may
create an alternate form HIT by constructing a transaction as follows:
===Procedure===
# Find the smallest combination of inputs whose value is at least the value
of the desired spend.
## Add these inputs to the transaction.
## Add a spend output to the transaction.
## Add a change output to the transaction containing the difference between
the current set of inputs and the desired spend.
# Repeat step 1 to create a second spend output and change output.
# Adjust the change outputs as necessary to pay the desired transaction fee.
Clients which create intentional HITs must have the capability to form
alternate form HITs, and must do so for a non-zero fraction of the
transactions they create.
==Non-compliant heterogenous input script transactions==
If a user wishes to create an output that is larger than half the total
size of their spendable outputs, or if their inputs are not distributed in
a manner in which the alternate form procedure can be completed, then the
user can not create a transaction which is compliant with this procedure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160519/4f01587b/attachment-0001.html>

2023-06-07 17:50:13

- reply

📅 Original date posted:2016-04-29
📝 Original message:Has anyone thought about the effects of the 75% Segregated Witness subsidy
on CoinJoin transactions and CoinJoin-like transactions? Better yet, has
anyone collected data or come up with a methodology for the collection of
data?
>From this link: https://bitcoincore.org/en/2016/01/26/segwit-benefits/
"Segwit improves the situation here by making signature data, which does
not impact the UTXO set size, cost 75% less than data that does impact the
UTXO set size. This is expected to encourage users to favour the use of
transactions that minimise impact on the UTXO set in order to minimise
fees, and to encourage developers to design smart contracts and new
features in a way that will also minimise the impact on the UTXO set."
My expectation from the above is that this will serve as a financial
disincentive against CoinJoin transactions. However, if people have
evidence otherwise, I'd like to hear it.
I noticed jl2012 objected to this characterization here, but has not yet
provided evidence:
https://www.reddit.com/r/Bitcoin/comments/4gyhsj/what_are_the_impacts_of_segwits_75_fee_discount/d2lvxmw
A sample of the 16 transaction id's posted in the JoinMarket thread on
BitcoinTalk shows an average ratio of 1.38 or outputs to inputs:
https://docs.google.com/spreadsheets/d/1p9jZYXxX1HDtKCxTy79Zj5PrQaF20mxbD7BAuz0KC8s/edit?usp=sharing
As we know, a "traditional" CoinJoin transaction creates roughly 2x UTXOs
for everyone 1 it consumes -- 1 spend and 1 change -- unless address reuse
comes into play.
Please refrain from bringing up Schnorr signatures in your reply, since
they are not on any immediate roadmap.
Thanks,
Kristov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160429/faf5665f/attachment.html>

2023-06-07 17:49:07

- reply

📅 Original date posted:2016-02-10
📝 Original message:BIP: TBD
Title: Best Practices for Heterogeneous Input Script Transactions
Author: Kristov Atlas <kristov at openbitcoinprivacyproject.org>
Status: Draft
Type: Informational
Created: 2016-02-10
# Abstract
The privacy of Bitcoin users with respect to graph analysis is reduced when
a transaction is created that merges inputs composed from different
scripts. However, creating such transactions is often unavoidable.
This document proposes a set of best practice guidelines which minimize the
adverse privacy consequences of such unavoidable transaction situations
while simultaneously maximising the effectiveness of privacy-improving
techniques such as CoinJoin.
# Copyright
This BIP is in the public domain.
# Definitions
Heterogenous input script transaction (HIT): A transaction containing
multiple inputs where not all inputs have identical scripts (e.g. a
transaction spending from more than one Bitcoin address)
Unavoidable heterogenous input script transaction: An HIT created as a
result of a user’s desire to create a new output with a value larger than
the value of his wallet's largest unspent output
Intentional heterogenous input script transaction: An HIT created as part
of a protocol for improving user privacy against graph analysis, such as
CoinJoin
# Motivations
The recommendations in this document are designed to accomplish three goals:
1. Maximise the effectiveness of privacy-enhancing transactions:
Privacy-sensitive users may find that techniques such as CoinJoin are
counterproductive if such transactions have a distinctive fingerprint which
enables them to be censored or subjected to additional scrutiny.
2. Minimise the adverse privacy consequences of unavoidable heterogenous
input transactions: If unavoidable HITs are indistinguishable from
intentional HITs, a user creating an unavoidable HIT benefits from
ambiguity with respect to graph analysis.
3. Limiting the effect on UTXO set growth: To date, non-standardized
intentional HITs tend to increase the network's UTXO set with each
transaction; this standard attempts to minimize this effect by
standardizing unavoidable and intentional HITs to limit UTXO set growth.
In order to achieve these goals, this specification proposes a set of best
practices for heterogenous input script transaction creation. These
practices accommodate all applicable requirements of both intentional and
unavoidable HITs and render the two types indistinguishable to the maximum
extent possible.
In order to achieve this, two forms of HIT are proposed: Standard form and
alternate form.
# Standard form heterogenous input script transaction
## Rules
An HIT is Standard form if it adheres to all of the following rules:
1. The number of unique output scripts must be equal to the number of
unique inputs scripts (irrespective of the number of inputs and outputs).
2. All output scripts must be unique.
3. At least one pair of outputs must be of equal value.
4. The largest output in the transaction is a member of a set containing at
least two identically-sized outputs.
## Rationale
The requirement for equal numbers of unique input/output scripts instead of
equal number of inputs/outputs accommodates privacy-enhancing UTXO
selection behavior. Wallets may contain spendable outputs with identical
scripts due to intentional or accidental address reuse, or due to dusting
attacks. In order to minimise the adverse privacy consequences of address
reuse, any time a UTXO is included in a transaction as an input, all UTXOs
with the same spending script should also be included in the transaction.
The requirement that all output scripts are unique prevents address reuse.
Restricting the number of outputs to the number of unique input scripts
prevents this policy from growing the network’s UTXO set. A standard form
HIT transaction will always have a number of inputs greater than or equal
to the number of outputs.
The requirement for at least one pair of outputs to be of equal value
results in optimal join transactions, and causes intentional HITs to
resemble unavoidable HITs.
Outside controlled laboratory conditions, join transactions will not
involve identically-sized inputs due to a lack of accommodating volume.
Without the ability to cryptographically blind output values on the
blockchain, every join transaction leaks information in the form of output
sizes. Requiring a pair of identically sized outputs creates the desired
ambiguity for spend outputs, but in most cases makes change outputs
linkable to inputs.
# Alternate form heterogenous input script transactions
The formation of a standard form HIT is not possible in the following cases:
The HIT is unavoidable, and the user’s wallet contains an insufficient
number or size of UTXOs to create a standard form HIT.
The user wishes to reduce the number of utxos in their wallet, and does not
have any sets of utxos with identical scripts.
When one of the following cases exist, a compliant implementation may
create an alternate form HIT by constructing a transaction as follows:
## Procedure
1. Find the smallest combination of inputs whose value is at least the
value of the desired spend.
i. Add these inputs to the transaction.
ii. Add a spend output to the transaction.
iii. Add a change output to the transaction containing the difference
between the current set of inputs and the desired spend.
2. Repeat step 1 to create a second spend output and change output.
3. Adjust the change outputs as necessary to pay the desired transaction
fee.
Clients which create intentional HITs must have the capability to form
alternate form HITs, and must do so for a non-zero fraction of the
transactions they create.
# Non-compliant heterogenous input script transactions
If a user wishes to create an output that is larger than half the total
size of their spendable outputs, or if their inputs are not distributed in
a manner in which the alternate form procedure can be completed, then the
user can not create a transaction which is compliant with this procedure.
----
A working draft of this document is here:
https://github.com/OpenBitcoinPrivacyProject/rfc/blob/master/bips/obpp-03.mediawiki
A few points of anticipated discussion:
1. It's possible for a CoinJoin transaction to decrease privacy by adhering
to the Standard Form in this BIP, depending on the utxos available for
creating it. For example, a typical two-person CoinJoin might look like:
input_A, input_B => spend_A, change_A, spend_B, change_B
In order to comply with the standard form, one or more parties would have
to add inputs to make this something like:
input_A_1, input_A_2, input_B_1, input_B_2 => spend_A, change_A, spend_B,
change_B.
If spend_A and spend_B are the same value, then input_A_1 and input_A_2 may
be linked based on the value of change_A and input_B_1 and input_B_2 may be
linked based on the value of change_B via sudoku analysis.
In that situation, wallets can opt to use the alternate form instead, or
stick with the standard form but enjoy a non-utxo set increase and a
significantly increased inter-transactional privacy set from other BIP
adherents.
2. In a naive simulation of a wallet randomly containing 1 to 10 utxos of
random value 1 to 10 and a desired spend of random value between 1 and the
sum of the utxos, the simulated wallet is able to create an alternate form
HIT 40% of the time. If we assume that half of all desire spends are a
value half or less of the total wallet balance, this improves to around
60%. Unfortunately, I don't have any good data on what values are found in
average wallets and what desired spends look like on average.
3. In the long-run it's better for all clients to participant in
CoinJoin-like operations, but this should significantly increase the cost
and decrease the signal of passive blockchain analysis attacks until that
becomes feasible.
Thanks in advance for your feedback.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160210/56f223bb/attachment.html>

2023-06-07 17:43:51

- reply

📅 Original date posted:2015-10-22
📝 Original message:The consequence of previous ECDH address proposals "not designing around
current software" is a sustained ~70% of transactions reusing addresses, as
you saw in my Reddit post recently.
If you have a fear that an inferior proposal will gain popularity, you can
always propose a superior one. If it's *actually* superior, it will win out.
On Thu, Oct 22, 2015 at 4:43 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote:
> > On 22/10/15 00:53, Luke Dashjr wrote:
> > > Sorry for the late review. I'm concerned with the "notification
> address"
> > > requirement, which entails address reuse and blockchain spam. Since it
> > > entails address reuse, the recipient is forced to either leave them
> > > unspent forever (bloating the UTXO set), or spend it which potentially
> > > compromises the private key, and (combined with the payment code)
> > > possibly as much as the entire wallet.
> > >
> > > Instead, I suggest making it a single zero-value OP_RETURN output with
> > > two pushes: 1) a hash of the recipient's payment code, and 2) the
> > > encrypted payment code. This can be searched with standard bloom
> > > filters, or indexed with whatever other optimised algorithms are
> > > desired. At the same time, it never uses any space in the UTXO set, and
> > > never needs to be
> > > spent/mixed/dusted.
> >
> > The notification transaction portion is my least-favorite portion of the
> > spec, but I don't see any alternatives that provide an unambiguous
> > improvement, including your suggestion.
> >
> > One of the most highly-weighted goals of this proposal is to be usable
> > on as many mobile/light wallets as possible.
> >
> > I know for sure that all existing platforms for balance querying index
> > by address. Support for bloom filters or other querying methods is less
> > comprehensive, meaning the set of wallets that can support payment codes
> > would be smaller.
>
> No, they just need to improve their software, and only to support receiving
> with payment codes (not sending to them). BIPs should in general not be
> designed around current software, especially in this case where there is no
> benefit to doing so (since it requires software upgrades anyway).
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/e2f8647f/attachment.html>

2023-06-07 17:39:58

- reply

📅 Original date posted:2015-09-11
📝 Original message:I applaud your brainstorming efforts! :) But I dislike just about
everything about this proposal.
Bitcoin addresses should never be reused, for privacy and security reasons
documented extensively online.
I definitely do not want my computer to maintain a registry of every
address in the world any more than I want to maintain a list of all email
addresses, web addresses, etc. This cannot be scaled and is wasteful since
most participants in the network don't need to transact.
If we need naming conventions, I'd rather see a name registry system
off-chain attached to bip47 reusable payment codes.
-Kr
On Sep 10, 2015 5:32 PM, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Are you aware of the payment protocol?
> On Sep 10, 2015 2:12 PM, "essofluffy . via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Everyone,
>>
>> An issue I'm sure everyone here is familiar with is the problem
>> concerning the fact that Bitcoin addresses are too complex to memorize and
>> share. Current Bitcoin addresses can be very intimidating to new users. As
>> Bitcoin grows it's necessary to provide a much more user friendly
>> experience to the end user. I think that having the capability to assign a
>> unique name to a Bitcoin address is in the best interest of Bitcoin and
>> it's users.
>> I've recently come up with a method for assigning a unique name to a
>> specific Bitcoin address. I'm looking to get some feedback/criticism on
>> this method that I have detailed below.
>>
>> Let’s run through Bob and Alice transacting with a Named Bitcoin Address.
>> Bob wants to collect a payment from Alice for a service/good he is
>> selling, but Alice wants to pay from her home computer where she securely
>> keeps all her Bitcoin. So now Bob needs to give Alice his Bitcoin address
>> and because Bob is using a Named Bitcoin Address and a supported wallet he
>> can give her an easy to memorize and hard to mess up address. Bob’s address
>> is simply ‘SendBitcoinsToBob’ which can easily be written down or
>> memorized. Now Alice can go home send the Bitcoin from her own supported
>> wallet and be positive that she sent it to Bob.
>>
>> Let’s look at how Bob’s supported wallet made that address.
>>
>> First Bob let’s his wallet know that he wants to create a new address. In
>> response, his wallet simply asks him what he wants that address to be
>> named. Bob then enters ‘SendBitcoinsToBob’ as his preferred address name.
>> The wallet then let’s Bob know if his preferred address name is available.
>> If it’s available the name is broadcasted to the network and ready to use.
>>
>> Now let’s get a little more technical.
>>
>> When Bob inputs his preferred address name the client has to make sure
>> this name hasn’t been taken or else who knows where Alice will be sending
>> her Bitcoins. The client does this by referencing a downloaded “directory”
>> of names chosen by people using this system. This directory of names are
>> transactions sent to an address without a private key (but still viewable
>> on the blockchain) with the name appended to the transactions as an
>> OP_RETURN output. These transactions are downloaded or indexed, depending
>> on whether or not the wallet contains the full Blockchain or is an SPV
>> wallet. Because of such a large amount of possible address names a binary
>> search method is used to search through all this data efficiently. The
>> names could be sorted in two ways, the first being the first character and
>> the second being the total length of the name (I will being exploring
>> additional methods to make this process more efficient). So now that Bob’s
>> client has verified that the name has not been taken and is valid (valid
>> meaning it's under 35 bytes long and only using chars 0-9 and a-z) it sends
>> a transaction of 1 satoshi and a small fee to the address without a private
>> key as talked about earlier. The transaction's OP_RETURN output consists of
>> two parts. The implementation version of this method (up to 8 characters)
>> and the name itself (up to 32 characters). Once the transaction is
>> broadcasted to the network and confirmed the name is ready to be used.
>>
>> Let’s look at how Alice’s supported wallet sends her Bitcoin to Bob’s
>> Named Bitcoin Address.
>>
>> When Alice enters in Bob’s address, ‘SendBitcoinsToBob’ Alice’s client
>> references the same “directory” as Bob only on her device and searches for
>> the OP_RETURN output of ‘SendBitcoinsToBob’ using a very similar binary
>> search method as used for the verification of the availability of an
>> address name. If a name isn’t found the client would simply return an
>> error. If the name is found then the client will pull the information of
>> that transaction and use the address it was sent from as the address to
>> send the Bitcoin to.
>>
>> Essentially what this idea describes is a method to assign a name to a
>> Bitcoin address in a way that is completely verifiable and independent of a
>> third party.
>>
>> Please ask your questions and provide feedback.
>>
>> - Devin
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150911/6ce236b5/attachment.html>

2023-06-07 17:39:12

- reply

📅 Original date posted:2015-09-01
📝 Original message:I am interested in finding or writing a fuzzer for push tx APIs. I did not
find one after a brief search. Has anyone found otherwise, or is she in the
process of writing one?
If not, what features would people recommend for a new push tx fuzzer?
Endpoints I would like to test include:
https://live.blockcypher.com/btc-testnet/pushtx/
https://insight.bitpay.com/tx/send
https://blockchain.info/pushtx
https://coinb.in/#broadcast
https://btc.blockr.io/tx/push
https://chain.localbitcoins.com/tx/send
The fuzzer should be able to send random data, invalid characters, etc. but
also fuzz particular aspects of the transaction format such as malformed
P2SH and P2PKH transactions, fields such as lock time, size, # inputs,
version number, vin size, etc. It should also be able to fuzz a variety of
valid and invalid script formats using odd op codes, changing the order of
op codes, etc.
If anyone has recommendations about how such a fuzzer should be structured,
please let me know.
Finally, if you are interested in collaborating, please contact me via
private message.
Thanks!
Kristov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/4cd15068/attachment.html>

2023-06-07 17:34:12

- reply

📅 Original date posted:2015-08-30
📝 Original message:Hi Wei,
As you know, I'm not a developer of Bitcoin-Qt, but we'll need to make our
best guesses for these answers if the developers won't reply. I'm going to
post my best guesses here so that people reading the list have a short
window of opportunity to correct me if they wish.
On Fri, Aug 7, 2015 at 2:46 PM, Wei via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Transaction Formatting
>
> 1. Does your application take any steps to create ambiguity between
> transactions which unavoidably spend from multiple addresses at the same
> time and intentional mixing transactions?
>
No, Bitcoin-Qt does not try to make non-mixing transactions look like
mixing transactions.
> 2. What algorithms does your application use for ordering inputs and
> outputs in a transaction? In particular, how do you handle the change
> output and do you take into account common practices of other wallet
> applications when determining ordering?
>
Not yet BIP 69. These notes suggest that outputs are randomized:
https://bitcoin.org/en/release/v0.8.1
> 3. Does your application minimize the harmful effects of address
> reuse by spending every spendable input (“sweeping”) from an address when a
> transaction is created?
>
Unknown
4. Does your application fully implement BIP 62?
>
Here's a detailed answer on stack exchange:
http://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented
By item, my extremely brief interpretation:
Non-DER encoded ECDSA signatures: BIP66 soft fork has happened, so this is
presumed to be implemented
Non-push operations in scriptSig: Implemented
Push operations in scriptSig of non-standard size type: Implemented in 0.9.0
Zero-padded number pushes: Implemented in 0.10.0 (current available version
is 0.11.0)
Inherent ECDSA signature malleability: ...implemented?
Superfluous scriptSig operations: implemented 0.6.0
Inputs ignored by scripts: Only partly addressed by 0.10.0. It appears
that the rest would require changes to consensus rules, so Bitcoin-Qt is as
compliant as it can be.
Sighash flags based masking and New signatures by the sender: Can't be
implemented without changes to consensus rules.
I would summarize this as a "yes."
>
> Mixing
>
> 5. If your application supports mixing:
>
It doesn't. There's an issue for CoinJoin here:
https://github.com/bitcoin/bitcoin/issues/3226
> a. What is the average number of participants a user can expect to
> interact with on a typical join transaction?
> b. Does your application attempt to construct join transactions in a
> way that avoids distinguishing them from non-join transactions?
> c. Does your application perform any kind of reversibility analysis
> on join transactions prior to presenting them to the user for confirmation?
> d. Is the mixing technique employed secure against correlation
> attacks by the facilitator, such as a CoinJoin server or off-chain mixing
> service?
> e. Is the mixing technique employed secure against theft of funds by
> the facilitator or its participants?
>
> Donations
>
> 6. If your application has a fee or donation to the developers
> feature:
>
No donation feature last time I checked.
> a. What steps do you take to make the donations indistinguishable
> from regular spend in terms of output sizes and destination addresses?
>
> Balance Queries and Tx Broadcasting
>
> 7. Please describe how your application obtains balance information
> in terms of how queries from the user’s device can reveal a connection
> between the addresses in their wallet.
> a. Does the application keep a complete copy of the blockchain
> locally (full node)?
>
Yes
> b. Does the user’s device provide a filter which matches some
> fraction of the blockchain while providing a false positive rate (bloom or
> prefix filters)?
>
No, it just downloads the whole blockchain and performs local queries.
> i. If so, approximately what fraction of the blockchain does the
> filter match in a default configuration (0% - 100%)?
>
100%, unless a user bootstraps downloading the blockchain. Bootstrapping
will potentially limit the user's anonymity set to other people who have
downloaded that bootstrap.dat file.
> c. Does the user’s device query all of their addresses at the same
> time?
>
N/A
> d. Does the user’s device query addresses individually in a manner
> that does not allow the query responder to correlate queries for different
> addresses?
>
No. Just download blocks and processes that information locally.
> e. Can users opt to obtain their balance information via Tor (or
> equivalent means)?
>
If Tor is set up as a SOCKS proxy, you can configure Bitcoin-QT download
the blockchain and broadcast txs through a single Tor circuit. This can be
configured once before opening Bitcoin-Qt.
8. Does the applications route outgoing transactions independently
> from the manner in which it obtains balance information? Can users opt to
> have their transactions submitted to the Bitcoin network via Tor (or an
> equivalent means) independently of how they obtain their balance
> information?
>
No, you can only configure a single proxy.
> 9. If your application supports multiple identities/wallets, does
> each one connect to the network as if it were completely independent from
> the other?
>
No built-in support for multiple identities. You can hotswap wallet files
to crudely simulate this. You'd have to manually change the Tor connection
outside of Bitcoin-Qt to create the effect of making the network
connections independent.
> a. Does the application ever request balance information for
> addresses belonging to multiple identities in the same network query?
>
Blocks are downloaded and tx broadcasts received/relayed rather than
querying the utxo set for a particular address. When swapping between
wallet files, some information may be leaked e.g. the client may be at the
same block height in terms of what it has downloaded from the p2p network,
which may leak to global passive adversaries/AS's or sybil attackers the
fact that a single client was used for multiple wallets.
> b. Are outgoing transactions from multiple identities routed
> independently of each other to the Bitcoin network?
>
Transactions from multiple identities would not be routed at the same time.
I'm not clear what happens if you have a single wallet (identity) open and
then open a new wallet (identity) without closing Bitcoin-Qt -- some of the
same routing paths may still be used such that an attacker might observe
transactions broadast signed by private keys from multiple wallets
(identities) and observe that they appear to come from the same wallet
client. OBPP should assume the worst unless prevented contrary evidence.
> c. When an identity/wallet is deleted, does the deletion process
> eliminate all evidence from the user's device that the wallet was
> previously installed?
>
Identity is primarily tied to a wallet.dat file. Deleting it will remove
most of the evidence that the wallet was installed on that device, but
there may be some extra information in ancillary files that should also be
deleted. This is an OS-level function, as there is no operation built into
the client to delete a wallet file (identity).
> Network Privacy
>
> 10. When a user performs a backup operation for their wallet, does
> this generate any automatic network activity, such as a web query or email?
>
No. Backups are local, and no email or SMS is linked. No web queries
related to backup.
> 11. Does your application perform any lookup external to the user’s
> device related to identifying transaction senders or recipients?
>
No
> 12. Does you application connect to known endpoints which would be
> visible to an ISP, such as your domain?
>
Yes, some connections to known p2p full nodes to bootstrap the connection
to the Bitcoin p2p network. This is configurable, but there are defaults.
An ISP is likely to be able to identify a customer as running the
Bitcoin-Qt client in particular on this basis.
> 13. If your application connects directly to nodes in the Bitcoin P2P
> network, does it either use an unremarkable user agent string (Bitcoin
> Core. BitcoinJ, etc), or randomize its user agent on each connection?
>
BIP12 specifies format for user agents:
https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
It appears that the Bitcoin-QT leaks specific information about its client
version through User Agent. This file defines the current client version:
https://github.com/bitcoin/bitcoin/blob/55294a9fb673ab0a7c99b9c18279fe12a5a07890/src/clientversion.h
Various other files seem to use this to build up the UA string, which is
transmitted to other peers.
>
> Physical Access
>
> 14. Does the application uninstall process for your application
> eliminate all evidence from the user's device that the application was
> previously installed? Does it also eliminate wallet data?
>
Probably depends on the platform. Last time I checked, I think Bitcoin-Qt
leaves behind a .bitcoin directory on most platforms even after you run an
uninstall script.
> 15. Does your application use techniques such as steganography to
> store persistent wallet metadata in a form not identifiable as belong to a
> Bitcoin wallet application?
>
No
> 16. Please describe the degree to which users can use passwords/PINs
> to protect their data:
> a. Can the user set a password/PIN to protect their private keys?
>
You can encrypt the wallet file with a password. The wallet is "locked"
until the password is entered, preventing decryption of the private keys.
> b. Can the user set a password/PIN to protect their public keys and
> balance information?
>
No -- any wallet.dat file can be opened and the public keys inspected
without the password.
> c. Can the user set a password/PIN to encrypt other wallet metadata,
> such as address books and transaction notes?
>
No -- any wallet.dat file can be opened and the metadata inspected without
the password.
> d. Does the application use a single password/PIN to cover all
> protected data, or does it allow the use of multiple passwords/PINs?
>
A single password for the wallet file.
>
> Custodianship
>
> 17. Do you as a wallet provider ever have access to unencrypted copies
> of the user’s private keys, public keys, or any other wallet metadata which
> may be used to associate a user with their transactions or balances?
>
No custodianship.
> Telemetry Data
>
> 18. If your application reports telemetry data, such as usage
> information or automatic crash reporting, does the user have the
> opportunity to review and approve all information transmitted before it is
> sent?
>
No obvious telemetry data being sent.
> Source Code and Building
>
> 19. Can a user of your application compile the application themselves
> in a manner that produces a binary version identical to the version you
> distribute (deterministic build system)?
>
Yes, I think that's the point of the gitian stuff.
-Kristov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150830/c489ab03/attachment-0001.html>

2023-06-07 15:46:14

- reply

2023-06-07 15:41:25

- reply

📅 Original date posted:2015-07-01
📝 Original message:Hi Justus,
What are the potential applications for this BIP?
-Kr
On Jun 30, 2015 1:53 PM, "Justus Ranvier" <justus.ranvier at monetas.net>
wrote:
> Monetas has developed a Bitmessage address derivation method from an
> HD seed based on BIP-43.
>
>
> https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki
>
>
> We're proposing this as a BIP per the BIP-43 recommendation in order
> to reserve a purpose code.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150701/8418af96/attachment.html>

2023-06-07 15:36:46

- reply

📅 Original date posted:2015-06-24
📝 Original message:Following up on this topic...
gmaxwell has reserved BIP 69 for my proposal.
It has been implemented by Electrum in v2.3.2:
https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES
Rusty has kindly tweaked his original canonical ordering proposal
implementation for Bitcoin Core's wallet client to fit my proposal:
https://github.com/rustyrussell/bitcoin/tree/bip-69 (needs testing)
Outstanding objections appear to me to boil down to two points:
1) Some transactions cannot comply with this BIP because there are input
and/or put index dependencies.
My response: No big deal, it's informational. They simply won't be
compliant with the BIP, and that's fine with me.
2) If we set a standard now for transactions that is not apparently random
ordering from the perspective of passive blockchain observers, transactions
that can't comply with this BIP will stand out. Also, if we change our
collective minds in the future about how ordering should be handled, those
future transactions would stand out. Therefore, the "safe" course of action
is to come up with another scheme that appears to be random ordering from
the perspective of a passive blockchain observer.
My response: Apparently-random but owner-verifiable ordering is doable.
Discussion of this has revolved around what I have called a "sorting key"
-- sort lexicographically, and then reorder according to the bits in a
sorting key that is impossible to predict by an attacker. This means
passive observers cannot determine anything meaningful about the
transaction (e.g. which output is change, information leaked based on utxo
selection algorithm for inputs, etc.) but the owner of the funds and the
sorting key can verify that his transaction matches the canonical
specification. Ideally, I think the key should rotate for each transaction
to avoid the possibility that a static key can link multiple transactions
together. The key should be rotated in such a fashion that the next
iteration is not predictable to anyone except the key holder (e.g. put the
key through a secure pseudo-random function for each new iteration). This
could be done by generating a few bytes of entropy upon wallet creation and
keeping track of the current iteration of rotation. HD wallets could derive
the initial state of the sorting key by deriving it from the HD seed. There
are a variety of schemes that could work here.
My main objection to this family of approaches at present is complexity. I
suspect that many wallet clients will not want to implement the BIP if they
have to maintain a sorting key.
A second objection is that no one will be able to detect anomalies in BIP
compliance except for the sorting key holder. Most users probably will not
bother to verify this. For code reviewers, this means that the sorting key
is yet another aspect of the code base that must be scrutinized to ensure
it is not being used as a covert channel or has been underhandedly weakened
in some fashion.
Also, I will mention an ancillary benefit of a non-random canonical
ordering: it makes unit testing of transactions for Bitcoin wallets simpler.
Given all of the above, I will reiterate my preference to keep the proposal
as it is now. The pull request is here:
https://github.com/bitcoin/bips/pull/157
If there is market demand for it, a separate sorting key-based proposal
could be written which can compete with this BIP and over time successfully
deprecate it. I would currently envision that as an HD BIP with a new
purpose code.
-Kristov
On Mon, Jun 15, 2015 at 12:01 AM, Kristov Atlas <
kristovatlas.lists at gmail.com> wrote:
> On Sun, Jun 14, 2015 at 7:02 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>
>> I'm not a great fan of this proposal for two reasons: The first is
>> that the strict ordering requirements is incompatible with future
>> soft-forks that may expose additional ordering constraints. Today we
>> have _SINGLE, which as noted this interacts with poorly, but there
>> have been other constraints proposed that this would also interact
>> with poorly.
>>
>
> I'm not clear on why this is a problem, so long as the canonical ordering
> BIP is *optional*. Unless there is a specific plan to soft fork a change
> that would break the BIP and it is fairly imminent, I see this only as a
> reason not to integrate it into isStandard().
>
>
>> The second is that even absent consensus rules there may be invisible
>> constraints in systems-- e.g. hardware wallets that sign top down, or
>> future transaction covenants that have constraints about ordering, or
>> proof systems that use (yuck) midstate compression for efficiency. Right
>> now, with random ordering these applications are fairly
>> indistinguishable from other random uses (since their imposed order
>> could come about by chance) but if everyone else was ordered, even if
>> wasn't enforced.. these would be highly distinguishable. Which would
>> be unfortunate.
>
>
> Maybe they shouldn't be doing that. :-P
>
>
>> I think perhaps the motivations here are understated. We have not seen
>> any massive deployments of accidentally broken ordering that I'm aware
>> of-- and an implementation that got this wrong in a harmful way would
>> likely make far more fatal mistakes (e.g. non random private keys).
>>
>
> In my reading of various wallet client sources, it is common that wallet
> clients will use cryptographically weak sources of randomness to sort
> outputs -- that is, the ones that actually bother to randomly sort. I can
> hunt down some examples if this would substantially contribute to the
> discussion.
>
> As an alternative to this proposal the ordering can be privately
>> derandomized in the same way DSA is, to avoid the need for an actual
>> number source. If getting the randomness right were really the only
>> motivation, I'd suggest we propose a simple derandomized randomization
>> algorithm--- e.g. take the order from (H(input ids||client secret)).
>>
>
> This sounds similar to an idea that Sergio pitched to me privately, which
> was for wallets to have a private sorting key that they can use to sort
> inputs and outputs. However, I suspect that adding yet another key which
> will necessarily require special key rotation rules and maybe special
> backup procedures will mean that this standard will not be widely adopted
> any time soon. Ideally, I'd like to see someone write a different BIP with
> the sorting key idea and let them compete in the wallet client market
> rather than trying to anticipate what is best for all clients and
> distilling two good ideas into one artificially.
>
> -Kristov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/b1579282/attachment.html>

2023-06-07 15:36:45

- reply

📅 Original date posted:2015-06-15
📝 Original message:On Sun, Jun 14, 2015 at 7:02 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> I'm not a great fan of this proposal for two reasons: The first is
> that the strict ordering requirements is incompatible with future
> soft-forks that may expose additional ordering constraints. Today we
> have _SINGLE, which as noted this interacts with poorly, but there
> have been other constraints proposed that this would also interact
> with poorly.
>
I'm not clear on why this is a problem, so long as the canonical ordering
BIP is *optional*. Unless there is a specific plan to soft fork a change
that would break the BIP and it is fairly imminent, I see this only as a
reason not to integrate it into isStandard().
> The second is that even absent consensus rules there may be invisible
> constraints in systems-- e.g. hardware wallets that sign top down, or
> future transaction covenants that have constraints about ordering, or
> proof systems that use (yuck) midstate compression for efficiency. Right
> now, with random ordering these applications are fairly
> indistinguishable from other random uses (since their imposed order
> could come about by chance) but if everyone else was ordered, even if
> wasn't enforced.. these would be highly distinguishable. Which would
> be unfortunate.
Maybe they shouldn't be doing that. :-P
> I think perhaps the motivations here are understated. We have not seen
> any massive deployments of accidentally broken ordering that I'm aware
> of-- and an implementation that got this wrong in a harmful way would
> likely make far more fatal mistakes (e.g. non random private keys).
>
In my reading of various wallet client sources, it is common that wallet
clients will use cryptographically weak sources of randomness to sort
outputs -- that is, the ones that actually bother to randomly sort. I can
hunt down some examples if this would substantially contribute to the
discussion.
As an alternative to this proposal the ordering can be privately
> derandomized in the same way DSA is, to avoid the need for an actual
> number source. If getting the randomness right were really the only
> motivation, I'd suggest we propose a simple derandomized randomization
> algorithm--- e.g. take the order from (H(input ids||client secret)).
>
This sounds similar to an idea that Sergio pitched to me privately, which
was for wallets to have a private sorting key that they can use to sort
inputs and outputs. However, I suspect that adding yet another key which
will necessarily require special key rotation rules and maybe special
backup procedures will mean that this standard will not be widely adopted
any time soon. Ideally, I'd like to see someone write a different BIP with
the sorting key idea and let them compete in the wallet client market
rather than trying to anticipate what is best for all clients and
distilling two good ideas into one artificially.
-Kristov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/004fad7d/attachment.html>

2023-06-07 15:36:40

- reply

📅 Original date posted:2015-06-14
📝 Original message:Update: BIP 79 has been implemented in the latest release of Electrum,
v2.3.2:
https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES
-Kristov
On Fri, Jun 12, 2015 at 5:36 PM, Kristov Atlas <kristovatlas.lists at gmail.com
> wrote:
> Since everyone's busy, I went ahead and made a pull request to add this as
> an informational BIP 79 to the bips directory.
>
> https://github.com/bitcoin/bips/pull/157
>
> Regards,
> Kristov
>
> On Tue, Jun 9, 2015 at 4:14 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote:
>>
>> Two other things:
>>
>>
>>
>> > On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd <pete at petertodd.org> wrote:
>> >
>> > > Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized
>> > > protocols; you haven't taken into account the needs of those
>> protocols.
>> > > For BIP's it's better to stick to the use-cases where the need is
>> clear
>> > > and there exists running code that to speculate too much on future
>> uses.
>> > > With signature hashing in particular it's not yet clear at all what
>> > > future OP_CHECKSIG's will look like, let alone the various ways people
>> > > will use sighash for smart contract type stuff.
>> > >
>> > > You'd be better off presenting the BIP in terms of a generic statement
>> > > that "except when otherwise prevented by advanced signature hashing
>> > > requirements, wallet software must emit transactions sorted according
>> to
>> > > the following" You can then specify the two common cases in detail:
>> > >
>> > > 1) SIGHASH_ALL: input and output order signed, so sort appropriately
>> > >
>> > > 2) SIGHASH_ANYONECANPAY: input order not signed, so software should
>> emit
>> > > transactions sorted, recognising that the actual mined order may be
>> > > changed.
>> > >
>> >
>> > That makes sense. I updated the language as follows -- your thoughts?
>> Keep
>> > in mind this BIP is informational, and so people are free to ignore it.
>> >
>> > "Applicability: This BIP applies to all transactions of signature hash
>> type
>> > SIGHASH_ALL. Additionally, software compliant with this BIP that allows
>> > later parties to update the transaction (e.g. using signature hash types
>> > SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit
>> > lexicographically sorted inputs and outputs, although they may later be
>> > modified. Transactions that have index dependencies between
>> transactions or
>> > within the same transaction are covered under the section of this BIP
>> > entitled “Handling Input/Output Dependencies.”"
>>
>> I'd keep it even simpler than that, and just say for now that such
>> use-cases are out of the scope of this BIP, however those standards
>> should come up with some kind of deterministic standard that meets the
>> needs of the protocol. Again, there's a bunch of possible use-cases here
>> and we just can't predict them; focus on the fact that the *spirit* of
>> what this BIP is about is applicable and future standards should be
>> developed.
>>
>> So I'd change the "Applicability" section to:
>>
>> This BIP applies to all transactions where the order of inputs and
>> outputs does not matter. This is true for the vast majority of
>> transactions as they simply move funds from one place to another.
>>
>> Currently this generally refers to transactions where SIGHASH_ALL is
>> used, in which case the signatures commit to the exact order of input
>> and outputs. In the case where SIGHASH_ANYONECANPAY and/or SIGHASH_NONE
>> has been used (e.g. crowdfunds) the order of inputs and/or outputs may
>> not be signed, however compliant software should still emit transactions
>> with sorted inputs and outputs, even though they may later be modified
>> by others.
>>
>> In the event that future protocol upgrades introduce new signature hash
>> types, compliant software should apply the lexographic ordering
>> principle analogously.
>>
>> While out of scope of this BIP, protocols that do require a specified
>> order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should
>> consider the goals of this BIP and how best to adapt them to the
>> specifics needs of those protocols.
>>
>>
>> Then remove the "handling input/output deps" section.
>>
>> > > Do you have a patch implementing deterministic tx ordering for Bitcoin
>> > > Core yet?
>> > >
>> >
>> > I'm not a frequent C programmer, so I'd prefer to let someone else take
>> > care of it, as a frequent committer of code would do a faster and more
>> > stylistically consistent job of it. If no one else will, however, I
>> will.
>>
>>
>>
>> re: the actual ordering algorithm, having txids be sorted by with the
>> hex-based algorithm is odd. I'd simply say they're sorted as
>> little-endian byte arrays, or in other words, with the bytearr_cmp()
>> function, but with the order of bytes reversed. You also should say that
>> we're doing that to make the user see them in visually sorted order to
>> match expectations because txids are displayed as little-endian.
>>
>> For outputs, don't say "locking script", say "scriptPubKey". Secondly,
>> scriptPubKeys are not in little-endian representation - they have no
>> endianness to them. With output amount, there's no need to say that
>> they're unsigned or little-endian satoshies, just say they're sorted
>> largest/smallest amount first.
>>
>> "For the sake of efficiency, amounts will be considered first for
>> sorting, since they contain fewer bytes of information (7 bytes)
>> compared to a standard P2PKH locking script (800 bytes)." <- where the
>> heck did you get these numbers from? Amounts are 8 bytes, and P2PKH
>> scriptPubKeys are 25 bytes.
>>
>>
>> "Backwards Compatibility" <- I'd just remove this whole section; we're
>> unlikely to make this an IsStandard() rule anytime soon.
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/5a268295/attachment.html>

2023-06-07 15:36:39

- reply

📅 Original date posted:2015-06-10
📝 Original message:Thanks for the feedback. I think I have reflected all of your requested
changes in the latest version, in the BIP and sample code:
https://github.com/kristovatlas/rfc/tree/master/bips
-Kr
On Tue, Jun 9, 2015 at 4:14 PM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote:
>
> Two other things:
>
>
>
> > On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd <pete at petertodd.org> wrote:
> >
> > > Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized
> > > protocols; you haven't taken into account the needs of those protocols.
> > > For BIP's it's better to stick to the use-cases where the need is clear
> > > and there exists running code that to speculate too much on future
> uses.
> > > With signature hashing in particular it's not yet clear at all what
> > > future OP_CHECKSIG's will look like, let alone the various ways people
> > > will use sighash for smart contract type stuff.
> > >
> > > You'd be better off presenting the BIP in terms of a generic statement
> > > that "except when otherwise prevented by advanced signature hashing
> > > requirements, wallet software must emit transactions sorted according
> to
> > > the following" You can then specify the two common cases in detail:
> > >
> > > 1) SIGHASH_ALL: input and output order signed, so sort appropriately
> > >
> > > 2) SIGHASH_ANYONECANPAY: input order not signed, so software should
> emit
> > > transactions sorted, recognising that the actual mined order may be
> > > changed.
> > >
> >
> > That makes sense. I updated the language as follows -- your thoughts?
> Keep
> > in mind this BIP is informational, and so people are free to ignore it.
> >
> > "Applicability: This BIP applies to all transactions of signature hash
> type
> > SIGHASH_ALL. Additionally, software compliant with this BIP that allows
> > later parties to update the transaction (e.g. using signature hash types
> > SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit
> > lexicographically sorted inputs and outputs, although they may later be
> > modified. Transactions that have index dependencies between transactions
> or
> > within the same transaction are covered under the section of this BIP
> > entitled “Handling Input/Output Dependencies.”"
>
> I'd keep it even simpler than that, and just say for now that such
> use-cases are out of the scope of this BIP, however those standards
> should come up with some kind of deterministic standard that meets the
> needs of the protocol. Again, there's a bunch of possible use-cases here
> and we just can't predict them; focus on the fact that the *spirit* of
> what this BIP is about is applicable and future standards should be
> developed.
>
> So I'd change the "Applicability" section to:
>
> This BIP applies to all transactions where the order of inputs and
> outputs does not matter. This is true for the vast majority of
> transactions as they simply move funds from one place to another.
>
> Currently this generally refers to transactions where SIGHASH_ALL is
> used, in which case the signatures commit to the exact order of input
> and outputs. In the case where SIGHASH_ANYONECANPAY and/or SIGHASH_NONE
> has been used (e.g. crowdfunds) the order of inputs and/or outputs may
> not be signed, however compliant software should still emit transactions
> with sorted inputs and outputs, even though they may later be modified
> by others.
>
> In the event that future protocol upgrades introduce new signature hash
> types, compliant software should apply the lexographic ordering
> principle analogously.
>
> While out of scope of this BIP, protocols that do require a specified
> order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should
> consider the goals of this BIP and how best to adapt them to the
> specifics needs of those protocols.
>
>
> Then remove the "handling input/output deps" section.
>
> > > Do you have a patch implementing deterministic tx ordering for Bitcoin
> > > Core yet?
> > >
> >
> > I'm not a frequent C programmer, so I'd prefer to let someone else take
> > care of it, as a frequent committer of code would do a faster and more
> > stylistically consistent job of it. If no one else will, however, I will.
>
>
>
> re: the actual ordering algorithm, having txids be sorted by with the
> hex-based algorithm is odd. I'd simply say they're sorted as
> little-endian byte arrays, or in other words, with the bytearr_cmp()
> function, but with the order of bytes reversed. You also should say that
> we're doing that to make the user see them in visually sorted order to
> match expectations because txids are displayed as little-endian.
>
> For outputs, don't say "locking script", say "scriptPubKey". Secondly,
> scriptPubKeys are not in little-endian representation - they have no
> endianness to them. With output amount, there's no need to say that
> they're unsigned or little-endian satoshies, just say they're sorted
> largest/smallest amount first.
>
> "For the sake of efficiency, amounts will be considered first for
> sorting, since they contain fewer bytes of information (7 bytes)
> compared to a standard P2PKH locking script (800 bytes)." <- where the
> heck did you get these numbers from? Amounts are 8 bytes, and P2PKH
> scriptPubKeys are 25 bytes.
>
>
> "Backwards Compatibility" <- I'd just remove this whole section; we're
> unlikely to make this an IsStandard() rule anytime soon.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150610/51baef2a/attachment.html>

2023-06-07 15:36:39

- reply

📅 Original date posted:2015-06-12
📝 Original message:Since everyone's busy, I went ahead and made a pull request to add this as
an informational BIP 79 to the bips directory.
https://github.com/bitcoin/bips/pull/157
Regards,
Kristov
On Tue, Jun 9, 2015 at 4:14 PM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote:
>
> Two other things:
>
>
>
> > On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd <pete at petertodd.org> wrote:
> >
> > > Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized
> > > protocols; you haven't taken into account the needs of those protocols.
> > > For BIP's it's better to stick to the use-cases where the need is clear
> > > and there exists running code that to speculate too much on future
> uses.
> > > With signature hashing in particular it's not yet clear at all what
> > > future OP_CHECKSIG's will look like, let alone the various ways people
> > > will use sighash for smart contract type stuff.
> > >
> > > You'd be better off presenting the BIP in terms of a generic statement
> > > that "except when otherwise prevented by advanced signature hashing
> > > requirements, wallet software must emit transactions sorted according
> to
> > > the following" You can then specify the two common cases in detail:
> > >
> > > 1) SIGHASH_ALL: input and output order signed, so sort appropriately
> > >
> > > 2) SIGHASH_ANYONECANPAY: input order not signed, so software should
> emit
> > > transactions sorted, recognising that the actual mined order may be
> > > changed.
> > >
> >
> > That makes sense. I updated the language as follows -- your thoughts?
> Keep
> > in mind this BIP is informational, and so people are free to ignore it.
> >
> > "Applicability: This BIP applies to all transactions of signature hash
> type
> > SIGHASH_ALL. Additionally, software compliant with this BIP that allows
> > later parties to update the transaction (e.g. using signature hash types
> > SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit
> > lexicographically sorted inputs and outputs, although they may later be
> > modified. Transactions that have index dependencies between transactions
> or
> > within the same transaction are covered under the section of this BIP
> > entitled “Handling Input/Output Dependencies.”"
>
> I'd keep it even simpler than that, and just say for now that such
> use-cases are out of the scope of this BIP, however those standards
> should come up with some kind of deterministic standard that meets the
> needs of the protocol. Again, there's a bunch of possible use-cases here
> and we just can't predict them; focus on the fact that the *spirit* of
> what this BIP is about is applicable and future standards should be
> developed.
>
> So I'd change the "Applicability" section to:
>
> This BIP applies to all transactions where the order of inputs and
> outputs does not matter. This is true for the vast majority of
> transactions as they simply move funds from one place to another.
>
> Currently this generally refers to transactions where SIGHASH_ALL is
> used, in which case the signatures commit to the exact order of input
> and outputs. In the case where SIGHASH_ANYONECANPAY and/or SIGHASH_NONE
> has been used (e.g. crowdfunds) the order of inputs and/or outputs may
> not be signed, however compliant software should still emit transactions
> with sorted inputs and outputs, even though they may later be modified
> by others.
>
> In the event that future protocol upgrades introduce new signature hash
> types, compliant software should apply the lexographic ordering
> principle analogously.
>
> While out of scope of this BIP, protocols that do require a specified
> order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should
> consider the goals of this BIP and how best to adapt them to the
> specifics needs of those protocols.
>
>
> Then remove the "handling input/output deps" section.
>
> > > Do you have a patch implementing deterministic tx ordering for Bitcoin
> > > Core yet?
> > >
> >
> > I'm not a frequent C programmer, so I'd prefer to let someone else take
> > care of it, as a frequent committer of code would do a faster and more
> > stylistically consistent job of it. If no one else will, however, I will.
>
>
>
> re: the actual ordering algorithm, having txids be sorted by with the
> hex-based algorithm is odd. I'd simply say they're sorted as
> little-endian byte arrays, or in other words, with the bytearr_cmp()
> function, but with the order of bytes reversed. You also should say that
> we're doing that to make the user see them in visually sorted order to
> match expectations because txids are displayed as little-endian.
>
> For outputs, don't say "locking script", say "scriptPubKey". Secondly,
> scriptPubKeys are not in little-endian representation - they have no
> endianness to them. With output amount, there's no need to say that
> they're unsigned or little-endian satoshies, just say they're sorted
> largest/smallest amount first.
>
> "For the sake of efficiency, amounts will be considered first for
> sorting, since they contain fewer bytes of information (7 bytes)
> compared to a standard P2PKH locking script (800 bytes)." <- where the
> heck did you get these numbers from? Amounts are 8 bytes, and P2PKH
> scriptPubKeys are 25 bytes.
>
>
> "Backwards Compatibility" <- I'd just remove this whole section; we're
> unlikely to make this an IsStandard() rule anytime soon.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150612/6cbf4c0f/attachment.html>

2023-06-07 15:36:38

- reply

📅 Original date posted:2015-06-08
📝 Original message:Hey Peter, thanks for your experienced feedback.
On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd <pete at petertodd.org> wrote:
> Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized
> protocols; you haven't taken into account the needs of those protocols.
> For BIP's it's better to stick to the use-cases where the need is clear
> and there exists running code that to speculate too much on future uses.
> With signature hashing in particular it's not yet clear at all what
> future OP_CHECKSIG's will look like, let alone the various ways people
> will use sighash for smart contract type stuff.
>
> You'd be better off presenting the BIP in terms of a generic statement
> that "except when otherwise prevented by advanced signature hashing
> requirements, wallet software must emit transactions sorted according to
> the following" You can then specify the two common cases in detail:
>
> 1) SIGHASH_ALL: input and output order signed, so sort appropriately
>
> 2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit
> transactions sorted, recognising that the actual mined order may be
> changed.
>
That makes sense. I updated the language as follows -- your thoughts? Keep
in mind this BIP is informational, and so people are free to ignore it.
"Applicability: This BIP applies to all transactions of signature hash type
SIGHASH_ALL. Additionally, software compliant with this BIP that allows
later parties to update the transaction (e.g. using signature hash types
SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit
lexicographically sorted inputs and outputs, although they may later be
modified. Transactions that have index dependencies between transactions or
within the same transaction are covered under the section of this BIP
entitled “Handling Input/Output Dependencies.”"
> As for IsStandard() rules - let alone soft forks - better to leave
> discussion of them out for now. In particular, for the soft-fork case
> mandating certain transaction orders will very likely cause problems in
> the future for future OP_CHECKSIG upgrades. For SIGHASH_ANYONECANPAY, it
> might be appropriate for nodes to enforce a certain ordering, but that
> can be a separate BIP. (actually implementing that in Bitcoin Core would
> be annoying and ugly right now; without replace-by-fee ANYONECANPAY has
> a silly DoS attack (adding low-fee inputs) so I can't recommend wallets
> use it in the general case yet)
>
> "and a sequence number currently set to 0xFFFFFFFF." <- Actually, this
> will be changed in Bitcoin Core as of v0.11.0, which implements
> anti-fee-sniping w/ nLockTime.(1) (I need to write up a full BIP
> describing it)
>
Thanks for the heads-up; removed.
> Do you have a patch implementing deterministic tx ordering for Bitcoin
> Core yet?
>
I'm not a frequent C programmer, so I'd prefer to let someone else take
care of it, as a frequent committer of code would do a faster and more
stylistically consistent job of it. If no one else will, however, I will.
-Kristov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150608/0d043ebb/attachment.html>

2023-06-07 15:36:38

- reply

📅 Original date posted:2015-06-08
📝 Original message:>
> As for IsStandard() rules - let alone soft forks - better to leave
> discussion of them out for now.
Removed that bit as well.
Latest version:
https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki
-Kristov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150608/683bd48c/attachment.html>

2023-06-07 15:36:37

- reply

📅 Original date posted:2015-06-06
📝 Original message:I've updated the draft BIP in two ways:
-Making it clear that sorting is algorithmically agnostic, but should
conform to the output of the example algorithms written in python
-The BIP now handles schemes that create an input/output dependency, such
as SIGHASH_SINGLE:
Handling Input/Output Dependencies
Some uncommon forms of transactions create an ordering dependency between
inputs and outputs of a transaction. Wallets forming these transactions
should first sort inputs according to the methodology outlined in section
“Transaction Inputs” of this BIP. Then, they should fix the output indices
that depend on the input order, and sort the remaining outputs around them.
If there are no outputs that do not depend on input order, then all outputs
will simply be ordered based on the expected scheme. The following are the
known cases of input/output dependency that must be handled specially:
* SIGHASH_SINGLE hash type. [5] Clients seeking to verify LI01 compliance
for a transaction must inspect the last byte of the scriptSig of each input
to determine the signature hash type. In the case of SIGHASH_SINGLE (0x03)
for input “n”, the verifier should expect that output “n” will be fixed
when considering output ordering.
https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki
I'm satisfied with this adjustment, as it is unlikely that any software
that wants to verify compliance with the BIP will not have access to the
scriptSig of each input.
-Kristov
On Sat, Jun 6, 2015 at 2:24 AM, Kristov Atlas <kristovatlas.lists at gmail.com>
wrote:
> Hey Stephen,
>
> Thanks for your feedback
>
> On Fri, Jun 5, 2015 at 11:20 PM, Stephen <stephencalebmorse at gmail.com>
> wrote:
>
>> - I think your explanation of sorting could be significantly shortened
>> and clarified by simply saying that the TXIDs of inputs should be compared
>> as uint256 integers.
>>
>
> I considered defining the comparison of txids in terms of integers;
> however, I am concerned that this definition may be ambiguous when applied
> to a variety of languages and platforms without a similar amount of
> explanation as currently exists. For example, if a web wallet uses an API
> to receive transaction information, this is traditionally expressed in
> terms tx id strings rather than 256-bit integers. My intent is that wallets
> can implement the algorithm however they wish, but should ensure that their
> output is compliant with the BIP definition. IMHO the algorithm stated in
> the BIP should target test cases rather than implementation, and should
> leave as little room for ambiguity as possible.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150606/022fec3a/attachment.html>

2023-06-07 15:36:37

- reply

📅 Original date posted:2015-06-06
📝 Original message:Hey Stephen,
Thanks for your feedback
On Fri, Jun 5, 2015 at 11:20 PM, Stephen <stephencalebmorse at gmail.com>
wrote:
> - I think your explanation of sorting could be significantly shortened
> and clarified by simply saying that the TXIDs of inputs should be compared
> as uint256 integers.
>
I considered defining the comparison of txids in terms of integers;
however, I am concerned that this definition may be ambiguous when applied
to a variety of languages and platforms without a similar amount of
explanation as currently exists. For example, if a web wallet uses an API
to receive transaction information, this is traditionally expressed in
terms tx id strings rather than 256-bit integers. My intent is that wallets
can implement the algorithm however they wish, but should ensure that their
output is compliant with the BIP definition. IMHO the algorithm stated in
the BIP should target test cases rather than implementation, and should
leave as little room for ambiguity as possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150606/964566ef/attachment.html>

2023-06-07 15:36:36

- reply

📅 Original date posted:2015-06-05
📝 Original message:Hello all,
I have written a draft of a BIP to standardize the sorting of tx inputs and
outputs for privacy and security reasons. A few colleagues have reviewed
this and provided feedback privately, but now it's ready for feedback from
a wider audience.
If there is positive sentiment about the proposal after feedback is
integrated, I aim for a bip number to be assigned and have it accepted into
https://github.com/bitcoin/bips
Link:
https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki
For your convenience, here's the abstract:
"Currently there is no standard for bitcoin wallet clients when ordering
transaction inputs and outputs. As a result, wallet clients often have a
discernible blockchain fingerprint, and can leak private information about
their users. By contrast, a standard for non-deterministic sorting could be
difficult to audit. This document proposes deterministic lexicographical
sorting, using hashes of previous transactions and output indices to sort
transaction inputs, as well as value and locking scripts to sort
transaction outputs."
Thanks,
Kristov Atlas
Open Bitcoin Privacy Project Contributor, Blockchain.info Security
Engineer, etc.
Twitter: @kristovatlas
Blog: kristovatlas.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150605/9ba7bf54/attachment.html>

2023-06-07 15:36:35

- reply

📅 Original date posted:2015-06-04
📝 Original message:Why would Peter be accountable to you in any shape or form? What contact
did he sign onto with you?
-Kr
On Jun 4, 2015 5:52 PM, "Sven Berg" <svenberg at airmail.cc> wrote:
> 1) Hours/week have you devoted to each project out of a 40hr work week
>
> 2) Upfront and ongoing fees for use of your name
>
> 3) Break down total amounts for each project
>
> 4) Start dates of contracts for each project
>
> 5) End dates (if applicable)
>
> 6) Current and past holdings of altcoins/appcoins (including liquidation
> dates)
>
> 7) Describe return on investment to investors related to your activities
> during employment
> (other than marketing/price pump)
>
> 8) Describe your involvement with Initial Coin Offers (ICO) of
> applicable
>
> 9) Explain rational for pursuit of ICO fund sources rather than
> community/established
> businesses (Lighthouse, legit startups, etc.)
>
> --
> Berg Investigations LLC.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150604/d324704f/attachment.html>

2023-06-07 15:28:50

- reply

📅 Original date posted:2015-01-20
📝 Original message:The Open Bitcoin Privacy Project is seeking public comment on our ratings
criteria for Bitcoin wallet privacy. Please provide your feedback within
the next week through Jan 23, 2015 to ensure that it will be considered for
version 1.0 of the document.
https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/criteria.md
In conjunction with a scoring matrix that will determine the weight of each
sub-category, this criteria will be used to evaluate and score a variety of
Bitcoin wallets, which will be published on our website at
openbitcoinprivacyproject.org.
Feedback through this mailing list is, of course, welcome; if you have a
GitHub account, this is the preferred medium for proposing changes to the
document.
The current version of the criteria was authored by myself, as well as
other OBPP members including Justus Ranvier (Monetas), Chris Pacia (Bitcoin
Authenticator), and Samuel Patterson (Open Bazaar).
Thank you in advance for your feedback,
Kristov Atlas
kristovatlas at gmail.com
author at anonymousbitcoinbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150120/994fedb5/attachment.html>

2023-06-07 15:26:14

- reply

📅 Original date posted:2014-10-04
📝 Original message:Congrats, and thanks for your hard work.
I hate to reply to a release that includes a huge number of new features
with yet another feature request, so -- with apologies -- any plans for
bitcoinj to support stealth address sending and/or receiving?
https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth
Sincerely,
Kristov Atlas
On Oct 3, 2014 8:50 AM, "Mike Hearn" <mike at plan99.net> wrote:
> I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most
> popular Bitcoin libraries. It is used by at least four Android wallets,
> three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp,
> Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets,
> for academic research projects and much more.
>
> This release represents 8 months of work. The biggest new feature is HD
> wallets. Other notable enhancements include a bundled Tor client that can
> be activated with one line of code, support for multisig wallets, much
> faster and deterministic ECDSA, many API improvements and big upgrades to
> the included GUI wallet which can be seen in a new screencasted tutorial
> <https://bitcoinj.github.io/simple-gui-wallet>.
>
> The commit hash of bitcoinj 0.12
> is 83a9a71f3fff3f223d0737ad758b519a39dbbd62.
>
> New in this release
>
> - Privacy enhancements:
> - Wallets are now hierarchical and deterministic (HD) by default,
> using the BIP32 specification. Support for mnemonic codes (BIP 39) is also
> included. Change and receive addresses are no longer being reused. Old
> wallets are upgraded in place using the private key of the oldest
> non-rotating key as the seed bytes, so old backups remain valid.
> - Thanks to devrandom, we have an integrated Tor mode using the
> Orchid library. The user does not have to install the Tor client as it’s
> all pure Java. WalletAppKit users can enable usage of Tor with a single
> line of code. This support should be considered experimental for now.
> - Thanks to Kosta Korenkov, we have an experimental multisig wallets
> implementation. Multisig (also “married”) wallets are HD wallets that are
> connected to a third party risk analysis service or device. When married,
> the wallet tracks multiple BIP32 key trees, keeps them in sync and starts
> vending P2SH addresses.
> - As part of this work, transaction signing is now pluggable.
> TransactionSigner implementations can be added to the wallet and will be
> serialized into and out of the users saved wallet file. Signers are given a
> transaction to sign in sequence. This is intended for risk analysis
> providers to provide a class that talks to their server to get a signature
> of the right form, so that all bitcoinj based wallets can be easily
> upgraded to support the new provider.
> - Reject messages are now deserialized and logged, though not yet
> exposed in the API.
> - Upgraded to Guava 16 and Bouncy Castle 1.51. Thanks to Peter Dettman
> and the rest of the Bouncy Castle team, bitcoinj now uses deterministic
> ECDSA for signing and we’re now using an accelerated secp256k1
> implementation that exploits the special properties of this curve, for
> dramatically faster calculations.
> - Payment protocol code improvements: Some X.509 utility code was
> refactored out of PaymentSession for general usage. StartCom was added to
> the default trust store which was promoted to override the system trust
> store on non-Android platforms. A command line tool to dump requests to
> stdout was added.
> - Thanks to Andreas Schildbach:
> - We are now BIP62 (canonical push encodings) compliant.
> - A new Coin class replaces usage of BigInteger for marking values
> that are quantities of bitcoin. Formatting has moved into the new
> MonetaryFormat class.
> - The wallet now saves the fee paid on transactions we calculated
> ourselves. This is useful for putting it into a wallet user interface.
> - Transactions can have user memos and exchange rates attached,
> that will be saved by the wallet.
> - Support for decrypting BIP 38 protected private keys has been
> added.
> - Checkpoints can now be stored textually as well as in the old
> binary format.
> - There is also a new BtcFormat API that provides an alternative to
> MonetaryFormat that plugs in to the java.text framework.
> - Added new DNS seed from Addy Yeow.
> - Wallets can now have string->byte[] mappings attached to them, for
> lighter weight extensions.
> - Thanks to Richard Green, there is now a Python version of the
> ForwardingService program from the getting started tutorial. This shows how
> to use bitcoinj from Python using the Jython interpreter.
> - bitcoinj now probes localhost for a Bitcoin node and automatically
> uses that instead of the P2P network, when present. This means any bitcoinj
> based app can be easily upgraded from SPV to full security just by running
> Core at the same time: no setup needed.
> - Thanks to Michael Bumann, there are now more example apps showing
> how to use parts of the API.
> - WalletTemplate/WalletAppKit improvements. WalletTemplate is a demo
> app that shows how to create a cross-platform GUI wallet with a modern
> style and 60fps animations. WalletAppKit is a very high level API for
> creating apps that have a Bitcoin wallet:
> - Now supports mnemonic code and restore from seed words. A date
> picker is provided to cut down on the amount of chain that needs to be
> rescanned.
> - Support for encrypting wallets. Password is requested when
> needed. The difficulty of the scrypt function is selected to always take a
> fixed number of seconds even if hardware gets more powerful.
> - Some new animation and utility code backported from Lighthouse.
> - Tor support
> - Thanks to Martin Zachrison, the micropayment channels implementation
> has received various improvements.
> - Thanks to Eric Tierney (Circle), the Postgres store can now take a
> custom schema.
> - The Bloom filtering API has been extended so FilteredBlock objects
> can now be produced from Block objects given a BloomFilter. Previously
> there was support for client-side Bloom usage but no implementation of the
> generation part.
> - Many other bugfixes, cleanups, minor tweaks and small new APIs.
>
> *Documentation and tutorials*
>
> - A JavaScript tutorial <https://bitcoinj.github.io/getting-started-js> has
> been added, showing how to use bitcoinj from this language. More tutorials
> in other languages will come in future.
> - The “Working with the wallet
> <https://bitcoinj.github.io/working-with-the-wallet>” document has
> been significantly extended to cover encryption, watching wallets, HD
> wallets and multisig/married wallets.
> - A new document and accompanying screencast
> <https://bitcoinj.github.io/simple-gui-wallet> shows how to extend the
> WalletTemplate app to have a transactions list, and then make a
> native/bundled packages that don’t need the user to install Java. By
> following this tutorial you will learn how to make a basic cross platform
> desktop wallet of your own.
> - All other docs were refreshed to the latest APIs.
>
> *API changes*
>
> - The package name has changed to org.bitcoinj and the core Maven
> artifact name is now “bitcoinj-core”. You can auto-port most of your code
> by running find . -name '*.java' \| xargs sed -i .bak
> 's/com.google.bitcoin./import org.bitcoinj./g
> - Wallet.completeTx now throws more precise unchecked exceptions in
> edge cases, instead of IllegalArgumentException.
> - The use of BigInteger to represent quantities of Bitcoin has been
> replaced with the more efficient, type safe and useful class Coin. Coin is
> mostly source compatible with BigInteger so you can probably just do a
> search and replace to update your codebase.
> Utils.bitcoinValueToFriendlyString and friends moved to CoinFormat.
> - NetworkParameters.getProofOfWorkLimit was renamed to getMaxTarget
> for consistency with other Bitcoin codebases.
> - The library no longer uses the misleading term “nanocoins” to mean
> satoshis (the old term predated the use of the word satoshi to describe the
> smallest possible amount of bitcoin).
> - TransactionConfidence no longer tracks total work done.
> - Because outputs are now shuffled any code during that assumes the
> ordering is preserved will break. You can set the shuffleOutputs field of
> SendRequest to false to disable this behaviour if you need to.
> - The ECKey and HD API’s have changed quite a bit: several
> constructors were replaced with clearer static factory methods that make it
> more obvious how their parameters are interpreted. The new methods don’t
> change their behaviour depending on the pattern of nulls passed into them.
> - Some unit testing utilities have been moved to the new testing
> subpackage and cleaned up/rearranged. It should be easier to write unit
> tests for your app that need a simulated network now. DeterministicKey now
> derives from ECKey.
> - We now use Utils.HEX.encode() and Utils.HEX.decode() to do
> translation to and from base 16.
> - Transaction.hashTransactionForSignature was renamed to just
> hashForSignature.
> - The subVer string sent by bitcoinj now has a lower cased first
> component.
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&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/20141004/1f0ea69d/attachment.html>

2023-06-07 15:23:06

- reply

📅 Original date posted:2014-06-17
📝 Original message:On 06/17/2014 06:46 PM, Gregory Maxwell wrote:
> The correct place for more information is the Bitcointalk forum thread
> where it was announced:
> https://bitcointalk.org/index.php?topic=279249.0
Can anyone summarize the current status of the bounty? I see nothing
definite about the bounty in that thread from the beginning of January
2014, other than that the multisig address continues to accumulate
bitcoins. Meanwhile, on other mailing lists, I've seen some talk about
paying a portion or the whole of the bounty to the Dark Wallet team.
-Kristov

2023-06-07 15:20:52

- reply

📅 Original date posted:2014-05-02
📝 Original message:On 04/30/2014 03:02 AM, Wladimir wrote:
> On Sat, Apr 26, 2014 at 7:29 PM, Kristov Atlas
> <author at anonymousbitcoinbook.com> wrote:
>> Hey Wladimir,
>>
>> Thanks for building this binary. The initial problem with Qt was
>> resolved, and I was able to load the GUI that chooses my datadir. After
>> choosing the default datadir, however, it segfaulted.
> I've fixed the issue; at least on Debian 6 - which is a lot more
> conductive to development than tails :-). See
> https://github.com/bitcoin/bitcoin/pull/4094 for the gory details. New
> test build available:
>
> https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz
> (sigs: https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz.sig
> )
>
> Wladimir
Nice work! I can confirm that this dev binary runs smoothly in the
latest version of Tails, v1.0. Screenshot proof here [1]. When this is
incorporated into the next release of Bitcoin Core, will this make the
usual Linux binary compatible, or will there be a special binary just
for systems running the older Qt?
-Kristov
[1] http://postimg.org/image/p3ycwai9d/

2023-06-07 15:20:17

- reply

📅 Original date posted:2014-04-26
📝 Original message:On 04/25/2014 04:27 PM, Wladimir wrote:
> Kristov,
> I've modified the gitian build so that it builds against Qt 4.6
> instead of Qt 4.8 in this pull request:
> https://github.com/bitcoin/bitcoin/pull/4094
>
> A test build of master with that pulls gitian descriptor is available:
>
> https://download.visucore.com/bitcoin/linux-4765b8c-gitian-2d48b96.tar.gz
> https://download.visucore.com/bitcoin/linux-4765b8c-gitian-2d48b96.tar.gz.sig
>
> These bitcoin-qt executables *should* work on Debian Squeeze / Tails
> Linux. Let me know if it is the case.
>
>
Hey Wladimir,
Thanks for building this binary. The initial problem with Qt was
resolved, and I was able to load the GUI that chooses my datadir. After
choosing the default datadir, however, it segfaulted.
The segfault came after the usual message that I get when running
Bitcoin Core in Tails, which is the "sendto: Operation not permitted"
message since Core will not be able to connect to the internet without
going through Tails' Tor SOCKS proxy. When I specify the SOCKS proxy
through the command-line, I get a brief flash of the GUI before it
segfaults again.
The "Bus::open" and "IBusInputContext::createInputContext" messages are
atypical and might be related to the segfault.
Sample terminal output for latest Tails (0.23):
amnesia at amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
sendto: Operation not permitted
Segmentation fault
amnesia at amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt
Segmentation fault
amnesia at amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt -proxy=127.0.0.1:9050
Segmentation fault
-Kristov

2023-06-07 15:19:20

- reply

📅 Original date posted:2014-04-25
📝 Original message:Yes. Tails 1.1, based on Wheezy, will be out on June 10:
https://tails.boum.org/contribute/calendar/
-Kristov Atlas
On 04/24/2014 08:18 AM, Wladimir wrote:
> On Thu, Apr 24, 2014 at 10:25 AM, Wladimir <laanwj at gmail.com> wrote:
>> On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. <wtogami at gmail.com> wrote:
>>
>> But indeed we need to decide on a cut-off point. I'd have preferred
>> 4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010.
>> Apart from tails it doesn't seem like anyone is using those old stable
>> distributions on the desktop.
> Does anyone know of the timeframe in which tails will switch to a
> newer version of Qt?
>
> As it's debian based: will switch to a Wheezy/7.4. Wheezy has Qt 4.8
> so is decidedly unproblematic.
>
> I see they're working on migration at least:
>
> - https://tails.boum.org/blueprint/Wheezy/
> - https://git-tails.immerda.ch/tails/log/?h=feature/wheezy
>
> Wladimir
>
> ------------------------------------------------------------------------------
> 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

2023-06-07 15:19:19

- reply

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 06:28 PM, Gregory Maxwell wrote:
> Tails users usually can't really build it from source— talks is a live
> boot mostly stateless linux distribution for privacy applications.
> It's really good in general.
>
> I agree that we shouldn't be statically linking QT on linux generally
> (due to things like theming), though maybe we could just have the
> build process dump out a seperate extra static QT binary just for
> these other cases? I feel like the work maintaining it would be less
> than what we've had in answering questions/complaints about it.
>
> ------------------------------------------------------------------------------
Dumping out a separate, extra static QT binary is a great idea.

2023-06-07 15:19:18

- reply

📅 Original date posted:2014-04-23
📝 Original message:On 04/23/2014 04:39 PM, Warren Togami Jr. wrote:
> On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas
> <kristovatlas at gmail.com <mailto:kristovatlas at gmail.com>> wrote:
>
> I see that the latest nightly build (thanks for that, Warren) is
> still not compatible with Tails/Debian Squeeze. Is there still an
> intention to address this issue? Might it be fixed by 0.9.2?
>
>
> If I understand the situation, bitcoind does work but not bitcoin-qt
> due to qt-4.6? If that is so, then the official Bitcoin 0.8.6
> binaries didn't work on Squeeze either this is not a regression.
>
> The priority is for bitcoind to work on as many distributions as
> reasonably possible as older stable distributions are most often
> headless. If you are a rare user who needs Bitcoin-Qt on an
> incompatible system you can at least build it from source.
>
> Warren
Bitcoin-Qt 0.8.6 worked fine on Tails (and Debian Squeeze, I assume).
So, it is a regression.
Here's output from the latest nightly build for Linux:
amnesia at amnesia:~/bitcoin-0.9.99.0-20140422-2bbecc8-linux/bin/32$ ./bitcoin-qt
./bitcoin-qt: symbol lookup error: ./bitcoin-qt: undefined symbol: _ZN19QAbstractProxyModel11setItemDataERK11QModelIndexRK4QMapIi8QVariantE
Since Tails has many simple development tools like "make" stripped out
for security reasons, one could not simply build from source in Tails.
It might be possible to build in Debian Squeeze and transplant that,
however. I'll have to give that a shot some time. I'd argue that Tails
is an incredibly important -- and hardly obscure -- Linux distribution
that Bitcoin should endeavour to support. See:
https://tails.boum.org/press/index.en.html
-Kristov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/be54ba9b/attachment.html>

2023-06-07 15:19:17

- reply

📅 Original date posted:2014-04-23
📝 Original message:On 04/22/2014 09:30 AM, Warren Togami Jr. wrote:
> Bitcoin-Translators mailing list is an announce-only mailing list for
> developers to communicate to translators at particular times when new
> translations are needed. Replies and discussion would go to the
> bitcoin dev list. Subscriptions to this list would additionally be
> valuable to the project as it allows for a convenient way to ask for
> translations of other related projects like bitcoin.org
> <http://bitcoin.org> that are hosted on theTransifex platform.
> Whenever source strings of significance are changed or deadlines are
> announced, translators will learn of work to be done in Transifex
> quickly as they will all be subscribed to this announce list.
> Discussion of translation issues should be on the Bitcoin-Development
> list.
>
> Development Roadmap of Bitcoin Core 0.9.2
>
> The Bitcoin Core developers have a desire to do a mostly bug-fix and
> translation update release in v0.9.2. A feature and string freeze will
> start about 3 weeks from now.
>
>
> The purpose of this development roadmap is to communicate the project
> intent and to better organize volunteers. Hopefully doing so will make
> clear when particular types of contributions are most welcome and help
> to push the release process forward in a more timely manner while also
> improving the quality of the release. Missing a target goal is OK.
> The developers may decide to delay particular goals if there are good
> reasons on a case-by-case basis. While schedules may slip, it is
> generally a good thing for a goal to have existed.
>
>
> Schedule (subject to change)
>
> 13 May 2014:Feature freeze. Source string freeze. Release candidate.
>
> 20 May 2014: Testing of a release candidate is roughly a week. More
> time can be added at the discretion of the developers to allow for
> testing if further release candidates are deemed necessary due to
> subsequent changes.
>
>
> Nightly Gitian Builds
>
> https://bitcointalk.org/index.php?topic=571414.0
>
> To make it easier for non-developers and translators to get involved
> in testing unofficial deterministic nightly builds are now available.
>
>
> Warren Togami
I see that the latest nightly build (thanks for that, Warren) is still
not compatible with Tails/Debian Squeeze. Is there still an intention to
address this issue? Might it be fixed by 0.9.2?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/1be17057/attachment.html>