Re: [bitcoin-dev] Ring VS Schnorr signatures

[Casciano, Anthony via bitcoin-dev]

In the world of architectural trade-offs, specifically: confidentiality versus 
base layer performance, and
in the current regulatory environment, as global monetary affairs begin to get 
"more real," I'm now leaning towards greater confidentiality rather than my 
earlier preference for performance.

Do Ring sigs with Stealth addresses impede blockchain performance or do they 
mis-align with Bitcoin's longer term
dev roadmap?


~ TC


From: bitcoin-dev-boun...@lists.linuxfoundation.org 
 on behalf of 
bitcoin-dev-requ...@lists.linuxfoundation.org 

Sent: Monday, October 28, 2019 8:00 AM
To: bitcoin-dev@lists.linuxfoundation.org
Subject: bitcoin-dev Digest, Vol 53, Issue 41

Send bitcoin-dev mailing list submissions to
bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
bitcoin-dev-requ...@lists.linuxfoundation.org

You can reach the person managing the list at
bitcoin-dev-ow...@lists.linuxfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."


Today's Topics:

   1. Fwd: node-Tor is now open source in clear (andmodular)
  (Aymeric Vitte)


--

Message: 1
Date: Mon, 28 Oct 2019 11:33:32 +0100
From: Aymeric Vitte 
To: Bitcoin Dev 
Subject: [bitcoin-dev] Fwd: node-Tor is now open source in clear (and
modular)
Message-ID: <70e77789-9fce-0d54-0aed-361035e79...@gmail.com>
Content-Type: text/plain; charset="utf-8"

FYI, javascript implementation of the Tor protocol on server side and
inside browsers

Not related directly to bitcoin-dev but might be of some use one day to
anonymize bitcoin apps (light wallets for example)


 Message transf?r? 
Sujet?: node-Tor is now open source in clear (and modular)
Date?:  Thu, 24 Oct 2019 18:02:42 +0200
De?:Aymeric Vitte 
Pour?:  tor-t...@lists.torproject.org



Please see https://github.com/Ayms/node-Tor and http://peersm.com/peersm2

This is a javascript implementation of the Tor protocol on server side
(nodejs) and inside browsers, please note that it is not intended to add
nodes into the Tor network, neither to implement the Tor Browser
features, it is intended to build projects using the Tor protocol from
the browser and/or servers (most likely P2P projects), the Onion Proxy
and Onion Router functions are available directly inside the browser
which establishes circuits with other nodes understanding the Tor
protocol (so it's not a "dumb" proxy), but it can of course establish
circuits with the Tor network nodes (see
https://github.com/Ayms/node-Tor#test-configuration-and-use) and act as
a Tor node

It is financed by NLnet via EU Horizon 2020 Next Generation Internet
Privacy & Trust Enhancing Technologies, now open source under a MIT
license and we made it modular, it is fast (extensively tested when
video streaming was there, especially with bittorrent or ORDB concept)
and the total unminified code
(https://github.com/Ayms/node-Tor/blob/master/html/browser.js) is only 1
MB (so ~600 kB minified) which is quite small for what it does, this is
not a browser extension/module but pure js

Possible next steps are to implement elliptic crypto and connections via
WebRTC Snowflake (peersm2 above uses WebSockets a bit the way flashproxy
was working, ie implementing the ws interface on bridges side), as well
as integrating it with "Discover and move your coins by yourself"
(https://peersm.com/wallet) for anonymous blockchain search and
anonymous sending of transactions from the browser

--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

-- next part --
An HTML attachment was scrubbed...
URL: 


--

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


End of bitcoin-dev Digest, Vol 53, Issue 41
***
___

Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

[Johan Torås Halseth via bitcoin-dev]

On Mon, Oct 28, 2019 at 6:16 PM David A. Harding  wrote:

> A parent transaction near the limit of 100,000 vbytes could have almost
> 10,000 outputs paying OP_TRUE (10 vbytes per output).  If the children
> were limited to 10,000 vbytes each (the current max carve-out size),
> that allows relaying 100 mega-vbytes or nearly 400 MB data size (larger
> than the default maximum mempool size in Bitcoin Core).
>

Thanks, Dave, I wasn't aware the limits would allow this many outputs. And
as your calculation shows, this opens up the potential for free relay of
large amounts of data.

We could start special casing to only allow this for "LN commitment-like"
transactions, but this would be application specific changes, and your
calculation shows that even with the BOLT2 numbers there still exists cases
with a large number of children.

We are moving forward with adding a 1 block delay to all outputs to utilize
the current carve-out rule, and the changes aren't that bad. See Joost's
post in "[PATCH] First draft of option_simplfied_commitment"

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