Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[Pieter Wuille via bitcoin-dev]

On Thursday, August 19th, 2021 at 1:02 PM, ts via bitcoin-dev 
 wrote:

> > In any case --- the last 5 characters of a bech32 string are already a 
> > human-readable 5-digit code, with fairly good properties, why is it not 
> > usable for this case?

Side note: it's actually the last six characters.

>
> Well, because
>
> a) most people don't know that
>
> b) it is specific to bech32
>
> c) it is not easily readable being the last digits of a long address 
> (although this could be

I think this is a misconception. For the purpose of verifying that you have the 
*right* address (rather than just a valid one), the checksum, or even the 
knowledge that a checksum is present, is completely irrelevant.

In honestly-generated addresses, every character except the prefix (the ~2 
first characters for P2PKH and P2SH, and the ~4 first characters for 
BIP173/BIP350 native segwit addresses) has exactly the same amount of entropy. 
Instead of adding say a 4 character code, just tell people to compare any 4 
characters of their choosing. Or more - I would hope people are already 
comparing (much) more than 4 characters already.

It doesn't matter if the characters being compared are checksum characters or 
data characters. In honestly-generated addresses, both are equally random.

Adding a special 4 character "external" checksum IMO would instead encourage 
people to perhaps just compare those 4 characters instead of the rest (or at 
least, focus mostly on those). That could easily worsen how well comparisons 
are done in practice...

Cheers,

--
Pieter

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Using transaction version number in different projects

[Pieter Wuille via bitcoin-dev]

On Sunday, August 29th, 2021 at 5:32 AM, Prayank via bitcoin-dev 
 wrote:

> Wanted to know if others think we should allow more numbers in transaction 
> version by considering such transaction standard. I have shared an example 
> how transaction version can be used to bet on something that involves 2 
> outcomes:
> https://gist.github.com/prayank23/6f54e9a27f057abd1182436e7f88d1ac

I can't say I understand what you're suggesting, or what transaction version 
numbers have to do with it, so take the following with the caveat that I may be 
missing your point.

Generally, my view is that Bitcoin transactions should solely contain the 
information necessary for the world to validate them. Given that, as of now, 
there are no consensus rules (or even generally-adopted relay policies) that 
care about the version number except it being 1 or 2 (due to BIP68), I would 
say that the usage of anything but those 2 possible numbers is both pointless 
and a gratuitous loss of privacy: for numbers with no protocol-defined meaning, 
the usage of an uncommon one reveals something to the world that should be 
privately communicated to the parties involved instead.

Combined with the fact that currently-unused version numbers may well be used 
for future consensus rules like BIP68, which any use you're suggesting may 
interfere with, I say no: versions numbers with no protocol-defined meaning 
should not be standard. They are reserved for future extensions.

Cheers,

--
Pieter___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[Pieter Wuille via bitcoin-dev]

On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev 
 wrote:

> Following up on my original proposal, I would like to get some more feedback 
> of the community
>
> to see if this could be realized at some point. Also, any recommendations as 
> to who to contact
>
> to get things rolling?

I honestly don't understand the point of what you're suggesting.

* If you're concerned about random typos, this is something already 
automatically protected against through the checksum (both base58check or 
bech32/bech32m).

* If you're concerned about accidentally entering the wrong - but honestly 
created - address, comparing any few characters of the address is just as good 
as any other. It doesn't even require the presence of a checksum. Looking at 
the last N characters, or the middle N, or anything except the first few, will 
do, and is just as good as an "external" checksum added at the end. For 
randomly-generated addresses (as honest ones are), each of those has exactly as 
much entropy.

* If you're concerned about maliciously constructed addresses, which are 
designed to look similar in specific places, an attacker can just as easily 
make the external checksum collide (and having one might even worsen this, as 
now the attacker can focus on exactly that, rather than needing to focus on 
every other character).

Things would be different if you'd suggest a checksum in another medium than 
text (e.g. a visual/drawing/colorcoding one). But I don't see any added value 
for an additional text-based checksum when addresses are already text 
themselves. This is even disregarding the difficulty of getting the ecosystem 
to adopt such changes.

Cheers,

--
Pieter

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Camouflage: A project dedicated to Hal Finney

[Aymeric Vitte via bitcoin-dev]

Hi,

Maybe let's discuss the details privately since some might be off topic
for this list, as a quick answer the discussion I linked to is about
using the Tor protocol between bitcoin nodes piping the bitcoin protocol
via node-Tor (not to be misunderstood with the Tor network again), nodes
can be whatever you like including browsers (but the use of the Tor
browser is not foreseen neither encouraged, disabling js and WebRTC is
valid when you are browsing, but browsing is not what is proposed here),
they can be wallets too, if you look at the browserification of
bitcoin-transactions (https://peersm.com/wallet) there is a mechanism to
make sure the js code you loaded is the correct one, you can also create
a bookmarklet button with the js code to run it directly inside the
browser without having to load it

Regards

Aymeric


Le 29/08/2021 à 00:40, Prayank a écrit :
> Hi Aymeric,
>
> Thanks for sharing the link. 'bitcoin-transactions' and 'node-Tor'
> looks interesting although I will have to check details and try things.
>
> One observation: I noticed it's in JavaScript and will use WebRTC.
> Users who care about privacy normally disable both while using a browser.
>
> -- 
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Aug 28, 2021, 22:06 by ayme...@peersm.com:
>
> Probably you could add to your links this discussion/issue
> https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853
>
>
> Le 27/08/2021 à 23:29, Prayank via bitcoin-dev a écrit :
>> I wish Hal Finney was with us today and help us improve privacy
>> in Bitcoin. I like reading his posts and one of them is
>> https://bitcointalk.org/index.php?topic=156390.msg1659654#msg1659654
>>
>> I had emailed about Privacy related things on July 23:
>> 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019276.html
>>
>> It was my birthday on 23 and had few beers so maybe email wasn't
>> very focused. Although basic idea was to initiate discussion
>> about improving privacy in different Bitcoin projects. I did not
>> receive any response except one person who liked the video I
>> mentioned in the email. So here is one project which uses GitHub
>> pages and will have the following things:
>>
>> 1.Issues and PRs related to privacy from different Bitcoin
>> projects. I have added few from Bitcoin Core (full node
>> implementation), Bisq(DEX) and LND (LN implementation) right now.
>> 2.Blog section for my opinion on different privacy related issues
>> and PRs.
>> 3.'Hall of Fame' section to appreciate the contribution of devs
>> who are improving privacy in different Bitcoin projects.
>>
>> I will be happy if this project helps in improving privacy or
>> helps users/devs in any other way. This project will never turn
>> in to a paid newsletter or needs any sponsors, however any
>> contribution to make the website better would be appreciated.
>> Edward Snowden can also contribute if he wants to do more than
>> just tweets to help improve Bitcoin privacy.
>>
>> Link: https://prayank23.github.io/camouflage/
>>
>> Will move everything to new repository this weekend:
>> https://github.com/BlockchainCommons/Bitcoin-Camouflage
>>
>> -- 
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

-- 
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Anti-spies and private torrents, dynamic blocklist: 
http://torrent-live.peersm.com
Peersm : http://www.peersm.com

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Using transaction version number in different projects

[Prayank via bitcoin-dev]

print('Hello, world!')

I had asked related question on Bitcoin Stackexchange: 
https://bitcoin.stackexchange.com/questions/108248/version-in-transaction

Wanted to know if others think we should allow more numbers in transaction 
version by considering such transaction standard. I have shared an example how 
transaction version can be used to bet on something that involves 2 outcomes:

https://gist.github.com/prayank23/6f54e9a27f057abd1182436e7f88d1ac

Anything wrong with this approach? We could use oracles (DLC) or something else 
later to settle the bet and create a release transaction. However wanted to 
confirm if everything looks okay until funding transaction. Nothing involves 
any centralized server or trusting third parties:
1.Tx1 is a normal OP_RETURN transaction.
2.App will save results for `getrawmempool` regularly in local db. It will 
check if any transaction wants to participate in bets.
3.Multisig address will be created using two public keys. One entered by user 
and other from mempool.
4.Funding transaction will use the version bits to indicate if Alice wants to 
bet on India or Australia.


-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Braidpool: Proposal for a decentralised mining pool

[pool2win via bitcoin-dev]

We have been working on a peer to peer mining pool that overcomes the
problems faced by P2Pool and enables building a futures market for
hashrate.
 
The proposal can be found here:
https://github.com/pool2win/braidpool/raw/main/proposal/proposal.pdf
 
The key features of the pool are:
 
1. Lower variance for smaller miners, even when large miners join
  the pool.
2. Miners build their own blocks, just like in P2Pool.
3. Payouts require a constant size blockspace, independent of the
  number of miners in the pool.
4. Provide building blocks for enabling a futures market of hash
  rates.
 
Braidpool: Decentralised Mining Pool for Bitcoin
 
Abstract. Bitcoin P2Pool's usage has steadily declined over the years,
negatively impacting bitcoin's decentralisation. The variance in
earnings for miners increases with total hashrate participating in
P2Pool, and payouts require a linearly increasing block space with the
number of miners participating in the pool. We present a solution that
uses a DAG of shares replicated at all miners. The DAG is then used to
compute rewards for miners. Rewards are paid out using one-way payment
channels by an anonymous hub communicating with the miners using Tor's
hidden services. Using the payment channels construction, neither the
hub nor the miners can cheat.

Full proposal at
https://github.com/pool2win/braidpool/raw/main/proposal/proposal.pdf
 
Details on trading hashrate are here:
https://pool2win.github.io/braidpool/2021/08/18/deliver-hashrate-to-market-makers.html
 
@pool2win
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev