Re: [bitcoin-dev] Bitcoin Legal Defense Fund

2022-01-14 Thread Aymeric Vitte via bitcoin-dev
(P2P?) Electronic Cash (Defense?) Fund or Electronic Cash Foundation ?
More neutral, potentially covering others than Bitcoin, mimicking a bit
EFF (even if as stated US is not the only target), referring to
Satoshi's paper where everything started

Maybe I am not up to date but it would be good to know what are the
current procedures with the Tulip thing

Aymeric


Le 13/01/2022 à 19:20, jack via bitcoin-dev a écrit :
> Hi Prayank,
>
>> On 13 Jan 2022, at 10:13, Prayank  wrote:
>> I had few suggestions and feel free to ignore them if they do not make sense:
>>
>> 1.Name of this fund could be anything and 'The Bitcoin Legal Defense Fund' 
>> can be confusing or misleading for newbies. There is nothing official in 
>> Bitcoin however people believe things written in news articles and some of 
>> them might consider it as an official bitcoin legal fund.
> Excellent point. Will come up with a better name.
>
>> 2.It would be better if people involved in such important funds do not 
>> comment/influence soft fork related discussions. Example: Alex Morcos had 
>> some opinions about activation mechanism during Taproot soft fork IIRC.
> Yes. Will think through this and board operating principles we can share 
> publicly, which would probably include criteria for how cases are chosen, to 
> protect against this board and fund influencing direction.
>
> Open to ideas and suggestions on all.
>
> jack
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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


Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

2021-12-13 Thread Aymeric Vitte via bitcoin-dev


> It's just one example of a downside of (a particular way of) using
> Tor. That doesn't mean I recommend against using Tor for Bitcoin
> traffic at all; my point was simply that there are trade-offs, and
> aspects of privacy of the P2P protocol that Tor does not address, and
> thus one shouldn't assume that all problems are solved by "just use Tor".
There are many downsides since the default behavior of the Tor network
does not apply to p2p networks, another example is a bitcoin node
exiting transactions (I thought you were referring to this), since the
same Tor circuit is used during some time most likely the transactions
are related to the same node even if we don't know its IP

According to the bitcoin github example discussion link I gave, I am not
saying that Tor network nodes should not be used, I am saying that they
should be used à la node-Tor, or more precisely like the github example
and http://www.peersm.com/Convergence-2020.pdf, one of the main
differences are how behave the first node (ie the originating bitcoin
node), HS/RDV, nb of hops, hybrid nodes

Another drawback is that bitcoin community lets bitcoin nodes operators
play the way they like with torrc

@Prayank, regarding js/webrtc my previous answer was not partial, please
email in private if you need more, it's just a part of the project (but
important since disruptive), which is already advertised widely
(bitcoin, ipfs, covid apps, videoconf, etc, there are plenty of links on
github, lists, specs discussion, probably I should reference them), the
answer is always the same: "very interesting, go ahead", but no, it is
designed to be integrated by the projects, not by myself, and the only
thing missing to get rid of myself is to release phase4


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


Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

2021-12-12 Thread Aymeric Vitte via bitcoin-dev
Using the Tor network to bypass censorship for bitcoin can work but is a
very poor solution, the Tor network is very centralized, very small,
watched and controlled, with plenty of features that do not apply to
other protocols than those made to be used with the Tor Browser, Pieter
gave a simple example, that you can solve easily changing the circuits,
the problem remains that you really need to be a super expert to escape
all the dangers of the Tor network, not even sure it's possible unless
you use something else than the Tor project code

Believe it or not, node-Tor is a more than ten years old project (and
not a duplicate of the Tor network), so I know what I am talking about,
different studies of mine show also that the more you try to hide the
more you can get caught, even on really decentralized networks like
bittorrent, unlike another common belief that in such big networks it's
difficult to track/deanonymize peers, it is not

Extra measures like rebroadcasting can maybe add something, but back to
the previous sentence, extra measures can also help to catch/track you
if not well designed/thought

What I am proposing since years, not only to bitcoin, is to use the Tor
protocol independently of the Tor network, and from the browsers also
acting as nodes (not to be misunderstood with the Tor Browser, this has
nothing to do) probably someone one day will understand it

Le 12/12/2021 à 14:38, Karl a écrit :
>
>
> On Sun, Dec 12, 2021, 7:42 AM Aymeric Vitte via bitcoin-dev
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> Indeed, I reiterate that using the Tor network for Bitcoin or
> whatever protocol not related to the Tor Browser (ie browsing and
> HS) does not make sense, for plenty of reasons
>
>
> Please cite this.  It is very hard to believe.
>
> Personally, I have encountered network blocking of bitcoin peers, and
> Tor is one way to reconnect with the network when this happens.
>
>
> Regardless, reasonable rebroadcasting of nonlocal transactions is a
> hands-down good thing.  This does not make them anonymous, but it does
> make it a little harder to track their origin, and additionally it
> makes their transmission more robust.
>
> Every extra measure is a good thing, as everything eventually fails.
>

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


Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

2021-12-12 Thread Aymeric Vitte via bitcoin-dev
Indeed, I reiterate that using the Tor network for Bitcoin or whatever
protocol not related to the Tor Browser (ie browsing and HS) does not
make sense, for plenty of reasons

But using the Tor protocol outside of the Tor network (and inside
browsers for wallets for example) does:
https://github.com/Ayms/node-Tor#presentation and
https://github.com/Ayms/node-Tor#phase-4-and-phase-5, anonymizing nodes
can just be already existing bitcoin nodes, example:
https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853


Le 11/12/2021 à 17:21, Pieter Wuille via bitcoin-dev a écrit :
>> It is that the solution to privacy is to use privacy-enhancing network
>> communications, such as TOR. I am not against a mechanism to rebroadcast
>> transactions more robustly if the mempool of adjoining nodes has
>> forgotten about them, but the truth is, all transactions originate from
>> some node, and there are methods that allow an individual node to be
>> identified as the likely source of a transaction unless privacy-enabled
>> networks are utilised. Having a different method to cause rebroadcast
>> does not obfuscate the origin.
> You're talking about distinct aspects of transaction privacy.
>
> The rebroadcasting approach as it exists on the network, where wallets are 
> responsible for their own rebroadcasting, directly reveals to your peers a 
> relation between nodes and transactions: whenever any node relays the same 
> transaction twice, it almost certainly implies they are the origin.
>
> This is just a node-transaction relation, and not necessarily IP-transaction 
> relation. The latter can indeed be avoided by only connecting over Tor, or 
> using other privacy networks, but just hiding the relation with IP addresses 
> isn't sufficient (and has its own downsides; e.g. Tor-only connectivity is 
> far more susceptible to partition/Eclipse/DoS attacks). For example seeing 
> the same node (even without knowing its IP) rebroadcast two transaction lets 
> an observe infer a relation between those transactions, and that too is a 
> privacy leak.
>
> I believe moving to a model where mempools/nodes themselves are responsible 
> for rebroadcasting is a great solution to improving this specific problem, 
> simply because if everyone rebroadcasts, the original author doing it too 
> does not stand out anymore. It isn't "fixing privacy", it's fixing a specific 
> leak, one of many, but this isn't a black and white property.
>
> Cheers,
>
> --
> Pieter
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
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

2021-08-29 Thread 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


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

2021-08-28 Thread Aymeric Vitte via bitcoin-dev
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

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


Re: [bitcoin-dev] Taproot NACK

2021-03-16 Thread Aymeric Vitte via bitcoin-dev
It's incredible how this troll keeps trolling and the list (bitcoin-dev
!!) keeping attention


Good troll, really


Le 14/03/2021 à 11:13, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev a
écrit :
> Good Afternoon,
>
> Since this is on the list I will open without my thank-you. You will
> kindly be advised that my title are recorded in both Scotland and with
> England, also provided by record in Australia's account with names
> recorded. If you wonder than am I Wills it is because a long time
> before we ever saw Wills in print with an article provided reference to
> any Prince in the past thirty-years there I am Wills already. Title The
> Australian was prepared a long time to my requiest to wait until it was
> better presented, with at least some acquired experience in business to
> understand a market like BHP services. Thereby you accept a separate
> title Lord being with feudal and Lord being with the appointments
> direct to the service of the monarch's house Earl and similar up to
> Duke and King and higher being heard usually the monarch's preference
> Your Excellency or Your Highness being His service. I have never been
> any Prince. If any Prince titles came the instructions were they were
> retained to be considered not accepted not refused.
>
> If you had each fools to inquire.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>  
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>  
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this
> email if misdelivered.
> 
> *From:* bitcoin-dev  on
> behalf of Eric Voskuil via bitcoin-dev
> 
> *Sent:* Saturday, 13 March 2021 9:30 AM
> *To:* R E Broadley ; Bitcoin
> Protocol Discussion 
> *Subject:* Re: [bitcoin-dev] Taproot NACK
>  
> I’m pretty sure it’s subtle mockery. Even a legit title doesn’t
> warrant additional attention.
>
> e
>
> > On Mar 12, 2021, at 14:02, R E Broadley via bitcoin-dev
>  wrote:
> >
> > Can I just point out (to those addressing James as Lord/Excelency/etc
> > that he isn't noble nor a Lord, so just wanted to mention this in case
> > people were giving him more attention than the average person would be
> > afforded.
> >
> > My 2p (an equal 2p) on Taproot is ACK, by the way.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ___
> 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
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

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


Re: [bitcoin-dev] BIP Proposal: Wallet Interface

2020-12-25 Thread Aymeric Vitte via bitcoin-dev
Resending to the list since I am using a different email

Complement: if anonymity is required from the browser (or elsewhere) you
might consider looking at https://github.com/Ayms/node-Tor too


Le 24/12/2020 à 20:40, Aymeric Vitte a écrit :
>
> You might want to take a look at: https://peersm.com/wallet
>
> And https://github.com/Ayms/bitcoin-transactions
>
> "wallet" is not the very correct word, it's more bitcoin cli outside
> of bitcoin core but for now not linked to an explorer/tx system which
> makes it probably still not so easy to use for the transactions part
> (which can be extended to lightning, etc)
>
> The idea is to propose to people most of the tools they need to manage
> their coins by themselves, or at least understand better what they are
> doing
>
> "People should not be encouraged to write or use web browsers for
> their wallet." --> yes and no, please crack the standalone webapp
> above, so it's finally a no when things are done correctly, of course
> there is no story of keys storage inside browsers or online stuff with
> keys
>
> Maybe this can be turned one day into a w3c api like webcrypto
> (window.bitcoin as you sketch)
>
> Le 23/12/2020 à 08:29, monokh via bitcoin-dev a écrit :
>> Thanks for the input Luke.
>>
>> > 1) People should not be encouraged to write or use web browsers for
>> their wallet.
>>
>> Indeed. Holding keys in the browser can be very insecure, however the
>> spec is not limited to this. I will amend to make this clear. The
>> same interface can be used to communicate from a web context or even
>> desktop application with hardware wallets where keys are segregated
>> safely. The prominent hardware wallets already have such an
>> interface. Unfortunately as there has been no standardisation, an
>> application must specifically provide an implementation for each
>> wallet to be compatible.
>>
>> > 2) You may want to look over earlier work in this area.
>>
>> Please share if you have specifics in mind. What has been considered
>> were mainly hardware wallet apis. The requests have been defined such
>> that they would be compatible. I will make references to such
>> considerations in the text. I welcome any feedback on what may be
>> missing or problematic for these providers - something I will also
>> pursue outwith the thread.
>>
>> -monokh 
>>
>> On Wed, Dec 23, 2020 at 2:15 AM Luke Dashjr > > wrote:
>>
>> 1) People should not be encouraged to write or use web browsers
>> for their
>> wallet.
>> 2) You may want to look over earlier work in this area.
>>
>> On Tuesday 22 December 2020 14:43:11 monokh via bitcoin-dev wrote:
>> > Hi
>> >
>> > This is a first draft of a BIP we intend to submit. The main
>> intention is
>> > to define a simple interface that wallets and applications can
>> agree on
>> > that would cover the vast majority of use cases. This can
>> enable writing
>> > bitcoin applications (e.g. time lock, multi sig) on the web
>> that can be
>> > seamlessly used with any compatible wallets. We have
>> implementations of
>> > such examples but I don't want to turn this thread into a
>> promotion and
>> > rather focus on the spec.
>> >
>> > Appreciate input from the list. Please share if there are
>> existing efforts,
>> > relevant specs or use cases.
>> >
>> > --
>> >
>> > A wallet interface specification for bitcoin applications
>> >
>> > ## Abstract
>> >
>> > This BIP describes an API for Bitcoin wallets and applications as a
>> > standard.
>> >
>> > ## Summary
>> >
>> > Bitcoin wallets should expose their address derivation and signing
>> > functions to external applications. The interface would be
>> expressed as
>> > follows in javascript:
>> >
>> > ```
>> > {
>> > // Wallet Metadata
>> > wallet: {
>> > name: 'Bitcoin Core'
>> > },
>> >
>> > // Request access to the wallet for the current host
>> > async enable: (),
>> >
>> > // Request addresses and signatures from wallet
>> > async request ({ method, params })
>> > }
>> > ```
>> >
>> > In the web context the interface could be exposed at the top
>> level of a
>> > webpage, for example under `window.bitcoin`. However this spec
>> does not
>> > intend to define any standards for how and where the interfaces
>> should be
>> > exposed.
>> >
>> > ## Motivation
>> >
>> > Due to the seldom available APIs exposed by wallets,
>> applications (web or
>> > otherwise) are limited in how they are able to interact.
>> Generally only
>> > simple sends have been available. A more robust API that
>> introduces other
>> > requests will promote richer Bitcoin applications.
>> >
>> > Additionally, wallet APIs have frequently included
>> inconsistencies in their
>>   

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-08 Thread Aymeric Vitte via bitcoin-dev

Le 08/06/2020 à 06:56, ZmnSCPxj via bitcoin-dev a écrit :
> Running both Bitcoin and Lightning nodes on clearnet automatically links 
> them, making them easier to attack, whereas running Lightning on Tor does not.
> Of course, they could still be linked by onchain transaction monitoring, but 
> at least this increases the effort to attack, hopefully it becomes marginally 
> less desirable to attack you.
Or makes it easier in fact, correcting what I said in my previous
answer, stating a "yes" for a mixed bitcoin and/or LN node in clearnet
and Tor, with or without different IPs, it's probably not difficult for
the Tor attacker to identify you (for example pinging the nodes with a
new received tx to see who has it in mempool)

Similar to "Deanonymizing the VPN peers"
https://github.com/Ayms/torrent-live, this is not public but the method
uses the clearnet/VPN "mixity" and unexpectedly the more you try to hide
the better you can get deanonymized

The conclusion is always the same: do not use the Tor network for
services it is not designed for
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-05 Thread Aymeric Vitte via bitcoin-dev
Hi,

As far as I understand your answer is "let's try to use what exists",
this is not what I am proposing and not the Tor network, no "standard"
exit nodes, different hidden services, decentralized anonymizer network
unlike the Tor network, nodes are anonymizing themselves

Comments below, please let me know what is unclear in the description of
the project so I can modify it because all the time I get the impression
that it is mixed with the Tor network while it just has a very little to
do with it, and I don't get that the simple principle of communicating
between nodes using the Tor protocol without RDV points is never considered

Regards,

Le 05/06/2020 à 13:44, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>> The issue each time there are discussions/research linking to Tor is that it 
>> is biased since the beginning because based on a wrong postulate: using the 
>> Tor network
>>
> Well, in the interest of using the wrong tool for a highly important job, let 
> me present this thought:
Then for an important job people should use the right tool...
>
> * The Tor network is weakened due to its dependence on a limited set of exit 
> nodes.
And centralized structure, limited set of nodes to make it short, for
some (or a lot) misbehaving, not designed for bitcoin, nothing prevents
bitcoin from operating its own anonymizer system, which I am proposing
> * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
Good to a certain extent... if you want to hide that you are operating a
bitcoin node you can use RDV points (ie hidden services) but if you
don't care you just connect anonymized circuits between bitcoin nodes,
this is more "direct" and does not exist in the Tor network, this
includes light clients that can act as relays also
> * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet 
> connections, the issue is with Tor-to-clearnet connections.
There are plenty of Tor-to-Tor issues, not theoretical but in the real
world, "Tor-to-clearnet" can be done outside of the Tor network, ie the
bitcoin network
> * Of course, no miner is going to run over Tor because latency, so all the 
> miners will be on clearnet.
Probably, again I am not proposing a remake of the Tor network, I don't
see the use for a miner to hide (neither for a bitcoin node to use RDV
points), but they can be part of the global anonymized system, please
see below
> * So make your own bridge between Tor and clearnet.
> * Run two fullnodes on your computer (with sufficient ingenuity, you can 
> probably share their block storages, or make one pruning).
> * One fullnode is on the public network but runs in `blocksonly` so it does 
> not propagate any transactions (which might be attached to your public IP).
> * The other fullnode is on the Tor network and has an `-addnode` to the 
> public-network node via `localhost`, which I assume is very hard for an 
> eclipse attacker to get at.
> * Use the Tor-fullnode to propagate your transactions.
Yes but one full node should be able to do this alone, ie implement both
interfaces, like miners and everybody in fact (or Peersm bridges with
bittorrent if you look at the history of the project)
>
> Of course, the eclipse attacker can still attack all Tor exit nodes and block 
> outgoing transaction traffic to perform eclipse attacks.
> And if you decide to propagate transactions to the public-network node then 
> you pretty much lose your privacy there.

Please see the convergence link, it's not based on the assumption that
"the more you are the better you can hide and the lesser you can get
attacked", this does not work at all, it's based on the assumption that
even with a reduced set of peers it becomes very difficult to know who
is doing what and whom is talking to whom, the concept of
exiting/bridging to clearnet(s) is not clearly detailed in this version
but appears on the drawings


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


Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-05 Thread Aymeric Vitte via bitcoin-dev

Le 04/06/2020 à 04:58, ZmnSCPxj via bitcoin-dev a écrit :
>> [Tor is tricky](https://arxiv.org/abs/1410.6079) too
> Since the issue here is that eclipsing of Bitcoin nodes is risky, it strikes 
> me that a mitigation would be to run your Bitcoin fullnode on clearnet while 
> running your Lightning node over Tor.
> Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) 
> "only" loses you the ability to pay, receive, or route (and thereby earn 
> forwarding fees), but as long as your blockchain view is clear, it should be 
> fine.
>
> Of course, the Lightning node could still be correlated with the Bitcoin node 
> when transactions are broadcast with the attached Bitcoin node (as noted in 
> the paper).
> Instead the Lightning node should probably connect, over Tor, to some random 
> Bitcoin fullnodes / Electrum servers and broadcast txes to them.
>
> And this seems to tie with what you propose: that the LN node should use a 
> different view-fullnode from the broadcast-fullnode.
>

The issue each time there are discussions/research linking to Tor is
that it is biased since the beginning because based on a wrong
postulate: using the Tor network

I will not elaborate on this again, it's an obvious very bad idea to use
the Tor network for bitcoin

It's not a bad idea to use the Tor protocol with no story of exit nodes
and hidden services, linking again to:
https://github.com/Ayms/node-Tor#phase-4-and-phase-5

And new link: http://www.peersm.com/Convergence-2020.pdf "A universal
and generic architecture to anonymize any application or protocol and
turn it into an independent decentralized p2p network inside browsers
and servers, with browsers acting as servers"

LN and bitcoin nodes would be relays and/or RDV points and/or clients
and serving parties, some Tor network nodes could be used in the middle
also (relays only) but in any case sybils/eclipse attacks become much
more difficult to perform (or unlikely depending on how the peer
discovery system is designed)

bitcoin | node-Tor |bitcoin and LN.pipe(node-Tor)

Then question for possible future tests: is there a simple way to pipe
the bitcoin protocol via stdin/stdout? (the socks interface could be
used but we already saw that it did raise issues)

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

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


[bitcoin-dev] node-Tor - phases 4 and 5

2020-02-25 Thread Aymeric Vitte via bitcoin-dev
Please see the current status here:
https://github.com/Ayms/node-Tor#phases-and-funding

Quick reminder: this is a javascript implementation of the Tor protocol
inside nodes and browsers

Phase 4 (evented pipes) has been developped (self funded) but is not
fully tested/released, however the doc is here:
https://github.com/Ayms/node-Tor/blob/master/docs/README.md, it allows
to simply anonymize any protocol piping it to the Tor protocol

We were about to implement phase 5 (elliptic crypto, Tor v3 features and
WebRTC) but are running out of funding, while we have self funded the
vast majority of this project since 2012 we can't continue (thanks to
NLnet for supporting phases 1 to 3) and are looking for funding to
complete this work (cf above link)

The timing is supposed to be now because restarting such a project in
months or years is not trivial and despite of the huge efforts for the
refactoring/update/cleaning of the initial code and split into modules
it's probably still difficult to use/integrate/modify (see
https://github.com/Ayms/node-Tor/issues/14), it will become quite easy
if the project goes to its targeted phase

The code is subtle and minimal, it represents only 1MB browserified not
minified, so 500kB minified, which is quite small for what it does with
zero external dependencies, redevelopping everything from scratch would
be long and difficult

Some examples of what node-Tor does (as nodes or inside browsers using
WebSockets/WebRTC/XHR):

http.pipe(parser).pipe(gzip).pipe(tls).pipe(node-Tor)

ipfs.pipe(node-Tor)

webtorrent.pipe(node-Tor)

bitcoin | node-Tor | bitcoin (via stdin/stdout or using IPC)

Of course the Tor protocol itself might not be enough and each project
might have to design the full anonymization system (peer discovery,
introduction, etc) but they can rely on node-Tor to implement the Tor
protocol (not to be misunderstood again with the Tor network)

It does implement direct p2p via the Tor protocol or via RendezVous
(RDV) points using also Tor protocol hops to connect to them, the peers
advertise what they have or do using a hash to the RDV points they are
connected to, please see
https://github.com/Ayms/node-Tor#phase-4-and-phase-5

Example: by convention a bitcoin node could advertise a hash of "Satoshi
Nakamoto" to tell it is a bitcoin node, then bitcoin nodes will connect
to each others via RDV points or several Tor protocol hops requesting
this hash, they can also connect directly via several hops for well
known bitcoin nodes that don't need to hide themselves but want to hide
to whom they are connected to, which can be wallets too, for example to
hide who originated a transaction

Since peers are implementing both direct p2p and RDV functions (both via
Tor protocol hops), and can extend to other peers as peers or RDV points
again, it becomes difficult to understand who is doing what and how many
hops finally are used between the peers (suggested setting for p2p is 2
hops instead of 3 for a Tor protocol circuit, knowing that the number of
hops can extend via RDV points)

This is the current design and can of course be adapted

It would look logical that this techno is integrated natively one day
inside browsers, again it must not be misunderstood with what the Tor
Browser is doing (with many specific features inside the browser itself)
and is not a replacement for it, this is different but could be used
also by the Tor network with browsers acting as real Tor nodes (a bit à
la Snowflake but not only relaying messages via WebRTC, implementing the
Tor protocol inside browsers), or uproxy-like for those that remember it

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

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


Re: [bitcoin-dev] v3 onion services

2019-11-18 Thread Aymeric Vitte via bitcoin-dev
So I must ask the question: what is the rational for a bitcoin node to
be hidden? ie to use RDV points like hidden services?

For me the rational for bitcoin is to anonymize communications between
nodes and/or clients, typically who sent this tx, not to hide that you
are operating a bitcoin node, then back to what I sent earlier

I tried to find the explaination in the bitcoin docs before sending this
post but did not find any, except referring to the fact that bitcoin
communications should be anonymized, which does not need RDV points

Another question is why to mimic the Tor network for RDV points with
.onion addresses?

The answers might be "this is what exists and we have no other way to do
it", I am proposing another way

I will not repeat what I wrote before, but I am operating node-Tor nodes
inside the Tor network since ~10 years, the js implementation of the Tor
protocol had not been easy (as well as putting everything inside
browsers) but I consider that the most difficult had been to handle all
unexpected events that happen inside the Tor network, even after
selecting carefully the nodes and testing them, this is a mess, nodes
are coming in, going out, responding, not responding, responding
correcltly or all of a sudden responding shxtty stuff, I was even
considering to get the entropy for the js prng from all of those
unexpected events

I don't think that any other people except the Tor project team know
this, a good example is http://peersm.com/peersm2, see the logs (destroy
and destroy and destroy) and how long it takes to establish 6 circuits
knowing that our server is the first one in the path (eliminating one
dubious node among 3)

I am not "promoting" this, everything is open source now and it is made
to be used, and I think that my proposal has some interest, using the
Tor network for bitcoin is a very bad idea, for security and
performances reasons

Le 18/11/2019 à 17:44, Carl Dong via bitcoin-dev a écrit :
> Hi Mr. Lee Chiffre,
>
> I have been working on an implementation of addrv2 (BIP-155). Is this what 
> you meant by I2P and Torv3 address support?
>
> My WIP pull request: https://github.com/bitcoin/bitcoin/pull/16748
> Merged BIP: https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
> Ongoing discussion: https://github.com/bitcoin/bips/pull/766
> Note: Even though the pull request to the BIP repo is merged, we’re still 
> discussing some details in the pull request thread and will amend the BIP 
> once it seems like we’ve worked out all the kinks
>
> Review and further discussion is very much welcome! :-)
>
> Cheers,
> Carl Dong
> cont...@carldong.me
> "I fight for the users"
>
>> On Nov 16, 2019, at 11:33 PM, Mr. Lee Chiffre via bitcoin-dev 
>>  wrote:
>>
>>
>> Right now bitcoin client core supports use of tor hidden service. It
>> supports v2 hidden service. I am in progress of creating a new bitcoin
>> node which will use v3 hidden service instead of v2. I am looking at
>> bitcoin core and btcd to use. Do any of these or current node software
>> support the v3 onion addresses for the node address? What about I2P
>> addresses? If not what will it take to get it to support the longer
>> addresses that is used by i2p and tor v3?
>>
>>
>> --
>> lee.chif...@secmail.pro
>> PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] v3 onion services

2019-11-18 Thread Aymeric Vitte via bitcoin-dev
As I briefly sketched here before I think that a better long term
solution would be to link the bitcoin traffic with something like
node-Tor (https://github.com/Ayms/node-Tor)

Much more light (the whole code not minified is only ~1MB), not using
tons of libraries prone to security/maintenance issues, easy to
use/configure/maintain and you don't need the (heavy/complicate) onions
RDV concepts and addresses, which in addition is useless for bitcoin

As simple as a duplex stream *bitcoin.pipe(node-Tor)* inside servers or
browsers (difficult to imagine full nodes and the blocks inside browsers
but why not one day, so for light clients probably implementing part of
the bitcoin protocol like https://peersm.com/wallet, for now it's a
standalone offline webapp but of course it would be interesting to
connect it in a secure way to bitcoin nodes to retrieve info from the
utxo set and send txs for example since it's not obvious for users to
create their txs in its current form)

This would be a separate network using the Tor protocol over TCP,
WebSockets and WebRTC, making it possible also for browsers to relay the
traffic, probably the nodes discovery (to get the keys) could be linked
to the bitcoin peer discovery system (we just have to add the onion key
to the peer profile, and maybe long term id key), anyway that's simple
to setup, and probably for a p2p network 2 hops will be enough

I really don't think that the Tor network is designed and adapted to
support bitcoin nodes, using it for something else than browsing is just
a workaround and I would be surprised that the Tor project team
contradicts this and/or encourage this use

Le 18/11/2019 à 00:42, Matt Corallo via bitcoin-dev a écrit :
> There is effort ongoing to upgrade the Bitcoin P2P protocol to support other 
> address types, including onion v3. There are various posts on this ML under 
> the title “addrv2”. Further review and contributions to that effort is, as 
> always, welcome.
>
>> On Nov 17, 2019, at 00:05, Mr. Lee Chiffre via bitcoin-dev 
>>  wrote:
>>
>> Right now bitcoin client core supports use of tor hidden service. It
>> supports v2 hidden service. I am in progress of creating a new bitcoin
>> node which will use v3 hidden service instead of v2. I am looking at
>> bitcoin core and btcd to use. Do any of these or current node software
>> support the v3 onion addresses for the node address? What about I2P
>> addresses? If not what will it take to get it to support the longer
>> addresses that is used by i2p and tor v3?
>>
>>
>> -- 
>> lee.chif...@secmail.pro
>> PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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


Re: [bitcoin-dev] CVE-2017-18350 disclosure

2019-11-09 Thread Aymeric Vitte via bitcoin-dev
Do not find excuses (and vague statements or technical bulls) and learn,
you don't know what you are talking about and don't get the global
picture, we don't care about the Tor network and they don't care about
others neither do they care that they increase their network, so indeed
let's stop this discussion


Just replying here (for the last time) because expecting more clever
thoughts about what I wrote, maybe one day... but for sure something
like this will happen in the future


Le 09/11/2019 à 21:21, LORD HIS EXCELLENCY JAMES HRMH a écrit :
> We do not need to discuss this back and forward publickly. I am not
> concerned whether Tors seems or is much centralised or not, it is not
> the concern of m statements, and it required directory nodes of which
> there are several and we could discuss the operation of its nodes and
> infrastructure all day, even comparing directory nodes to seed nodes.
> The fact is that browsing is the most common publicly understood usage
> of Tor but like with and without Tor the internet provides many services.
>
> It seems you have misunderstood the reason I reference making so many
> Tor nodes also but do not concern I will no reiterate. Also, whether
> Tor can provide for the bandwidth and connectivity required for
> Bitcoin you have not tested and provide only your opinion, where it
> seems that actually it can. The matter is that Tor carries Bitcoin
> traffic quite easily now and in fact as there is more Bitcoin traffic
> likely the Tor capacity increases in some proportion.
>
> Also, socks proxy is not a door in, it is a door out, do you realise
> but just works at a different network layer to HTTP proxy which works
> at layer 7 of the OSI model and Socks a bit lower?
>
> I have had some communication difficulty before where the native
> language is not English and although the communication happens in
> native English the though is still being formed in another language
> and so the presentation of the thought is not clear to the English
> presentation. Even if not this I do not consider wrong just that we
> write to consider not the same thing.
>
> Good day.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> 
> *From:* Aymeric Vitte 
> *Sent:* Sunday, 10 November 2019 6:33 AM
> *To:* LORD HIS EXCELLENCY JAMES HRMH ; Bitcoin
> Protocol Discussion ; Luke
> Dashjr 
> *Cc:* secur...@bitcoincore.org 
> *Subject:* Re: [bitcoin-dev] CVE-2017-18350 disclosure
>  
>
> ???
>
>
> Well, you obviously don't know what you are talking about and did not
> even consider reading correctly what I wrote, neither to read node-Tor
>
>
> What you are saying here is quite trivial, typical of people thinking
> that the Tor network will solve everything and is not centralized (but
> you seem unsure about it), that's not the case, it's completely wrong
> and the "normal" use of the Tor network is for browsing only,
> basically the Tor network is still the same since years: 1000 guards,
> 1000 relays, 1000 exits (so not "hundreds", happier, and there are of
> course intersections between them, knowing that they are the supposed
> working nodes as tested by node-Tor), quite small at the end with
> finally many misbehaving nodes among the 3000 set, not at all able or
> willing to handle bitcoin nodes load
>
>
> Using bitcoin with the Tor network is absurd, using socks proxy with
> bitcoin is absurd too (I don't get the comparison with a http proxy,
> nothing to do),  except if limited to a local use, ie you socks proxy
> inside your device, for example to pipe to node-Tor, but this remains
> as a whole dangerous if the local proxy has been hacked, as we could
> see recently with malware Tor sw being used by people
>
>
> Using the Tor protocol for bitcoin is not absurd at all (do you
> understand the difference?) + browsers, webRTC, etc I will not repeat
> what I wrote
>
>
> Please do some readings or consider at least what I sent, or ask
> questions if what I am saying is unclear for you
>
>
> But from my standpoint the discussion on this list is not about
> explaining all of this that is probably well known by everybody but
> what can/could be next to anonymize/help anonymizing bitcoin
>
>  when required and make it a real p2p network
>
>
> Unfortunately I am afraid that we get moderated here because that's
> not the place to give basic lessons about Tor that you don't know
>
>
> Le 09/11/2019 à 12:42, LORD HIS EXCELLENCY JAMES HRMH a écrit :
>> Socks proxies have their use in controlled gateway infrastructure and
>> is a relevant feature for any software required to operate behind a
>> secure network boundary and allows for UDP connectivity (whether it
>> is utilised in any particular application) which a HTTP proxy does not.
>>
>> You are obviously not well abreast of the Tor project, regardless of
>> whether it seems centralised, whether it is or it isn't, the Tor
>> project is to allow anonymity and connection privacy. 

Re: [bitcoin-dev] CVE-2017-18350 disclosure

2019-11-09 Thread Aymeric Vitte via bitcoin-dev
???


Well, you obviously don't know what you are talking about and did not
even consider reading correctly what I wrote, neither to read node-Tor


What you are saying here is quite trivial, typical of people thinking
that the Tor network will solve everything and is not centralized (but
you seem unsure about it), that's not the case, it's completely wrong
and the "normal" use of the Tor network is for browsing only, basically
the Tor network is still the same since years: 1000 guards, 1000 relays,
1000 exits (so not "hundreds", happier, and there are of course
intersections between them, knowing that they are the supposed working
nodes as tested by node-Tor), quite small at the end with finally many
misbehaving nodes among the 3000 set, not at all able or willing to
handle bitcoin nodes load


Using bitcoin with the Tor network is absurd, using socks proxy with
bitcoin is absurd too (I don't get the comparison with a http proxy,
nothing to do),  except if limited to a local use, ie you socks proxy
inside your device, for example to pipe to node-Tor, but this remains as
a whole dangerous if the local proxy has been hacked, as we could see
recently with malware Tor sw being used by people


Using the Tor protocol for bitcoin is not absurd at all (do you
understand the difference?) + browsers, webRTC, etc I will not repeat
what I wrote


Please do some readings or consider at least what I sent, or ask
questions if what I am saying is unclear for you


But from my standpoint the discussion on this list is not about
explaining all of this that is probably well known by everybody but what
can/could be next to anonymize/help anonymizing bitcoin

 when required and make it a real p2p network


Unfortunately I am afraid that we get moderated here because that's not
the place to give basic lessons about Tor that you don't know


Le 09/11/2019 à 12:42, LORD HIS EXCELLENCY JAMES HRMH a écrit :
> Socks proxies have their use in controlled gateway infrastructure and
> is a relevant feature for any software required to operate behind a
> secure network boundary and allows for UDP connectivity (whether it is
> utilised in any particular application) which a HTTP proxy does not.
>
> You are obviously not well abreast of the Tor project, regardless of
> whether it seems centralised, whether it is or it isn't, the Tor
> project is to allow anonymity and connection privacy. For this it
> works very well and there seem to be hundreds of known Tor nodes, to
> be known they are not isolated and are connected.
>
> Even if an exit node performs all logging it is only aware of the node
> one hop up but the originator is higher still. In the case where we
> perform a Tor cluster and make hundreds of guard, middle and exit
> nodes we still cannot with absolute certainty say that the connecting
> node is the originator and, the eventual Bitcoin node is still unaware
> of the originator IP which is the primary objective. Otherwise, can
> you hide your IP from your ISP would be a better goal?
>
> You may prefer to familiarise yourself first with the history of Tor,
> even a brief from [WikipediaTor_(anonymity_network)
> ](https://en.wikipedia.org/wiki/Tor_(anonymity_network))
> and consider some of the possible uses, and consider how its
> implementation benefits the privacy and anonymity of Bitcoin in public
> where it is allowed in many countries; Tor is just as useful in
> countries where Bitcoin is allowed to hide from third-parties. You may
> also enjoy an example of activating Bitcoin Cores Tor implementation:
> [How can I setup Bitcoin to be anonymous with
> Tor?](https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070)
> 
>   
> Tor (anonymity network) - Wikipedia
> 
> Tor is free and open-source software for enabling anonymous
> communication.The name is derived from an acronym for the original
> software project name "The Onion Router". Tor directs Internet traffic
> through a free, worldwide, volunteer overlay network consisting of
> more than seven thousand relays to conceal a user's location and usage
> from anyone conducting network surveillance or traffic analysis.
> en.wikipedia.org
>
>
> 
>   
> bitcoind - How can I setup Bitcoin to be anonymous with Tor? - Bitcoin
> Stack Exchange
> 
> Bitcoin is billed as many things, among them its anonymity is highly
> regarded. While it is true that a transaction does not identify a user
> or wallet, recent news shows that there is the potential ...
> bitcoin.stackexchange.com
>
>
>
> There should be no rational consideration that 

Re: [bitcoin-dev] CVE-2017-18350 disclosure

2019-11-08 Thread Aymeric Vitte via bitcoin-dev
Sure, but what is questionable here is the use of SOCKS proxy, for Tor I
think as the main purpose, making it dangerous for the "whole bitcoin
world" while it's something like of zero interest/use (or please let me
know what it is beside Tor)

The Tor network is very centralized and not designed at all to handle
p2p networks (which bitcoin is still not), it is designed to be used via
the Tor Browser to browse the web and to hide web servers, not bitcoin
nodes, and there are a lot of misbehaving/dangerous nodes there, there
is no encryption in bitcoin protocol, an exit node can fake whatever it
likes, this seems to be a use case as far as I can see, but even if the
initiator is configured to connect to a hidden bitcoin node, I don't see
the point

I have advertised recentlty the open sourcing of node-Tor
(https://github.com/Ayms/node-Tor) here

This one is designed for p2p, not over the Tor network but using the Tor
protocol, as simple as bitcoin.pipe(node-Tor), or .pipe(node-Tor), which is the finality of the project as far as
I see it since years (maybe see http://www.peersm.com/Convergence.pdf
even if I would modify some parts now)

Inside servers or browsers acting as servers also (WebRTC or
WebSockets), bitcoin peers (servers/browsers) relaying the bitcoin
anonymized protocol using the Tor protocol (and not the Tor network)
between each others, there is no story of exit nodes here and rdv points
would not apply for bitcoin use, this "just" adds the internal missing
encryption and anonymity layer to the bitcoin protocol

Personally I would remove the socks proxy interface from bitcoin core,
independently of Tor this can be misused too and offers absolutely zero
security


Le 08/11/2019 à 18:03, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev a
écrit :
> It goes without saying in that all privately known CVE should be
> handled so professionally but, that is, well done team.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> 
> *From:* bitcoin-dev-boun...@lists.linuxfoundation.org
>  on behalf of Luke
> Dashjr via bitcoin-dev 
> *Sent:* Saturday, 9 November 2019 2:07 AM
> *To:* bitcoin-dev@lists.linuxfoundation.org
> 
> *Cc:* secur...@bitcoincore.org 
> *Subject:* [bitcoin-dev] CVE-2017-18350 disclosure
>  
> CVE-2017-18350 is a buffer overflow vulnerability which allows a
> malicious
> SOCKS proxy server to overwrite the program stack on systems with a
> signed
> `char` type (including common 32-bit and 64-bit x86 PCs).
>
> The vulnerability was introduced in
> 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5
> (SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012
> Aug 27.
> A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372 ("Improve
> and
> document SOCKS code") released in v0.15.1, 2017 Nov 6.
>
> To be vulnerable, the node must be configured to use such a malicious
> proxy in
> the first place. Note that using *any* proxy over an insecure network
> (such
> as the Internet) is potentially a vulnerability since the connection
> could be
> intercepted for such a purpose.
>
> Upon a connection request from the node, the malicious proxy would
> respond
> with an acknowledgement of a different target domain name than the one
> requested. Normally this acknowledgement is entirely ignored, but if the
> length uses the high bit (ie, a length 128-255 inclusive), it will be
> interpreted by vulnerable versions as a negative number instead. When the
> negative number is passed to the recv() system call to read the domain
> name,
> it is converted back to an unsigned/positive number, but at a much
> wider size
> (typically 32-bit), resulting in an effectively infinite read into and
> beyond
> the 256-byte dummy stack buffer.
>
> To fix this vulnerability, the dummy buffer was changed to an explicitly
> unsigned data type, avoiding the conversion to/from a negative number.
>
> Credit goes to practicalswift (https://twitter.com/practicalswift) for
> discovering and providing the initial fix for the vulnerability, and
> Wladimir
> J. van der Laan for a disguised version of the fix as well as general
> cleanup
> to the at-risk code.
>
> Timeline:
> - 2012-04-01: Vulnerability introduced in PR #1141.
> - 2012-05-08: Vulnerability merged to master git repository.
> - 2012-08-27: Vulnerability published in v0.7.0rc1.
> - 2012-09-17: Vulnerability released in v0.7.0.
> ...
> - 2017-09-21: practicalswift discloses vulnerability to security team.
> - 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability.
> - 2017-09-27: Fix merged to master git repository.
> - 2017-10-18: Fix merged to 0.15 git repository.
> - 2017-11-04: Fix published in v0.15.1rc1.
> - 2017-11-09: Fix released in v0.15.1.
> ...
> - 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
> - 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.
> ___
> bitcoin-dev mailing list
> 

[bitcoin-dev] Fwd: node-Tor is now open source in clear (and modular)

2019-10-28 Thread Aymeric Vitte via bitcoin-dev
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

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


[bitcoin-dev] Fwd: Discover and move your coins by yourself

2019-08-07 Thread Aymeric Vitte via bitcoin-dev
FYI Phase 3 is released https://github.com/Ayms/bitcoin-transactions,
features:

- create transactions

- decode transactions

- verify transactions

- convert/map addresses (including bech32)

- create/map wallets (bip32,39,44, etc), wallets recovery (missing/wrong
words) and check

- decode/create multisig redeem scripts

- pubkey/privkey mapping , conversion and formats

- sign/verify messages

Browserifying everything now for the end of the month



 Message transféré 
Sujet : Discover and move your coins by yourself
Date :  Fri, 12 Jul 2019 20:35:00 +0200
De :Aymeric Vitte 
Pour :  Bitcoin Dev 




Please see https://github.com/Ayms/bitcoin-transactions this is a merge
of former bitcoin-transactions and bitcoin-wallets nodejs modules with
additional features to be implemented as described in the README

It is financed by NLnet via EU Horizon 2020 Next Generation Internet
Search and Discovery call

So the initial dev fees have been removed and the code is now open
source and provided in clear under a MIT license

The intent is to provide all the necessary tools for anybody to discover
and manage their coins, as well as making transactions by themselves,
without having to sync a full node or as an alternative to wallets when
people don't understand where their coins are (we saw quite a lot of
confusion for people not understanding at all how to find their coins
and to what keys their addresses did relate in case of multisig, segwit
and now bech32)

It's somewhere bitcoin-cli outside of bitcoin core more easy to use and
not restricted to its own wallet, available for any bitcoin based coins

At the end it will be a secure standalone offline js webapp inside
browsers (like https://peersm.com/wallet but the app does not reflect
the current state of the nodejs repo)

It's not a remake of iancoleman's tool but of course some features
overlap, as well as for other existing tools, we will also extend all of
this inside one tool with no limitations (for example some tools do not
accept "invalid" bip39 seeds, or bip32 seeds, etc)

Comments/suggestions welcome

PS: initially sent to bitcoin-discuss but the list seems to be dead

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

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


[bitcoin-dev] Discover and move your coins by yourself

2019-07-16 Thread Aymeric Vitte via bitcoin-dev


Please see https://github.com/Ayms/bitcoin-transactions this is a merge
of former bitcoin-transactions and bitcoin-wallets nodejs modules with
additional features to be implemented as described in the README

It is financed by NLnet via EU Horizon 2020 Next Generation Internet
Search and Discovery call

So the initial dev fees have been removed and the code is now open
source and provided in clear under a MIT license

The intent is to provide all the necessary tools for anybody to discover
and manage their coins, as well as making transactions by themselves,
without having to sync a full node or as an alternative to wallets when
people don't understand where their coins are (we saw quite a lot of
confusion for people not understanding at all how to find their coins
and to what keys their addresses did relate in case of multisig, segwit
and now bech32)

It's somewhere bitcoin-cli outside of bitcoin core more easy to use and
not restricted to its own wallet, available for any bitcoin based coins

At the end it will be a secure standalone offline js webapp inside
browsers (like https://peersm.com/wallet but the app does not reflect
the current state of the nodejs repo)

It's not a remake of iancoleman's tool but of course some features
overlap, as well as for other existing tools, we will also extend all of
this inside one tool with no limitations (for example some tools do not
accept "invalid" bip39 seeds, or bip32 seeds, etc)

Comments/suggestions welcome

PS: initially sent to bitcoin-discuss but the list seems to be dead

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

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


Re: [bitcoin-dev] Two questions about segwit implementation

2019-05-27 Thread Aymeric Vitte via bitcoin-dev
Well, OK, then back to non standard stuff and bitcoin considers that an
OP_1 or empty scriptpubkey is something that can exist, sipa does not
like my questions on this list but this is a bit frightening in fact to
see that after 10 years an OP_1 scriptpubkey or empty one can be a use
case, thanks Thomas also, where all of this is clearly documented so
people don't bother the list not to produce approximative stuff remains
mysterious

Le 26/05/2019 à 19:24, Johnson Lau a écrit :
> Empty scriptSig doesn’t imply segwit input: if the previous scriptPubKey is 
> OP_1 (which does not allow witness), it could still be spent with an empty 
> scriptSig
>
> Similarly, a scriptSig looking like a spend of P2SH-segwit doesn’t imply 
> segwit input: if the previous scriptPubKey is empty, it could be spent with a 
> push of any non-zero value.
>
>> On 27 May 2019, at 1:09 AM, Aymeric Vitte  wrote:
>>
>> I did not phrase correctly in fact, what I meant is: if the validator
>> sees empty or witness script in scriptSig, then this is a segwit input,
>> and doing this one by one the validator can associate the correct segwit
>> data to the correct segwit input, so 00 does not look to be needed
>>
>> Le 26/05/2019 à 18:28, Johnson Lau a écrit :
>>> This is not how it works. While the transaction creator may know which 
>>> inputs are segwit, the validators have no way to tell until they look up 
>>> the UTXO set.
>>>
>>> In a transaction, all information about an input the validators have is the 
>>> 36-byte outpoint (txid + index). Just by looking at the outpoint, there is 
>>> no way to tell whether it is segwit-enabled or not. So there needs to be a 
>>> way to tell the validator that “the witness for this input is empty”, and 
>>> it is the “00”.
>>>
 On 27 May 2019, at 12:18 AM, Aymeric Vitte  wrote:

 ……. for the 00 number of witness
 data for non segwit inputs the one that is doing the transaction knows
 which inputs are segwit or not, then parsing the transaction you can
 associate the correct input to the correct witness data, without the
 need of 00, so I must be missing the use case
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Two questions about segwit implementation

2019-05-27 Thread Aymeric Vitte via bitcoin-dev
I did not phrase correctly in fact, what I meant is: if the validator
sees empty or witness script in scriptSig, then this is a segwit input,
and doing this one by one the validator can associate the correct segwit
data to the correct segwit input, so 00 does not look to be needed

Le 26/05/2019 à 18:28, Johnson Lau a écrit :
> This is not how it works. While the transaction creator may know which inputs 
> are segwit, the validators have no way to tell until they look up the UTXO 
> set.
>
> In a transaction, all information about an input the validators have is the 
> 36-byte outpoint (txid + index). Just by looking at the outpoint, there is no 
> way to tell whether it is segwit-enabled or not. So there needs to be a way 
> to tell the validator that “the witness for this input is empty”, and it is 
> the “00”.
>
>> On 27 May 2019, at 12:18 AM, Aymeric Vitte  wrote:
>>
>> ……. for the 00 number of witness
>> data for non segwit inputs the one that is doing the transaction knows
>> which inputs are segwit or not, then parsing the transaction you can
>> associate the correct input to the correct witness data, without the
>> need of 00, so I must be missing the use case
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Two questions about segwit implementation

2019-05-27 Thread Aymeric Vitte via bitcoin-dev
OK, thanks, understood for OP_0 but still for the 00 number of witness
data for non segwit inputs the one that is doing the transaction knows
which inputs are segwit or not, then parsing the transaction you can
associate the correct input to the correct witness data, without the
need of 00, so I must be missing the use case

Le 26/05/2019 à 16:33, Johnson Lau a écrit :
>> On 26 May 2019, at 7:56 AM, Aymeric Vitte via bitcoin-dev 
>>  wrote:
>>
>> I realized recently that my segwit implementation was not correct,
>> basically some time ago, wrongly reading the specs (and misleaded by
>> what follows), I thought that scriptsig would go into witness data as it
>> was, but that's not the case, op_pushdata is replaced by varlen
>>
> Witness is not script. There is no op_pushdata or any other opcodes.
>
> Witness is a stack. For each input, the witness starts with a CCompactSize 
> for the number of stack elements for this input. Each stack element in turns 
> starts with a CCompactSize for the size of this element, followed by the 
> actual data
>
>
>> Now reading correctly the specs, they seem to be not totally correct,
>> then the first question is: why OP_0 is 00 in witness data and not 0100?
>> Does this apply to other op_codes? This does not look logical at all
>>
> A “00” element means the size of this element is zero. Since it’s zero size, 
> no data is followed. This will create an empty element on the stack. It’s 
> effectively same as OP_0 (Again, witness is not script)
>
> A “0100” element means the element size is one, and the data for this element 
> is “00”. So it will leave an 1-byte element on the stack.
>
>
>> The second question is: why for non segwit inputs there is a 00 length
>> in segwit data, what is the rational for that? It should just be nothing
>> since you don't need this to reconciliate things
> The “00” here means "this input has no witness stack element”. You need this 
> even for non segwit inputs, because there is no way to tell whether an input 
> is segwit-enabled or not, until you look up the UTXO, which might not be 
> always available. Transaction serialization couldn’t rely on contextual 
> information.
>
> However, if all inputs have no stack element, the spec requires you to always 
> use the non-segwit serialization.
>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-- 
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

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


[bitcoin-dev] Two questions about segwit implementation

2019-05-26 Thread Aymeric Vitte via bitcoin-dev
I realized recently that my segwit implementation was not correct,
basically some time ago, wrongly reading the specs (and misleaded by
what follows), I thought that scriptsig would go into witness data as it
was, but that's not the case, op_pushdata is replaced by varlen

Now reading correctly the specs, they seem to be not totally correct,
then the first question is: why OP_0 is 00 in witness data and not 0100?
Does this apply to other op_codes? This does not look logical at all

The second question is: why for non segwit inputs there is a 00 length
in segwit data, what is the rational for that? It should just be nothing
since you don't need this to reconciliate things

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


Re: [bitcoin-dev] IsStandard

2019-05-03 Thread Aymeric Vitte via bitcoin-dev
Great doc, thanks, then my previous summarized conclusion was wrong,
trying on my side to write a "demistifying (simply) once for all bitcoin
scripting", not sure that "simply" can stay in the title at the end...

So my multisig modification is non standard, now I am still puzzled by
something, mainly the fact that we have op_pushdata inside op_pushdata,
maybe I am misreading the specs, but in case of p2sh only the last
op_pushdata (called {serialized script} (or redeem script) is executed,
then if succesfull it comes back onto the stack and scriptpubkey is executed

So, let's take again the BCH recovery example, scriptSig was OP_PUSHDATA
0014, and scriptPubKey OP_HASH160  OP_EQUAL, then scriptSig executes pushing
nothing and  into the stack, then scriptSig is pushed
again and executed with scriptPubKey, at the end we get nothing +
 + 1 in the stack, then cleanstack (maybe among
others, I have to read in more details your doc) says it is a correct
transaction but non standard, is this correct?

Le 03/05/2019 à 01:33, James Prestwich a écrit :
> Hi Aymeric, 
>
> As Luke and ZmnSCPxj have pointed out, documenting standardness is
> sisyphean, as it varies from version to version. I recently put
> together a reference for default TX_NONSTANDARD policies in v0.18,
> which can be found here: https://prestwi.ch/the-bitcoin-nonstandard/ 
>
> It applies only to v0.18, and may already be outdated.
>
> Best,
> James
>
> On Thu, May 2, 2019 at 4:29 PM Aymeric Vitte via bitcoin-dev
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> Thanks for the answer, indeed for the redeem script and someone
> attempting a 0/1 of 3, good example
>
> So to summarize everything is standard as long as it matches P2PKH,
> P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in
> op_return
>
> Still the case of bch is unclear (it's related since based on bitcoin
> code unless they changed the policy), was the story that nodes
> would not
> propagate the fix or that people did not want to take the risk to
> propagate it? And why a non segwit old bitcoin node would not
> accept it
> either?
>
> Le 02/05/2019 à 02:10, ZmnSCPxj a écrit :
> > Good morning Aymeric,
> >
> >
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte
> mailto:vitteayme...@gmail.com>> wrote:
> >
> >> I must badly explain my point (or just wondering things that do not
> >> exist finally), the question is indeed whether nodes will relay non
> >> usual transactions or not and how to know what they will accept
> or not:
> >>
> >> -   my modified multisig 2 of 3: I did put OP_2 out of the
> usual redeem
> >>     script, the redeem script still matches scriptpubkey and
> scriptsig will
> >>     execute succesfully, that's a normal legacy P2SH or segwit
> P2WSH
> >>
> >> -   bch segwit recovery: it's a p2sh transaction without any
> signature
> >>     verification, as far as I remember there was a story that
> it could not
> >>     propagate in the network (even taking the risk to be
> stolen) and that
> >>     people had to contact a (honest) miner
> >>
> >> -   sha bounties: same as above, p2sh transactions without
> signatures
> >>
> >>     etc
> >>
> >>     Will all of those transactions propagate normally? And then
> the rule is
> >>     just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH
> templates
> >>     whatever scripts you put inside?
> > P2PKH and P2WPKH cannot have custom script.
> > However, yes, any custom script can be wrapped in P2SH and P2WSH
> and it will be propagated.
> > The P2SH/P2WSH hides the details of your custom script so cannot
> be filtered based on your custom script.
> > Do realize that once a claim on your modified x-of-3 is
> propagated your `redeemScript` is known and someone can attempt to
> RBF (or coordinate with a miner) with a modified `witness` stack
> or `scriptSig` to claim your UTXO.
> > (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at
> least one of your signatories could make it a 1-of-3 and bribe a
> miner to get it claimed)
> >
> > I cannot answer for BCH; arguably that is off-topic here.
> >
> > The old SHA bounty transactions were propagated in the days
> before `isStandard`

Re: [bitcoin-dev] IsStandard

2019-05-02 Thread Aymeric Vitte via bitcoin-dev
Thanks for the answer, indeed for the redeem script and someone
attempting a 0/1 of 3, good example

So to summarize everything is standard as long as it matches P2PKH,
P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in
op_return

Still the case of bch is unclear (it's related since based on bitcoin
code unless they changed the policy), was the story that nodes would not
propagate the fix or that people did not want to take the risk to
propagate it? And why a non segwit old bitcoin node would not accept it
either?

Le 02/05/2019 à 02:10, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte  
> wrote:
>
>> I must badly explain my point (or just wondering things that do not
>> exist finally), the question is indeed whether nodes will relay non
>> usual transactions or not and how to know what they will accept or not:
>>
>> -   my modified multisig 2 of 3: I did put OP_2 out of the usual redeem
>> script, the redeem script still matches scriptpubkey and scriptsig will
>> execute succesfully, that's a normal legacy P2SH or segwit P2WSH
>>
>> -   bch segwit recovery: it's a p2sh transaction without any signature
>> verification, as far as I remember there was a story that it could not
>> propagate in the network (even taking the risk to be stolen) and that
>> people had to contact a (honest) miner
>>
>> -   sha bounties: same as above, p2sh transactions without signatures
>>
>> etc
>>
>> Will all of those transactions propagate normally? And then the rule is
>> just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates
>> whatever scripts you put inside?
> P2PKH and P2WPKH cannot have custom script.
> However, yes, any custom script can be wrapped in P2SH and P2WSH and it will 
> be propagated.
> The P2SH/P2WSH hides the details of your custom script so cannot be filtered 
> based on your custom script.
> Do realize that once a claim on your modified x-of-3 is propagated your 
> `redeemScript` is known and someone can attempt to RBF (or coordinate with a 
> miner) with a modified `witness` stack or `scriptSig` to claim your UTXO.
> (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at least one of your 
> signatories could make it a 1-of-3 and bribe a miner to get it claimed)
>
> I cannot answer for BCH; arguably that is off-topic here.
>
> The old SHA bounty transactions were propagated in the days before 
> `isStandard` I think.
> Either that or they were put in by miners.
> An SHA bounty can still be propagated today if they are wrapped in a P2SH or 
> P2WSH, but you have to publish the `redeemScript` yourself in some other 
> method.
> Or bribe a miner if the transaction is not time-sensitive (for an SHA bounty, 
> unlikely to be time-sensitive).
>
> Regards,
> ZmnSCPxj

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

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


Re: [bitcoin-dev] IsStandard

2019-05-02 Thread Aymeric Vitte via bitcoin-dev
I must badly explain my point (or just wondering things that do not
exist finally), the question is indeed whether nodes will relay non
usual transactions or not and how to know what they will accept or not:

- my modified multisig 2 of 3: I did put OP_2 out of the usual redeem
script, the redeem script still matches scriptpubkey and scriptsig will
execute succesfully, that's a normal legacy P2SH or segwit P2WSH

- bch segwit recovery: it's a p2sh transaction without any signature
verification, as far as I remember there was a story that it could not
propagate in the network (even taking the risk to be stolen) and that
people had to contact a (honest) miner

- sha bounties: same as above, p2sh transactions without signatures

etc

Will all of those transactions propagate normally? And then the rule is
just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates
whatever scripts you put inside?

Le 30/04/2019 à 06:29, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, April 29, 2019 5:30 PM, Aymeric Vitte  
> wrote:
>
>> ZmnSCPxj, OK, but you can put whatever you like in the different
>> standard output script you mention (my example below whether legacy or
>> segwit)
>>
> I am uncertain what you mean by this.
>
> For P2PKH and P2WPKH, you must present a hash of a public key.
> You cannot present a hash of anything else.
>
> The P2PKH template can be interpreted as a script, but is actually recognized 
> as a template by most current nodes (in a way that is consistent with 
> interpreting it as a script).
>
> For P2SH and P2WSH, you must present a hash of a script.
>
> It is more helpful to consider that *today* nodes recognize particular 
> patterns (P2PKH, P2WPKH, P2SH, P2WSH) as templates and not as scripts to be 
> executed.
>
> In any case, if you want to make anything more complicated than "single 
> signer" you should use P2SH or P2WSH regardless, and give your script.
> If you want to assure somebody that a particular P2SH or P2WSH commits to a 
> particular policy, just expose the policy script to them and have them (i.e. 
> their client software) verify that the policy is what the user wants and that 
> when hashed it matches the P2SH/P2WSH.
>
> As Luke said, nodes can have any policy for propagating transactions.
> However it is generally expected that P2PKH, P2WPKH, P2SH, and P2WSH will be 
> propagated by a majority of nodes, if only because those are reliably 
> "passed" by `isStandard` in the default latest Bitcoin Core and most people 
> will not modify the Core code.
>
> Generally, anything that isn't P2PKH, P2WPKH, P2SH, or P2WSH will not likely 
> be propagated by the network.
> You *could* still coordinate with one or more miners to get it mined: you can 
> put anything in the block, it is simply that most nodes will not inform 
> miners about transactions that do not pay out to P2PKH, P2WPKH, P2SH, or 
> P2WSH.
>
> Regards,
> ZmnSCPxj

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

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


Re: [bitcoin-dev] IsStandard

2019-05-02 Thread Aymeric Vitte via bitcoin-dev
ZmnSCPxj, OK, but you can put whatever you like in the different
standard output script you mention (my example below whether legacy or
segwit)

Luke, I am still confused or missing something, from your answer I
understand that everything is accepted, so if we take the past example
of bch coins wrongly sent to a segwit address, why was the recovery
solution where scriptsig included the matching segwit address/program
not a standard transaction?

Le 29/04/2019 à 05:01, Luke Dashjr a écrit :
> On Saturday 27 April 2019 10:37:29 Aymeric Vitte via bitcoin-dev wrote:
>> Maybe trivial question but asking here because I can't find anything
>> clear (or updated) about it: is somewhere explained in details what txs
>> are considered standard and non standard today without having to read
>> the core code?
>>
>> For example, modification of multisig 2 of 3:
>>
>> scriptSig:
>>     OP_0
>>     OP_PUSHDATA sign1
>>     OP_PUSHDATA sign2
>>     OP_2
>>     OP_PUSHDATA  OP_3 OP_CHECKMULTISIG
>>    
>> scriptPubKey:
>>     OP_HASH160 hash160( OP_3
>> OP_CHECKMULTISIG) OP_EQUAL
>>
>> Is this standard? Are lightning txs standards ? etc
> The name is confusing. It has little to do with standards, really.
> IsStandard is just one of the functions which implement the node's policy.
> It allows many things for which there is no standard (eg, data carrier / 
> OP_RETURN outputs), and can vary freely from node to node (either by 
> configurable parameters, or by different/modified software) without breaking 
> consensus.
>
> As it is a node-specific criteria, it is not itself even a possible *subject* 
> for standards.
>
> Additionally, it should not be given much (if any) attention when defining 
> new 
> standards. Just do what makes sense for the standard, and node policies can 
> be adapted around that.
>
> So, overall, there's limited use case for documenting this beyond the code.
> It makes far more sense to document actual standards instead.
>
> Luke

s

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


[bitcoin-dev] IsStandard

2019-04-28 Thread Aymeric Vitte via bitcoin-dev
Maybe trivial question but asking here because I can't find anything
clear (or updated) about it: is somewhere explained in details what txs
are considered standard and non standard today without having to read
the core code?

For example, modification of multisig 2 of 3:

scriptSig:
    OP_0
    OP_PUSHDATA sign1
    OP_PUSHDATA sign2
    OP_2
    OP_PUSHDATA  OP_3 OP_CHECKMULTISIG
   
scriptPubKey:
    OP_HASH160 hash160( OP_3
OP_CHECKMULTISIG) OP_EQUAL

Is this standard? Are lightning txs standards ? etc


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


Re: [bitcoin-dev] License for BIP39 word lists

2019-04-11 Thread Aymeric Vitte via bitcoin-dev
What is not final finally and when do you expect it to be?

Le 09/04/2019 à 11:49, Pavol Rusnak a écrit :
> We are in process of finalizing it, so it is not live in Trezor yet.
> It will be soon, though. I suppose every wallet that uses BIP39 will
> adopt this one as well.
>
> On Tue, Apr 9, 2019, 11:46 Aymeric Vitte  > wrote:
>
> Is it final now and live in Trezor? Do you know who else will
> adopt it?
>
> Regards
>
> Aymeric
>
> Le 03/04/2019 à 11:19, Pavol Rusnak via bitcoin-dev a écrit :
>> I am the author of the wordlist. Feel free to use it without any
>> restrictions.
>>
>> However, we are finalizing SLIP39 standard for splitting shares
>> which uses a different wordlist with better properties. It might
>> be more suitable for your project.
>>
>> See https://github.com/satoshilabs/slips/blob/master/slip-0039.md
>> and 
>> https://github.com/satoshilabs/slips/blob/master/slip-0039/wordlist.txt
>>
>>
>>
>> On Wed, Apr 3, 2019, 09:32 Elia via bitcoin-dev
>> > > wrote:
>>
>> I would like to use the BIP39 word lists posted in the Github
>> BIP repo
>> for my own project.
>>
>>
>> Unfortunately there is no license associated with the lists
>> provided on
>> Github so I am not sure whether usage for other projects is
>> permitted. I
>> am not able to file issues on the repo either to suggest
>> adding a license.
>>
>> Does anybody know under which license these lists are published?
>>
>>
>> Best regards,
>>
>> Elia
>>
>>
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org 
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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


Re: [bitcoin-dev] License for BIP39 word lists

2019-04-11 Thread Aymeric Vitte via bitcoin-dev
Is it final now and live in Trezor? Do you know who else will adopt it?

Regards

Aymeric

Le 03/04/2019 à 11:19, Pavol Rusnak via bitcoin-dev a écrit :
> I am the author of the wordlist. Feel free to use it without any
> restrictions.
>
> However, we are finalizing SLIP39 standard for splitting shares which
> uses a different wordlist with better properties. It might be more
> suitable for your project.
>
> See https://github.com/satoshilabs/slips/blob/master/slip-0039.md
> and https://github.com/satoshilabs/slips/blob/master/slip-0039/wordlist.txt
>
>
>
> On Wed, Apr 3, 2019, 09:32 Elia via bitcoin-dev
>  > wrote:
>
> I would like to use the BIP39 word lists posted in the Github BIP repo
> for my own project.
>
>
> Unfortunately there is no license associated with the lists
> provided on
> Github so I am not sure whether usage for other projects is
> permitted. I
> am not able to file issues on the repo either to suggest adding a
> license.
>
> Does anybody know under which license these lists are published?
>
>
> Best regards,
>
> Elia
>
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Smart Contracts Unchained

2019-04-08 Thread Aymeric Vitte via bitcoin-dev
Hi,

I took the example of colored coins because you quoted ethereum and like
most of ethereum tokens most of them reflect something coming from
nowhere, worse I can send you 10K Tethers if you like that of course
will not be validated by the central system but will be recorded in
bitcoin blockchain

Bitcoin oulasting ethereum, maybe, but the bitcoin community must make
more efforts to explain things, like "both were obvious" below is not in
fact for an usual reader, so a few more words would be good indeed

For me a sidechain does not have to be a blockchain but a decentralized
system allowing to secure off chain transactions until the final state
is stored into the blockchain, I don't see the use of storing forever
the intermediate states neither why the sidechain should be a
blockchain, if not then the sidechain would just be another
bitcoin/ethereum, no? What would be the purpose of building a blockchain
on top of another one? Just do your own, and this would eliminate the
drawback of needing to have bitcoins or ethers to smart contract things
that have nothing to do with them, as well as mixing addresses between
the blockchain and the sidechains

Regards

Aymeric

Le 08/04/2019 à 12:45, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>> Hi,
>>
>> Apparently you are not a fan of ethereum, as far as I can tell ethereum
>> sidechains look like a mess with stupid tokens/transactions flooding the
>> network while they are completely centralized, but some bitcoin
>> sidechains can easily compete with this too, like Tether, don't even
>> understand how anyone can give some credit to that stuff the way it is
>> implemented, and if bitcoin fails that would be the same as for ethereum
> I prefer to be more precise in my terminology.
> Colored coins are not the same as sidechains, and there are colored coins and 
> then there are colored coins.
> This mechanism does not propose some change in colored coins.
> An important aspect of colored coins is that one can foist them on somebody 
> else to extract things of real value from them, but this mechanism is more 
> strongly for a fixed set of participants.
>
> I strongly suspect that Bitcoin will outlast Ethereum, but that is rather not 
> very related to this topic.
>
>> Most likely everyone would agree if the escrow disappears, but not sure
>> at all, let's imagine 1 to N put 10K on the table for a game, they
>> update the states and at the end N wins everything, N is rich and don't
>> care finally if the others cheaters have their coins locked (and to lose
>> 10K), same with setting up a new escrow to resolve the conflict
>>
> Indeed.
> Still, the option to do so exists, and sometimes all that is needed for 
> humans to do the right thing, is to be given the option to do so.
>
>> I think that you should highlight this (and what private key corresponds
>> to E + h(E | s) * G, not sure it's trivial for everybody), probably a
>> way to get this more decentralized is to reward the escrows (what is the
>> interest here for people to run a smart contract platform?)
> I assumed both were obvious, but I suppose a few more words about those would 
> not be amiss.
>
>> For lightning, maybe it's a question of wording, I consider it as a
>> sidechain AND methods that can be used by other sidechains, as well as
>> the others you quoted, even if only two people in the world use
>> lightning, it is still decentralized, because it sustains itself alone
> Again, I prefer precision in my terminology.
> For me, a sidechain is a blockchain of some sort.
> In particular, a kind of Merklized singly-linked list containing 
> representations of transformations of state, is how I define blockchain to be.
>
> No such Merklized singly-linked list exists in Lightning Network, thus I do 
> not consider it, "blockchain".
> And thus I do not consider it "sidechain", as a sidechain is a blockchain.
> Current LN does use "shachains" by Rusty, but shachains are not Merklized 
> singly-linked lists, but are instead a kind of inverse mountain range 
> structure.
>
> Still, one might consider both federated sidechains and Lightning Network to 
> have a "federated" offchain structure.
> This is because the coins on the Bitcoin blockchain are locked to a 
> multisignature and activity is not recorded on the Bitcoin blockchain.
> However, in LN, each channel is a 2-member federation (you and a 
> counterparty) and the mechanism in LN requires consensus (2-of-2) rather than 
> a quorum (m-of-n).
> This greatly increases the security of LN: the owner of funding on an LN 
> channel can always refuse to sign an update if the other member of the 
> federation is taken over.
> Compare this to the quorum that typical federations have, where takeover of a 
> sufficient quorum is enough to steal funds from the remaining federation.
> https://zmnscpxj.github.io/offchain/safety.html
>
> Regards,
> ZmnSCPxj

___
bitcoin-dev mailing list

Re: [bitcoin-dev] Smart Contracts Unchained

2019-04-07 Thread Aymeric Vitte via bitcoin-dev

Hi,

Apparently you are not a fan of ethereum, as far as I can tell ethereum 
sidechains look like a mess with stupid tokens/transactions flooding the 
network while they are completely centralized, but some bitcoin 
sidechains can easily compete with this too, like Tether, don't even 
understand how anyone can give some credit to that stuff the way it is 
implemented, and if bitcoin fails that would be the same as for ethereum


Most likely everyone would agree if the escrow disappears, but not sure 
at all, let's imagine 1 to N put 10K on the table for a game, they 
update the states and at the end N wins everything, N is rich and don't 
care finally if the others cheaters have their coins locked (and to lose 
10K), same with setting up a new escrow to resolve the conflict


I think that you should highlight this (and what private key corresponds 
to E + h(E | s) * G, not sure it's trivial for everybody), probably a 
way to get this more decentralized is to reward the escrows (what is the 
interest here for people to run a smart contract platform?)


For lightning, maybe it's a question of wording, I consider it as a 
sidechain AND methods that can be used by other sidechains, as well as 
the others you quoted, even if only two people in the world use 
lightning, it is still decentralized, because it sustains itself alone


Regards

Aymeric

Le 05/04/2019 à 01:52, ZmnSCPxj a écrit :

Good morning Aymeric,



What if the smart contract platform(s) disappear?


It is still possible to recover the funds, *if* you can convince all participants of some 
"fair" distribution of the funds.
You do this by all participants simply signing with their participant keys and 
taking the first branch of the script.
This branch does not require the participation of the smart contract platform, 
at all.
If all participants can agree to the result of the smart contract without 
dispute, then they can exit the platform even after the platform disappears.

Now of course there will be participants who will not cooperate in such a case, for 
example if they were doing some betting game and "lost".
But at least it gives the possibility of doing so, and it will not be as 
massive a loss.

Indeed, if the smart contract platform code is open source, it may be possible 
to set up another implementation of the smart contract platform.
And it would be possible to at least try to convince all participants to switch to that 
new platform (again, via the "as long as everybody agrees" escape hatch).
Again, this is not possible with current federated sidechains, or Ethereum (if 
Ethereum fails, all ETH becomes valueless).


The proposal induces a very centralized system, to my knowledge all of
existing sidechains whether on bitcoin or ethereum are centralized,
except lightning (if we forget that someone must watch what others are
doing when you are on a trek in Nepal)

I would not lump together Lightning with sidechains.
Indeed, this design moves things closer to true offchain techniques (as in 
Lightning) than to sidechain techniques.

So while centralized, it is less centralized than a federated sidechains.


Now I don't get why a sidechain should be a blockchain on top on another
one (given also that we can't consider bitcoin or ethereum as
decentralized today, so the path might be long for the sidechains...),
the latest is used to store the final state, the former does not have to
store forever the intermediate states, then it could just use a
decentralized system (not necessarilly blockchain-like) to store the
intermediate states and maybe be a distributed escrow

I know, easy to say, please do it (why not), now the fact that
sidechains claim to be decentralized or that they will be is just
misleading people (that's not the case of your proposal but it does not
say what happens if the platforms go down)

Perhaps it can be a next step.

Regards,
ZmnSCPxj


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


Re: [bitcoin-dev] Smart Contracts Unchained

2019-04-04 Thread Aymeric Vitte via bitcoin-dev

What if the smart contract platform(s) disappear?

The proposal induces a very centralized system, to my knowledge all of 
existing sidechains whether on bitcoin or ethereum are centralized, 
except lightning (if we forget that someone must watch what others are 
doing when you are on a trek in Nepal)


Now I don't get why a sidechain should be a blockchain on top on another 
one (given also that we can't consider bitcoin or ethereum as 
decentralized today, so the path might be long for the sidechains...), 
the latest is used to store the final state, the former does not have to 
store forever the intermediate states, then it could just use a 
decentralized system (not necessarilly blockchain-like) to store the 
intermediate states and maybe be a distributed escrow


I know, easy to say, please do it (why not), now the fact that 
sidechains claim to be decentralized or that they will be is just 
misleading people (that's not the case of your proposal but it does not 
say what happens if the platforms go down)



Le 04/04/2019 à 03:55, ZmnSCPxj via bitcoin-dev a écrit :

https://zmnscpxj.github.io/bitcoin/unchained.html

Smart contracts have traditionally been implemented as part of the consensus 
rules of some blokchain.  Often this means creating a new blockchain, or at 
least a sidechain to an existing blockchain.  This writeup proposes an 
alternative method without launching a separate blockchain or sidechain, while 
achieving security similar to federated sidechains and additional benefits to 
privacy and smart-contract-patching.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

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


Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC

2019-04-02 Thread Aymeric Vitte via bitcoin-dev
Right and everybody knows that Tether is the most clever sidechain ever 
invented far more sophisticated than lightning, which makes me think 
that a punishment should be added in the proposal for the cheater 
advertising a price < 50 k (or 100) and/or selling before 1-3 years 
(tbd) so all his coins go to the Bitcoin Mediator, a new notion here to 
sustain the community (I modestly apply for the position)



Le 01/04/2019 à 13:50, Dana L. Coe via bitcoin-dev a écrit :
I suggest in the spirit of the times that we not use USD as the 
reference, but USDT.


Everyone knows Tethers are much more flexible in tracking the true 
value of the US dollar.


Dana

On Apr 1, 2019, at 7:22 PM, Melvin Carvalho via bitcoin-dev 
> wrote:




On Mon, 1 Apr 2019 at 02:32, Luke Dashjr via bitcoin-dev 
> wrote:


Certain parts of the community have been selling bitcoins for
unreasonably
low prices. This has halted Bitcoin's valuation at $20k and even
driven the
price down below $15k! However, clearly Bitcoin is worth much
more than
that, and there is widespread support for higher prices.

In light of this, I have written and implemented two BIPs: one to
add a
signed price field to Bitcoin transactions, and the other to
softfork a
minimum price of $50k USD/BTC a year from today.

The BIPs are here, as well as included at the bottom of this
email for
convenience:
https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki

https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki

A reference implementation is here:
https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k

Please review ASAP so we can get these deployed in Bitcoin Core
v0.18.


This seems a little arbitrary.  Ask yourself, "Why the USD?".  Yes, 
it is the dominant currency now, but in 2, 6, 10, 14 years?  Who knows.


You could make equally an argument to denominate in euros.  Or a 
basket of currencies, or even the Bancor.


However the wider question is why even denominate in fiat at all?

I suggest denominating the minimum value in satoshsis themselves, 
which would be a negligable upgrade to the network.



Luke



  BIP: ?
  Layer: Applications
  Title: Signed USD Price Indicator
  Author: Luke Dashjr mailto:luke%2b...@dashjr.org>>
  Comments-Summary: No comments yet.
  Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-
  Status: Draft
  Type: Standards Track
  Created: 2019-04-01
  License: BSD-2-Clause


==Abstract==

This BIP proposes a method to explicitly specify and sign the
USD/BTC price
for transactions.

==Copyright==

This BIP is licensed under the BSD 2-clause license.

==Motivation==

Certain parts of the community have been selling bitcoins for
unreasonably low
prices. This has halted Bitcoin's valuation at $20k and even
driven the price
down below $15k! However, clearly Bitcoin is worth much more than
that, and
there is widespread support for higher prices.

This problem can be fixed by setting a global minimum price for
bitcoins.
Unfortunately, today, the consensus protocol is completely
oblivious to the
price bitcoins are traded at. Therefore, we must first add a
field to Bitcoin
transactions to indicate their price.

==Specification==

===New field and legal implication===

A new field is added to Bitcoin transactions. This field, if
present, must
represent the honest and true USD/BTC rate used for the
transaction. By
signing the transaction, the sender legally affirms this is the
valuation of
bitcoins used for the transaction.

For the avoidance of doubt: when the transaction is valued in a
currency other
than USD, any reasonable exchange rate may be used to come up
with the USD
valuation.

===Serialisation===

When serialising the transaction for any purpose, including
signing, weight
calculation, and so on, the output count must be incremented by
one. Prior to
the first real output, the following bytes must be inserted:

* Constant: 00 00 00 00 00 00 00 00
* A single byte, the size in bytes of the remainder of the
inserted data
* Constant: 6a 04 55 53 44 24
* A single byte, the size in bytes of the remainder of the
inserted data
* The USD/BTC rate used for the transaction, in standard signed
integer
serialisation, with all leading zeros removed (except as
necessary to
preserve the sign bit).

==Backwards compatibility==

===Consensus===

The new price field is serialised as a dummy output, with a value
of zero, and
a scriptPubKey that begins with OP_RETURN (6a). Existing nodes
will ignore
this dummy 

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

2019-03-14 Thread Aymeric Vitte via bitcoin-dev
Apparently I don't have the same experience than others here, what I
encountered is no reject message received for wrong txs, but from what I
understand here it's not unusual to receive reject message for valid
txs, then I don't see how it can be really helpful/relied, given also
that the reject messages are unclear and even can be misleading

As it was written already I found it useful only for debugging purposes,
at least it can give some kind of ideas about what happened,
bitcoin-transactions is implementing the bitcoin protocol but does not
act as a node and does not pretend to fake a node behavior waiting for
example to get the tx back, is the method of sending a getdata for a
given tx to see if it was accepted by a node wrong ? It can't guarantee
100% that it was successful and will propagate but I see that you are
doing completely different things

Le 13/03/2019 à 23:30, Dustin Dettmer via bitcoin-dev a écrit :
> I’ve solved the same problem in a different way.
>
> 1) Submit a transaction
> 2) Collect all reject messages (that have matching txid in the reject
> data)
> 3) Wait 16 seconds after first error message received (chosen
> semirandomly from trial and error) before processing errors
> 4) Wait for our txid to be submitted back to us through the mempool,
> if we get it notify success and delete all pending error events
> 5) Signal failure with the given reject code if present (after the 16
> seconds have elapsed)
> 6) If no error or success after 20 seconds, signal timeout failure
>
> This works fairly well in testing. Newer transaction types seem to
> generate reject codes 100% of the time (from at least one node when
> sending to 4 nodes) so this culling / time delay approach is
> essentially required.
>
> On a related note: One issue is that RBF attempts with too small a fee
> and accidental double spends (with enough fee for 1 tx but not a RBF)
> both generate the same reject code: not enough fee.
>
> A new reject code for RBF based too small of fee would definitely make
> for a better user experience as I’ve seen this exact problem create
> confusion for users.
>
> Removing reject codes would make for a much worse user experience.
> “Your tx failed and we have no idea why” would be the only message and
> it would require waiting for a full timeout.
>
> On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev
>  > wrote:
>
> > I'd like to better understand this, but it would be easier to just
> > read the code than ask a bunch of questions. I tried looking for the
> > handling of reject messages in Android  Bitcoin Wallet and BitcoinJ
> > and didn't really find and handling other than logging exceptions.
> > Would you mind giving me a couple pointers to where in the code
> > they're handled?
>
> 
> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

2019-03-07 Thread Aymeric Vitte via bitcoin-dev
Bitcoin-transactions did use this "feature", but does not rely on it any
longer since I observed some strange behavior sometimes (no reject
message for bad tx, with suprnova for example as far as I remember),
then it doublechecks using getdata to see if the tx is in mempool

Indeed you can't trust what a node tells you with or without reject
(idem for getdata but more difficult to fake and better than nothing)

Then I don't see any problem to remove it, taking into account also that
the error message is too vague to be really helpful
https://github.com/bitcoin/bitcoin/issues/11891

Le 06/03/2019 à 01:53, Marco Falke via bitcoin-dev a écrit :
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected to 
> a
> trusted node. At this time, I am not aware of any software that requires this
> feature, and I would like to remove if from Bitcoin Core to make the codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended 
> alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network protocol
>   should be done by inspecting the log messages that are produced by a recent
>   version of Bitcoin Core. Bitcoin Core logs debug messages
>   (`-debug=`) to a stream (`-printtoconsole`) or to a file
>   (`-debuglogfile=`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
>   - `submitblock`
>   - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
>   - `sendrawtransaction`
>   - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
>   transaction has propagated the network, nor should wallets use "reject"
>   messages to set transaction fees. Wallets should rather use fee estimation
>   to determine transaction fees and set replace-by-fee if desired. Thus, they
>   could wait until the transaction has confirmed (taking into account the fee
>   target they set (compare the RPC `estimatesmartfee`)) or listen for the
>   transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there 
> are
> valid concerns about its removal.
>
> Marco
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


[bitcoin-dev] Fwd: BIP proposal - Signatures of Messages using Bitcoin Private Keys

2019-03-06 Thread Aymeric Vitte via bitcoin-dev
Re-sending to the list since it never made it

BIP or not, at least this process desserves to be documented precisely


 Message transféré 
Sujet : Re: [bitcoin-dev] BIP proposal - Signatures of Messages using
Bitcoin Private Keys
Date :  Mon, 18 Feb 2019 16:29:34 -0800
De :Christopher Gilliard 
Pour :  Aymeric Vitte 
Copie à :   Bitcoin Protocol Discussion




Trying the four possible options (p2pkh compressed, p2pkh uncompressed,
seg3, and bech32) is certainly a possibility and in fact, that's what I
ended up doing because not every wallet implements something like this,
but if there is a header field currently in use, it seemed reasonable to
me to use it specify which type of key is being used. If the header
includes whether the key is compressed or not compressed it seems
logical to include all data about what type of key it is and not just
this one type of information. That's why I thought the solution made
sense and I wrote it up.

On Mon, Feb 18, 2019 at 3:50 PM Aymeric Vitte mailto:vitteayme...@gmail.com>> wrote:

Ah, OK, that's of course a good thing to document this undocumented
(and strange) stuff, as a matter of fact I implemented it after
reading your post (because this was on my todo list since some time)
and got annoyed quickly, mainly by what is doing
formatMessageForSigning (which is quite trivial when you know it but
would be good to document precisely)

So, yes, it's a good idea to write this, regarding the header I
still don't see the use, testing the different possibilities is not
a big deal, why the signature format is not the same as transactions
one is mysterious too

Le 19/02/2019 à 00:24, Christopher Gilliard a écrit :
> The proposal includes actual code that does verification, but I
> didn't include code for signing. I thought it could be inferred,
> but I could at least include a description of how to sign. I am
> not sure exactly what part you are referring to by "keys speech",
> but the signatures are done by ECDSA keys so it's hard to not
> include anything about keys even though that's not the main topic.
> The "Background on ECDSA keys" section was mainly meant to give
> background about what kind of keys Bitcoin uses, for people who
> already know that they can easily skip this section so I would
> probably think it's best just to leave in.  Maybe it should be at
> the end as an addendum though. Yes, I did not invent any of this,
> I'm just documenting what people actually seem to do because I had
> to verify signatures as part of a project I'm working on. I would
> have liked to have had this document when I started the project so
> I thought it might be useful to others since as far as I can tell
> this was not specified anywhere. The reason for including this
> data in the header is the same that compressed/uncompressed is
> included in the header so that you know which type of key the
> signature is from and you don't have to try all options to see if
> any matches. This is why Trezor did that way and why I documented
> it. I'm sure there are other ways to do this, but since this is
> out there in the field being used and is a reasonable solution, I
> thought I'd write it up.
>
> On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte
> mailto:vitteayme...@gmail.com>> wrote:
>
> Then, since you wrote this proposal, maybe you should add the
> very precise description of the signing/verification process
> since it is documented nowhere
>
> I don't get the use of the speech regarding keys while it
> should focus on signatures which are summarized in a vague
> sentence inspired by your ref [2] with a not very logical link
> to the next paragraph stating that r,s should be 32B and the
> whole thing 65B with a header of 1B, you did not invent it,
> that's probably the rule, not sure where it is specified again
> and for what purpose, the header seems completely of no use
> especially when you extend to segwit/bech32 since you just
> have to check that related compressed key matches
>
> Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a
> écrit :
>> I have written up a proposed BIP. It has to do with Signature
>> formats when using Bitcoin Private keys. It is
>> here: https://github.com/cgilliard/BIP/blob/master/README.md
>>
>> This BIP was written up as suggested in this github
>> issue: https://github.com/bitcoin/bitcoin/issues/10542
>>
>> Note that the proposal is inline with the implementation that
>> Trezor implemented in the above issue.
>>
>> Any feedback would be appreciated. Please let me know what
>> the steps are with regards to getting a BIP number assigned
>> or any other process steps required.
>>

Re: [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys

2019-03-05 Thread Aymeric Vitte via bitcoin-dev
Ah, OK, that's of course a good thing to document this undocumented (and
strange) stuff, as a matter of fact I implemented it after reading your
post (because this was on my todo list since some time) and got annoyed
quickly, mainly by what is doing formatMessageForSigning (which is quite
trivial when you know it but would be good to document precisely)

So, yes, it's a good idea to write this, regarding the header I still
don't see the use, testing the different possibilities is not a big
deal, why the signature format is not the same as transactions one is
mysterious too

Le 19/02/2019 à 00:24, Christopher Gilliard a écrit :
> The proposal includes actual code that does verification, but I didn't
> include code for signing. I thought it could be inferred, but I could
> at least include a description of how to sign. I am not sure exactly
> what part you are referring to by "keys speech", but the signatures
> are done by ECDSA keys so it's hard to not include anything about keys
> even though that's not the main topic. The "Background on ECDSA keys"
> section was mainly meant to give background about what kind of keys
> Bitcoin uses, for people who already know that they can easily skip
> this section so I would probably think it's best just to leave in. 
> Maybe it should be at the end as an addendum though. Yes, I did not
> invent any of this, I'm just documenting what people actually seem to
> do because I had to verify signatures as part of a project I'm working
> on. I would have liked to have had this document when I started the
> project so I thought it might be useful to others since as far as I
> can tell this was not specified anywhere. The reason for including
> this data in the header is the same that compressed/uncompressed is
> included in the header so that you know which type of key the
> signature is from and you don't have to try all options to see if any
> matches. This is why Trezor did that way and why I documented it. I'm
> sure there are other ways to do this, but since this is out there in
> the field being used and is a reasonable solution, I thought I'd write
> it up.
>
> On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte  > wrote:
>
> Then, since you wrote this proposal, maybe you should add the very
> precise description of the signing/verification process since it
> is documented nowhere
>
> I don't get the use of the speech regarding keys while it should
> focus on signatures which are summarized in a vague sentence
> inspired by your ref [2] with a not very logical link to the next
> paragraph stating that r,s should be 32B and the whole thing 65B
> with a header of 1B, you did not invent it, that's probably the
> rule, not sure where it is specified again and for what purpose,
> the header seems completely of no use especially when you extend
> to segwit/bech32 since you just have to check that related
> compressed key matches
>
> Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
>> I have written up a proposed BIP. It has to do with Signature
>> formats when using Bitcoin Private keys. It is
>> here: https://github.com/cgilliard/BIP/blob/master/README.md
>>
>> This BIP was written up as suggested in this github
>> issue: https://github.com/bitcoin/bitcoin/issues/10542
>>
>> Note that the proposal is inline with the implementation that
>> Trezor implemented in the above issue.
>>
>> Any feedback would be appreciated. Please let me know what the
>> steps are with regards to getting a BIP number assigned or any
>> other process steps required.
>>
>> Regards,
>> Chris
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org 
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> -- 
> 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
>
-- 
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 

Re: [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys

2019-03-05 Thread Aymeric Vitte via bitcoin-dev
Then, since you wrote this proposal, maybe you should add the very
precise description of the signing/verification process since it is
documented nowhere

I don't get the use of the speech regarding keys while it should focus
on signatures which are summarized in a vague sentence inspired by your
ref [2] with a not very logical link to the next paragraph stating that
r,s should be 32B and the whole thing 65B with a header of 1B, you did
not invent it, that's probably the rule, not sure where it is specified
again and for what purpose, the header seems completely of no use
especially when you extend to segwit/bech32 since you just have to check
that related compressed key matches

Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
> I have written up a proposed BIP. It has to do with Signature formats
> when using Bitcoin Private keys. It is
> here: https://github.com/cgilliard/BIP/blob/master/README.md
>
> This BIP was written up as suggested in this github
> issue: https://github.com/bitcoin/bitcoin/issues/10542
>
> Note that the proposal is inline with the implementation that Trezor
> implemented in the above issue.
>
> Any feedback would be appreciated. Please let me know what the steps
> are with regards to getting a BIP number assigned or any other process
> steps required.
>
> Regards,
> Chris
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] BIP39 seeds

2019-01-03 Thread Aymeric Vitte via bitcoin-dev
What I have in mind is in my latest reply (difficult to have some kind
of fluent discussions on this list given the moderation and delayed posts)

I would just add that the derivation method (indeed something like what
you are sketching below) should estimate that there is enough entropy
from the secret, if not just throw

Le 02/01/2019 à 19:06, James MacWhyte via bitcoin-dev a écrit :
> On Wed, Jan 2, 2019 at 3:40 AM Alan Evans via bitcoin-dev
>  > wrote:
>
>
> I think any method that doesn't use real entropy, but some fake
> source of randomness, such as a book is asking to be hacked and so
> is not a reasonable idea.
>
> If an algorithm for book text to BIP39 sentence ever became well
> used, common books will be systematically searched for accounts.
> People will also choose their favourite passages, so I would
> expect to see collisions.
>
>
> I tend to have this conversation a lot ;) I'm not sure what Aymeric
> has in mind, but my suggestions are for use by the small few who
> properly understand how these things work. I am not suggesting
> blockchain.info  require every user to choose
> a book passage to use as their backup phrase!
>
> There are so many small things that could be done to make a text input
> unique. Choose the X number of words from the start of the Nth
> sentence. Replace all punctuation with exclamation points. Combine two
> sentences from different pages. It would be nigh impossible to brute
> force any of these, and would require hints/instructions from the
> owner to recover.
>
> But I admit if this is not intended for standardization, discussing it
> on this mailing list is probably unwarranted.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] BIP39 seeds

2019-01-01 Thread Aymeric Vitte via bitcoin-dev

You are simplifying too much what I am suggesting

What I am suggesting is: set a derivation method for BIP39 like for 
BIP32 (having the seed for BIP32 and not the derivation path is just 
like having nothing) and use this derivation method from a "book" (a 
"book" being a book, a document, a link, an image, whatever your secret 
can be), based on the fact that you will easily find from this 
derivation method "valid" BIP39 seeds (even if BIP39 does not enforce 
anything regarding valid phrases, everything can be valid as you 
mention, and this does not help in fact)


The derivation method will just define the way you select the words in 
the secret, and if everybody chooses the bible as the secret then this 
will not change the fact that it will be impossible to find the real 
seed without knowing the derivation path


Then you don't need to write the seed, you can easily plausible deny it, 
you can easily pass it to the family (using a passphrase does not say to 
them where they are supposed to use it)


"people lost"--> people think that there is some magic with BIP39 that 
will save them whatever they do (ie they don't even care of managing 
correctly the many easy to generate BIP39 seeds they are using) where 
they will always recover their seed and keys from BIP39/44/49, of course 
this does not work at all



Le 31/12/2018 à 17:52, Alan Evans a écrit :
> Using some algorithm to take some input and generate a bip39 phrase 
that you can use with any bip39 wallet sounds perfectly reasonable.


I think any method that doesn't use real entropy, but some fake source 
of randomness, such as a book is asking to be hacked and so is not a 
reasonable idea.


If an algorithm for book text to BIP39 sentence ever became well used, 
common books will be systematically searched for accounts. People will 
also choose their favourite passages, so I would expect to see collisions.


You should also note that BIP39 does not need input that is from the 
word list. You can use _any text as its input_, the word list and 
checksum check is just recommended to be a warning, but again, text 
chosen from public sources or common phrases is a bad idea for many 
reasons.


From BIP0039:
/> The conversion of the mnemonic sentence to a binary seed is 
completely independent from generating the sentence. This results in 
rather simple code; *there are no constraints on sentence structure* 
and clients are free to implement their own wordlists or even whole 
sentence generators, allowing for flexibility in wordlists for typo 
detection or other purposes./
/> Although using a mnemonic not generated by the algorithm described 
in "Generating the mnemonic" section is possible, this is not advised 
and software must compute a checksum for the mnemonic sentence using a 
wordlist and issue a warning if it is invalid./


What you could do is use a regular true random BIP39 sentence in 
conjunction with a phrase from a book as the "passphrase" giving you 
that plausible deniability, right up to the point you put that in your 
will or tell someone, i.e. for the "what if something happens to me" 
case. Though I still think redirecting people to a book phase is risky 
for this, e.g. books have editions, there may be a change in the key 
place.


From BIP0039:/
/
/> The described method also provides plausible deniability, because 
every passphrase generates a valid seed (and thus a deterministic 
wallet) but only the correct one will make the desired wallet available./


Alan

P.S. "I have seen many people completely lost with their wallets 
because of [BIP39]": I would say "despite" not "because". These people 
would have lost/miss recorded a BIP32 hex seed as well.



On Thu, 27 Dec 2018 at 11:02, Aymeric Vitte via bitcoin-dev 
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:



Le 26/12/2018 à 19:54, James MacWhyte a écrit :


On Wed, Dec 26, 2018 at 11:33 AM Aymeric Vitte
mailto:vitteayme...@gmail.com>> wrote:

so, even with a tool like yours, they can be misleaded, for
example trying a few words to replace the missing/incorrect
one, get a valid seed and stay stuck with it forever trying
to play with BIP44/49 to find their keys


Just a small detail, but my tool actually looks up all the
possible combinations and then finds which one has been used
before by looking for past transactions on the blockchain.
Therefore, it won't tell you your phrase is correct unless it is
a phrase that has actually been used before (preventing what you
described).


I saw that your tool was querying blockchain.info
<http://blockchain.info>, but it cannot guess what derivation path
was used and if it is a standard one what addresses were used, and
even if successful it works only for bitcoin (so maybe it should
just output the

Re: [bitcoin-dev] BIP39 seeds

2018-12-27 Thread Aymeric Vitte via bitcoin-dev

Le 26/12/2018 à 19:54, James MacWhyte a écrit :
>
> On Wed, Dec 26, 2018 at 11:33 AM Aymeric Vitte  > wrote:
>
> so, even with a tool like yours, they can be misleaded, for
> example trying a few words to replace the missing/incorrect one,
> get a valid seed and stay stuck with it forever trying to play
> with BIP44/49 to find their keys
>
>
> Just a small detail, but my tool actually looks up all the possible
> combinations and then finds which one has been used before by looking
> for past transactions on the blockchain. Therefore, it won't tell you
> your phrase is correct unless it is a phrase that has actually been
> used before (preventing what you described).

I saw that your tool was querying blockchain.info, but it cannot guess
what derivation path was used and if it is a standard one what addresses
were used, and even if successful it works only for bitcoin (so maybe it
should just output the ~1500 possible phrases and/or xprv, and be
completely offline, this is still doable for people)

>
> Using some algorithm to take some input and generate a bip39 phrase
> that you can use with any bip39 wallet sounds perfectly reasonable.

I forgot to mention that this can help also solving the "what if
something happens to me" case giving to the family the seed and the
parameter(s) for the derivation path, or an easy way to find it (better
than something like: remind this passphrase, take the sha256 of it, then
use some other stuff to find the encryption algo, take n bytes of the
hash, use it to decode my wallet or my seed... and then everybody
looking at you like crazy)

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


Re: [bitcoin-dev] BIP39 seeds

2018-12-27 Thread Aymeric Vitte via bitcoin-dev
Another drawback I think is that people are not using it as seeds, they
just go to a wallet sw which proposes a new seed, write it somewhere, do
something with the wallet and forget about it, go to another one, create
another wallet, etc

Apparently it is not very well known even here that the probabilities
are very high to get a valid BIP39 seed even with 24 words, so, even
with a tool like yours, they can be misleaded, for example trying a few
words to replace the missing/incorrect one, get a valid seed and stay
stuck with it forever trying to play with BIP44/49 to find their keys

Probably what I am suggesting is not new (and therefore maybe not a good
suggestion): given a secret seed (a book, a document, a link, etc) and a
derivation path (an algo with secret parameter(s) to derive/order the
words and select the valid bip39 sequences), you get your BIP39 seeds
and don't have to write them

Of course we don't have to use necessarilly BIP39 for this but this is
what we have everywhere and this is what is compatible with it, then you
could use the same or a fake written "not very well hidden" BIP39 seed
to plausibly deny your real wallet

Le 25/12/2018 à 01:30, James MacWhyte a écrit :
>
>
> On Mon, Dec 24, 2018 at 2:48 PM Aymeric Vitte via bitcoin-dev
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>
> I don't see very well why it's easier to write n words that you
> cannot choose rather than a 32B BIP32 hex seed, and I have seen
> many people completely lost with their wallets because of this
>
>
> In practice it has quite a few qualities that make it a bit more
> resilient for physical (written) storage.
>
> If a few letters of a word get rubbed off or otherwise become
> illegible, it is pretty easy for a native speaker to figure out what
> the word is supposed to be. Even a non-native speaker could look
> through the word list and figure out which word fits. Missing
> characters in a hex string require more advanced brute force
> searching, which the average user isn't capable of.
>
> Additionally, having the bits grouped into words makes a more serious
> recovery easier. If you lose one entire word, it can be brute forced
> in about 5 minutes on a normal pc, even if you don't know which
> position the missing word is in (I have published a tool that does
> just this: https://jmacwhyte.github.io/recovery-phrase-recovery). If
> you are missing two words, you can brute force it in about a week
> (napkin math).
>
> If you were missing a random chunk of a hex string, I don't know how
> you'd go about brute forcing that in a timely manner.
>
> As an aside, from a UX standpoint we've seen that the 12 words don't
> *look* important so people don't take them seriously (and they get
> lost). A hex string or equivalent would look more password-y, and
> therefore would most likely be better protected by users.
>
> James

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


Re: [bitcoin-dev] BIP39 seeds

2018-12-24 Thread Aymeric Vitte via bitcoin-dev
Exactly

This is surprising, I would have expected the probabilities to be much
more lower

It just means that scanning whatever (secret) book, document, link, etc,
you will find easily BIP39 seeds, even of 24 words

So, it just means that you don't have to write your seed since you can
recover it that way, given a secret source and specific algo with custom
parameters, this could be used for plausible deniability also

For now I still dislike BIP39 and alike (because I don't see very well
why it's easier to write n words that you cannot choose rather than a
32B BIP32 hex seed, and I have seen many people completely lost with
their wallets because of this), but I could change my mind, and despite
of further improvements for this ratio, could what I am suggesting make
sense?

Le 23/12/2018 à 19:46, Pavol Rusnak a écrit :
> On 22/12/2018 00:58, Aymeric Vitte via bitcoin-dev wrote:
>> Has anybody already looked at this: given N randomly chosen words
>> belonging to a BIP39 2048 words dictionary, what is the probability to
>> get a "valid" BIP39 seed (ie with the right checksum)?
> 1:256 for 24 words
> 1:16 for 12 words
>
> This ratio is not too great and will be improved in the upcoming SLIP39
> standard: https://github.com/satoshilabs/slips/blob/master/slip-0039.md
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] BIP39 seeds

2018-12-23 Thread Aymeric Vitte via bitcoin-dev
Has anybody already looked at this: given N randomly chosen words
belonging to a BIP39 2048 words dictionary, what is the probability to
get a "valid" BIP39 seed (ie with the right checksum)?

The result looks (very) surprising to me and might have some use cases,
just would like to know if this topic has already been discussed before
going further

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

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


Re: [bitcoin-dev] Building a Bitcoin API and query system.

2018-08-30 Thread Aymeric Vitte via bitcoin-dev


Le 28/08/2018 à 20:36, Jonas Schnelli via bitcoin-dev a écrit :
> I’d like to hear some concrete use-cases for a such block explorer(ish) API.

https://github.com/Ayms/bitcoin-transactions which is somewhere
bitcoin-cli outside of bitcoin core with no wallet, which implies that
you don't want to mix/provide your wallet with/to the app creating your
transactions and/or you don't want to use wallet sw

Problem: quasi nobody succeeds to use it (and probably this trend is
unlikely to revert), that's why there is https://peersm.com/wallet which
is querying the info outside and output the right command to use with
the tool (or output the transaction if people put their keys, which is
of course not advised unless they are sure that the corresponding
addresses are dead ones)

It is planned to put the app for the advanced mode (ie people must know
all the parameters) as an offline one inside browsers, then back to the
above problem...

So probably the offline mode should include a phase where the tool
connects to some APIs/explorers like the one suggested here before
switching to the offline mode to enter the keys, this will always be not
very secure for the query phase unless it can become something
decentralized (and usable the same way on different networks), which as
far as I understand is envisioned here

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


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


Re: [bitcoin-dev] bitcoin-transactions

2018-08-01 Thread Aymeric Vitte via bitcoin-dev
You are right, that's what I have been saying for online services that
ask for private keys, and even the seeds

The problem is that people can't refrain to put their keys for example
to get "free" coins, typically they try to use bitcoin-transactions,
don't succeed and go put their seeds in an online service

At least it gives an alternative, private keys are optional and the tool
will output the command to use with bitcoin-transactions, and if they
want to put directly their keys, then...

"Move your coins by yourself" refers more to "don't get trapped by your
wallet(s) or things that you don't master like multisig, segwit, bech32,
etc"

As I said the idea would be to end up with an offline tool should some
people support/finance the effort


Le 01/08/2018 à 07:45, Marcel Jamin a écrit :
> IMHO you should almost never publish a service that asks users for
> private keys.
>
> A warning isn't enough. Your server might get compromised.
>
> "Move your coins by yourself" isn't even correct if your server is
> involved.
>
> On Tue, 31 Jul 2018 at 13:26, Aymeric Vitte via bitcoin-dev
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> I know this list is not to advertise personal projects but
> https://peersm.com/wallet might be of some interest, this is the web
> interface for https://github.com/Ayms/bitcoin-transactions since
> apparently quasi nobody succeeds to use it
>
> As far as I know (and surprisingly) this is the only online tool that
> converts bech32 addresses (Sipa's one does not output something
> understandable by everybody, the tool is using his code), the only one
> that converts from any address to any address, maybe the only one that
> decodes simply redeem scripts and probably the only one that allows to
> create transactions by its own (the advanced mode is not
> implemented for
> now but will be soon)
>
> Ideally it should be an offline tool if there is some incentive to do
> so, so of course it is not advised to use his private keys for now
>
> Maybe they are mistaken but some users are reporting invalid bech32
> addresses from their Electrum wallet, after segwit, bech32 confusion
> seems to be the topic of the moment
>
> Regards
>
> Aymeric
>
> -- 
> 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
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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


[bitcoin-dev] bitcoin-transactions

2018-07-31 Thread Aymeric Vitte via bitcoin-dev
I know this list is not to advertise personal projects but
https://peersm.com/wallet might be of some interest, this is the web
interface for https://github.com/Ayms/bitcoin-transactions since
apparently quasi nobody succeeds to use it

As far as I know (and surprisingly) this is the only online tool that
converts bech32 addresses (Sipa's one does not output something
understandable by everybody, the tool is using his code), the only one
that converts from any address to any address, maybe the only one that
decodes simply redeem scripts and probably the only one that allows to
create transactions by its own (the advanced mode is not implemented for
now but will be soon)

Ideally it should be an offline tool if there is some incentive to do
so, so of course it is not advised to use his private keys for now

Maybe they are mistaken but some users are reporting invalid bech32
addresses from their Electrum wallet, after segwit, bech32 confusion
seems to be the topic of the moment

Regards

Aymeric

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

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


Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.

2018-04-10 Thread Aymeric Vitte via bitcoin-dev
Indeed, this impacts jsbn only normally since all others from the time
getRandomValues was available are supposed to implement both


Le 10/04/2018 à 15:32, Jason Davies a écrit :
>>> Note that even with v1.4, it still does not use high-quality entropy for
>>> Internet Explorer, because getRandomValues is provided under window.msCrypto
>>> for that browser.
>> I don't know for that one, what was the issue?
> I simply meant that Internet Explorer implements the Web Cryptography API 
> under
> window.msCrypto instead of window.crypto.  Thus, unless
> msCrypto.getRandomValues is used, high-quality entropy will not have been used
> by any of these libraries under Internet Explorer.
>
> --
> Jason Davies, https://www.jasondavies.com/
>

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

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


Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.

2018-04-10 Thread Aymeric Vitte via bitcoin-dev
I used jsbn in the past, then I made some research too

Apparently window.crypto.getRandomValues was introduced in jsbn mid 2012
(according to the wayback machine, but 2012/2013 does not make any
difference, see below), was available in Chrome since 2011 (but indeed
see "window.crypto.getRandomValues() uses a weak CSPRNG"
https://bugs.chromium.org/p/chromium/issues/detail?id=552749 fixed *end
*of 2015, funny to see that those that did specify the Webcrypto API did
not implement it correctly...), in FF in 2013
(https://website-archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-US/firefox/21.0/releasenotes/)
, in IE in 2013 and Safari ~2012/2013, at least that's the official
dates for the Webcrypto API implementation, maybe something existed
before, but it's not so easy to seek for the history

The window.crypto.random check is in jsbn since the begining (2006) and
only returns true for Netscape browsers before Netscape 5/6, ie Firefox
(2000), see
https://books.google.fr/books?id=UooAblGoGN8C=PA85=PA85=browser+appversion+4=bl=dVijsOR0ov=6SnElm56-bAvmGlKqUAdoGLAs2A=fr=X=2ahUKEwirhtaqva_aAhUFchQKHQ4JCk4Q6AEwBXoECAAQcQ#v=onepage=browser%20appversion%204=false)

>From the existing tools, there was not only jsbn, everybody was using
Math.random (sjcl, cryptoJS, forge, etc) with different implementations
and everybody did put a note stating that it might be insecure with an
"improvement to come" comment

We can probably assume that nobody was using Netscape any longer when
Bitcoin started

The conclusion seems to be that at least all wallets generated by js
tools inside browsers since bitcoin exists until 2011 are impacted by
the Math.random weakness if applicable to the related implementations,
the Math.random or RC4 (Chrome) weakness between 2011 and 2013, and RC4
weakness for Chrome users until end of 2015

And all wallets using jsbn are impacted by Math.random and RC4 until
2013 (or end 2015 for Chrome), then still by the RC4 fallback step after

> Note that even with v1.4, it still does not use high-quality entropy
for Internet Explorer, because getRandomValues is provided under
window.msCrypto for that browser

I don't know for that one, what was the issue?

Le 10/04/2018 à 10:51, Jason Davies via bitcoin-dev a écrit :
> On 10 Apr 2018, at 00:39, m...@musalbas.com wrote:
>
>> The original disclosure didn't contain any information about the library
>> in question, so I did some digging.
>>
>> I think that the vulnerability disclosure is referring to a pre-2013
>> version of jsbn, a JavaScript crypto library. Before it used the CSRNG
>> in the Web Crypto API, it tried to use nsIDOMCrypto, but incorrectly did
>> a string comparison when checking the browser version.
>>
>> In practice though, this doesn't really matter, because
>> navigator.appVersion < "5" returns true anyway for old browsers. The
>> real issue is that modern browsers don't have window.crypto.random
>> defined, so Bitcoin wallets using a pre-2013 version of jsbn may not be
>> using a CSPRNG, when run on a modern browser.
> Yes, it looks like high-quality entropy via crypto.getRandomValues was only
> added in Tom Wu's latest version (v1.4) in July 2013.
>
> Note that even with v1.4, it still does not use high-quality entropy for
> Internet Explorer, because getRandomValues is provided under window.msCrypto
> for that browser.
>
>   http://www-cs-students.stanford.edu/~tjw/jsbn/rng.js
>
>> As is noted though, even if a CSPRNG is used, the library passes the
>> output of the CSPRNG through RC4, which generates some biased bits,
>> leading to possible private key recovery.
> I think this is the real issue: even if high-quality entropy is utilised, the
> RNG is RC4-based, which is known to generate biased output.
>
> Finally, note that even Chrome used RC4 for crypto.getRandomValues at one
> point (as recently as 2015)!
>
>   https://bugs.chromium.org/p/chromium/issues/detail?id=552749
>
> --
> Jason Davies, https://www.jasondavies.com/
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Possible change to the MIT license

2018-02-13 Thread Aymeric Vitte via bitcoin-dev
No, the problem is not bitcoin being under any kind of attack by the
forks for me, but the forks fooling people because, again, reusing the
bitcoin core code is too easy

I don't know if there can be a legal solution to this which would keep
some open source aspect of the code, but at least it deserves to be studied


Le 13/02/2018 à 16:24, Jameson Lopp via bitcoin-dev a écrit :
> If I'm understanding the problem being stated correctly:
>
> "Bitcoin is under a branding attack by fork coins."
>
> The proposed solution is to disincentivize fork coins from using the
> word Bitcoin by altering the license terms. I'm not a lawyer, but it
> seems to me that the words of the license are basically useless unless
> there is an entity that intends to make use of court systems to
> threaten noncompliant projects into submission.
>
> In my opinion, the perceived attack on Bitcoin here is social /
> marketing-based, thus it makes sense that any defense against said
> attack should also be social / marketing-based. I don't think that
> Bitcoin should be reliant upon courts or governments to defend itself
> against attacks of any form.
>
> On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev
>  > wrote:
>
>
>
> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CAÑUELO via
> bitcoin-dev"  >:
>
> ***
> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT
> THAT USES THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS
> MARKETING MATERIAL UNLESS THE SOFTWARE PRODUCED BY THAT
> PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN (CORE) BLOCKCHAIN
> ***
>
>
> That's better solved with trademarks. (whoever would be the
> trademark holder - Satoshi?)  
>
> This would also prohibit any reimplementation that's not formally
> verified to be perfectly compatible from using the name. 
>
> It also adds legal uncertainty. 
>
> Another major problem is that it neither affects anybody forking
> older versions of Bitcoin, not people using existing independent
> blockchain implementations and renaming them Bitcoin-Whatsoever. 
>
> And what happens when an old version is technically incompatible
> with a future version by the Core team due to not understanding
> various new softforks? Which version wins the right to the name? 
>
> Also, being unable to even mention Bitcoin is overkill. 
>
> The software license also don't affect the blockchain data. 
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Possible change to the MIT license

2018-02-13 Thread Aymeric Vitte via bitcoin-dev
I was thinking to post something very similar on this list but not sure
that it would get some kind of interest

Not sure how and if it can be done (ie license modification) but the
reuse of the bitcoin core code can allow even a child to launch a fork
and this mess should stop, maybe people like to get "free" coins but
they are misleaded, they can lose everything and there are some more
vicious side effects like replay protection collisions between forks,
this is already happening, nobody seems to care but I wrote:

Bitcoin Tartuffe, the ultimate fork - User guide: How to create your
bitcoin fork in 5mn, fool everybody and become rich
https://www.linkedin.com/pulse/user-guide-how-create-your-bitcoin-fork-5mn-fool-everybody-vitte

--> this is a parody of course but very close to the reality, some info
are intentionally wrong

The madness of bitcoin forks: risk, reward and ruin
https://www.linkedin.com/pulse/madness-bitcoin-forks-risk-reward-ruin-aymeric-vitte/

I don't think that it really impacts bitcoin itself but this is
definitely too easy for people to fork the bitcoin core code and launch
some shxtty fork

Probably nobody here follow this, as an example (among plenty) see this
https://bitcointalk.org/index.php?topic=2515675.msg30173307#msg30173307
completely absurd mess

Le 13/02/2018 à 13:25, JOSE FEMENIAS CAÑUELO via bitcoin-dev a écrit :
> Hi,
>
> Bitcoin is licensed under the MIT license 
> (https://github.com/bitcoin/bitcoin/blob/master/COPYING 
> ) which is one of the 
> most permissive licenses widely in use.
> While this almost restriction-less license has proved useful to many software 
> projects, I think it could be wise to question its current suitability for 
> this project, given the recent history.
>
> The difficulty among the general population to distinguish between Bitcoin 
> (the protocol and software) and bitcoin (the currency) arises spontaneously 
> from the intimate entanglement of both. 
> The current list of Bitcoin lookalikes includes: Bitcoin Cash, Bitcoin Gold, 
> Bitcoin Diamond, Bitcoin God, Bitcoin Clashic, Super Bitcoin, Bitcoin Hot, 
> Bitcoin X, Oil Bitcoin, Bitcoin World, Lightning Bitcoin...
>
> This recent flurry of hard forks is, IMHO, exacerbating the confusion about 
> the very nature of the project, and harming it in many ways.
>
> Although the liberal MIT license is (rightfully) beneficial to many other 
> projects, companies and individuals, it is my belief that several projects 
> are unfairly taking advantage of this generous license to attack Bitcoin 
> (both the software and the currency), confuse the public, and gain personal 
> profit in a way that is severely harming the Bitcoin ecosystem.
>
> Therefore, I’d like to raise the possibility of amending the MIT license in a 
> simple way, by adding a line such as:
>
>
> ***
> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES THE 
> NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS THE 
> SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN (CORE) 
> BLOCKCHAIN
> ***
>
> (This is just an approximation. A final version would probably have to 
> include a restriction to some soundalikes like BITKOIN, BIITCOIN,…)
>
> This way, I could legitimate use this software to create my own crypto coin, 
> or use it in Ethereum, Litecoin or any of the other legitimate cryptos, but I 
> could not make my “Bitcoin Whatever” fork and keep using this software as the 
> basis for it. I could also fork the bitcoin blockchain to create “Bcoin 
> lightspeed” but not “Bitcoin lightspeed” for instance.
>
> I know this would probably not prevent the explosion of forks in the future, 
> but maybe it could help mitigate the confusion among the users and the harm 
> to this community. Even if its enforceability is dubious, at least any 
> infringing project would be exposed to some liability. I see myself some 
> possible loopholes the way the license addendum is written. My intention is 
> not to arrive immediately to a final wording but to know if there is some 
> value to the idea of changing the license with this purpose.
>
>
> Jose Femenias
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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


Re: [bitcoin-dev] Why is deriving public key from the signature not used in Segwit?

2018-01-24 Thread Aymeric Vitte via bitcoin-dev
Indeed... I would have bet that I had other examples with p2pkh this
time but apparently I imagined it


Le 24/01/2018 à 12:35, Gregory Maxwell a écrit :
> On Wed, Jan 24, 2018 at 11:16 AM, Aymeric Vitte  
> wrote:
>> Then what about
>> https://blockchain.info/tx/226a8b08dc46a00e9ecec5567a303a0b354bef3c1674476eb5e4b627b2ace493?format=hex
>> ?
>>
>> Scriptsig:
>>
>> 473044022057a1234709270325e7215200f982546304cf465971cbd55d54231ead54ef1a7802207a82e93ef2b0f87188abe87bccb67ee9d5c650b1b58948e5b1c80ba1b4c43dc301
>>
>> No pubkey...
> Because the pubkey is in the scriptPubKey of vout 0 of
> 40872a376e98a1f8b285827c2ad8c5b3eec7d779d752dc3a4adda5d9bb70f3b5 which
> it is spending.

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

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


Re: [bitcoin-dev] Why is deriving public key from the signature not used in Segwit?

2018-01-24 Thread Aymeric Vitte via bitcoin-dev
Then what about
https://blockchain.info/tx/226a8b08dc46a00e9ecec5567a303a0b354bef3c1674476eb5e4b627b2ace493?format=hex
?

Scriptsig:

473044022057a1234709270325e7215200f982546304cf465971cbd55d54231ead54ef1a7802207a82e93ef2b0f87188abe87bccb67ee9d5c650b1b58948e5b1c80ba1b4c43dc301

No pubkey...


Le 24/01/2018 à 11:31, Gregory Maxwell a écrit :
> On Wed, Jan 24, 2018 at 10:24 AM, Aymeric Vitte  
> wrote:
>> out the fact that pubkey is there now even for standard p2pkh
>> transactions and it was not the case some time ago
>>
>> But I never got any answer regarding what motivated this change
>> (compared to the previous behavior) and when, so whether I am missing
>> something obvious, whether nobody wants to answer
> No such behaviour ever existed, you are simply mistaken.

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

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


Re: [bitcoin-dev] Why is deriving public key from the signature not used in Segwit?

2018-01-24 Thread Aymeric Vitte via bitcoin-dev
34 bytes in fact

I have asked already the question at least twice on this list pointing
out the fact that pubkey is there now even for standard p2pkh
transactions and it was not the case some time ago

But I never got any answer regarding what motivated this change
(compared to the previous behavior) and when, so whether I am missing
something obvious, whether nobody wants to answer

Txs without pubkey are now rejected then what is the element in the code
(protocol, version, etc) that "decided" this?


Le 24/01/2018 à 05:25, Gregory Maxwell via bitcoin-dev a écrit :
> On Wed, Jan 24, 2018 at 3:50 AM, Артём Литвинович via bitcoin-dev
>  wrote:
>> Greetings.
>>
>> I wanted to ask what was the rationale behind still having both public
>> key and signature in Segwit witness?
>>
>> As is known for a while, the public key can be derived from the
>> signature and a quadrant byte, a trick that is successfully used both
>> in Bitcoin message signing algorithm and in Ethereum transaction
>> signatures. The later in particular suggests that this is a perfectly
>> functional and secure alternative.
>> Leaving out the public key would have saved 33 bytes per signature,
>> which is quite a lot.
>>
>> So, the question is - was there a good reason to do it the old way
>> (security, performance, privacy, something else?), or was it something
>> that haven't been thought of/considered at the time?
> It is slow to verify, incompatible with batch validation, doesn't save
> space if hashing isn't used, and is potentially patent encumbered.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

2018-01-08 Thread Aymeric Vitte via bitcoin-dev
That's the point indeed and the scope is wider than XYZIP-39, even if
what I mean is the very contrary of your point (really bitcoin is
reserved to an elite understanding english/ascii letters?)

This proposal is tailor made for Trezor and does not simplify anything
for people, that's the contrary again

As I suggested in another response to this thread (which was moderated
due probably to some uninteresting parts of the discussion) it's time to
take a break and really make a survey worldwide of what people need,
what they understand and what they need to secure their coins, nobody
has any feedback about this (and maybe does not even care)

Wallets created a big mess implementing non standard things (or things
they thought standard but that are not), or things not intended for the
final use, or things that people can't understand, it's time to correct
this, unless wallets want to keep people tied forever to them (when I
read Trezor or other wallets docs, it's quite misleading, "sending coins
to your wallet", what does it mean? Nothing, and people think it means
something, this should stop now)

And again, I don't see the point of wordlist (in addition in a language
that they don't understand) compared to backing up a 32B hex string
(that you can encrypt different ways at different places), assuming that
the hex format can be made available in all languages

"yet I would not advise users to use a wordlist that might not have
support across multiple wallet implementations, resulting in lock-in or
worse"--> this single sentence shows how the whole model is wrong and
how you think that you can lock people

Le 08/01/2018 à 15:54, Greg Sanders via bitcoin-dev a écrit :
> Let me re-phrase: Is it a known thing for users to actually use it?
>
> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia  > wrote:
>
>
>
> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev
>  > wrote:
>
> Has anyone actually used the multilingual support in bip39?
>
>
>
> Copay (and all its clones) use it. 
>
>
>
>  
>
>
> If a feature of the standard has not been(widely?) used in
> years, and isn't supported in any major wallet(?), it seems
> indicative it was a mistake to add it in the first place,
> since it's a footgun in the making for some poor sap who can't
> even read English letters when almost all documentation is
> written in English.
>
> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev
>  > wrote:
>
> On 2018-01-08 at 07:35:52 +, 木ノ下じょな
> >
> wrote:
>
> This is very sad.
>
> The number one problem in Japan with BIP39 seeds is
> with English words.
>
> I have seen a 60 year old Japanese man writing down
> his phrase (because he kept on failing recovery), and
> watched him write down "aneter" for "amateur"...
>
> [...]
>
> If you understand English and can spell, you read a
> word, your brain processes the word, and you can spell
> it on your own when writing down.  Not many Japanese
> people can do that, so they need to copy letter for
> letter, taking a long time, and still messing up on
> occasion.
>
> [...]
>
> Defining "everyone should only use English, because
> ASCII is easier to plan for" is not a good way to move
> forward as a currency.
>
>
> Well said.  Thank you for telling of these experiences. 
> Now please, let’s put the shoe on the other foot.
>
> I ask everybody who wants an English-only mnemonic
> standard to entrust *their own money* to their abilities
> to very, very carefully write this down—then later, type
> it back in:
>
> すさん たんろ りゆう しもん ていおん しとう
> とこや はやい おうさま ほくろ けちゃっふ たもつ
>
> (Approximate translation:  “Whatever would you do if
> Bitcoin had been invented by somebody named Satoshi
> Nakamoto?”)
>
> No, wait:  That is only a 12-word mnemonic.  We are
> probably talking about a Trezor; so now, hey you there,
> stake the backup of your life’s savings on your ability to
> handwrite *this*:
>
> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>
> Ready to bet your money on *that* as a backup phrase in
> your own 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

2018-01-07 Thread Aymeric Vitte via bitcoin-dev
Calm down now and stop your "do you want a" or "link" stupid comments,
whether you are really willing to propose some improvements, whether you
are just posting for nothing

BIP39:

"The length of the derived key is 512 bits (= 64 bytes).

This seed can be later used to generate deterministic wallets using
BIP-0032 or similar methods."

So the derived key is the seed? (derived key... this seed, really?
"similar methods",funny) That's not clear, then why everybody is using
xpriv which corresponds to the first step of the derivation (ie the
derived key)? And why BIP39 does not follow BIP32 recommendation (32B seed)?

Anyway, I don't really care about this stuff in fact, the only
interesting thing in this discussion beside arguing around unclear specs
misleading many people would be if you can convince that BIP39 & co are
really usefull for people (and easier than writing a seed): what
feedback do you have, don't you see how it's a pain in the xss for
everybody?

And if the answer is positive how can you can make it easier for people
(I am amazed too that people know about BIPXYZ, they should not),
probably this discussion will bore people and get moderated, but as
mentioned below, even maybe off topic, the subject is wider

Le 06/01/2018 à 19:28, Alan Evans a écrit :
> > Unfortunately, even "yourself" seems not to know what he is talking
> about (so imagine for other people, 256 bits is advised --> 32B),
> probably that's why you brought this discussion off the list, then
> making recommendations to improve something that is misleading and
> messy is quite dubious
>
> And yet you still fail to read the BIP, do you want a
> link? https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki I
> repeat it says:
>
> between 128 and 512 bits
>
> So, that's between 16 and 64 bytes, the advisory of 256 is clearly a
> minimum.
>
> > That's another thing I completely dislike with BIP39, it ends up
> with xpriv, not the 32B seed
>
> Please also read
> BIP0039 https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki,
> it generates *a BIP32 seed only*, no xpriv, that's completely false,
> then you use BIP0032 as normal with the seed. Because BIP0039 produces
> a seed, your whole argument goes out of the window, you can write the
> seed if that's what you want to do, and throw away the mnemonic.
>
>
>
> On Sat, Jan 6, 2018 at 1:40 PM, Aymeric Vitte  > wrote:
>
> Unfortunately, even "yourself" seems not to know what he is
> talking about (so imagine for other people, 256 bits is advised
> --> 32B), probably that's why you brought this discussion off the
> list, then making recommendations to improve something that is
> misleading and messy is quite dubious
>
> And maybe you should take a look at what people you are talking to
> are doing before arguing stuff that you apparently don't know very
> well (ie "the length of the *derived *key", not the seed), cf
> https://github.com/Ayms/bitcoin-wallets
>  and even
> https://github.com/Ayms/zcash-wallets (not official but
> https://github.com/zcash/zips/issues/95)
> 
>
> But as you can notice there is a missing feature, ie to derive the
> wallets from xpriv, there is a comment in the repo why I don't
> like some things "Surprisingly from ~32 bytes keys BIP32 ends up
> with a 78 bytes format to describe them with all the necessary
> information like indexes, parent to possibly allow to revert the tree"
>
> That's another thing I completely dislike with BIP39, it ends up
> with xpriv, not the 32B seed, there are many, many, many posts in
> forums of people fighting to figure out their private keys derived
> from bip39/44/etc
>
> "No offence too" but please keep your advises for yourself, I
> indeed don't read closely inept BIPs, and never said I did not
> like BIP32, that's the contrary, I really like it
>
> Before firing plenty of BIPs that do not fit together people maybe
> should take a break and see what people are doing today (this is
> quite amazing) and why they got stolen
>
> And you seem to know very little about security, if you suspect
> you home printer, then suspect you OS, your hw, etc, (you really
> envision to generate a seed from a mobile device ???) writing 64
> characters is not very difficult for a human being, even easier
> than writing x words of y length
>
> See this too
> https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887
> ,
> the tutorial was corrected, but basic things are still missing, an
> offline version is when you disconnect from the internet, not when
> you use the "offline version"  (assuming that the browser storage
> or other stuff are not used...)
>

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

2018-01-07 Thread Aymeric Vitte via bitcoin-dev
Unfortunately, even "yourself" seems not to know what he is talking
about (so imagine for other people, 256 bits is advised --> 32B),
probably that's why you brought this discussion off the list, then
making recommendations to improve something that is misleading and messy
is quite dubious

And maybe you should take a look at what people you are talking to are
doing before arguing stuff that you apparently don't know very well (ie
"the length of the *derived *key", not the seed), cf
https://github.com/Ayms/bitcoin-wallets
 and even
https://github.com/Ayms/zcash-wallets (not official but
https://github.com/zcash/zips/issues/95)


But as you can notice there is a missing feature, ie to derive the
wallets from xpriv, there is a comment in the repo why I don't like some
things "Surprisingly from ~32 bytes keys BIP32 ends up with a 78 bytes
format to describe them with all the necessary information like indexes,
parent to possibly allow to revert the tree"

That's another thing I completely dislike with BIP39, it ends up with
xpriv, not the 32B seed, there are many, many, many posts in forums of
people fighting to figure out their private keys derived from bip39/44/etc

"No offence too" but please keep your advises for yourself, I indeed
don't read closely inept BIPs, and never said I did not like BIP32,
that's the contrary, I really like it

Before firing plenty of BIPs that do not fit together people maybe
should take a break and see what people are doing today (this is quite
amazing) and why they got stolen

And you seem to know very little about security, if you suspect you home
printer, then suspect you OS, your hw, etc, (you really envision to
generate a seed from a mobile device ???) writing 64 characters is not
very difficult for a human being, even easier than writing x words of y
length

See this too
https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887,
the tutorial was corrected, but basic things are still missing, an
offline version is when you disconnect from the internet, not when you
use the "offline version"  (assuming that the browser storage or other
stuff are not used...)

Re-ccing the list because again at a certain point of time the theory
should look at the reality and adapt accordingly, part of the example I
gave is off topic for this thread but globally (which could become
another thread) the message is: the bitcoin community should stop making
things complicate for people, releasing BIPs of no use just ends up with
complicating things more than it helps, people deserve to understand
what they are doing, manage their keys by their own and stop syncing
useless full nodes for every coin to sync their wallets, that's why I
made the tool, the first people that used it made some outstanding
mistakes that I did not envision now it's not possible any longer,
except if they give wrong destination addresses and nobody can't do
anything about this (btw the primary intent of the tool was for myself
and you are right for once, I did not know that people could do so big
mistakes, that's not their fault, I see it now, my mistake for
underestimating this)

Le 06/01/2018 à 16:00, Alan Evans a écrit :
> You're mistaken. BIP32 does not require a particular length. It
> recommends:
>
>   * Generate a seed byte sequence S of a chosen length (between 128
> and 512 bits; 256 bits is advised) from a (P)RNG
>
> But BIP39 produces a 64 byte seed:
>
> The length of the derived key is 512 bits (= 64 bytes).
>
> If you don't believe me, why don't you just try it? That seed will
> derive the same keys as that mnemonic, it's a real example.
>
> -
>
> About printing, there is a huge security risk involved in printing
> anything. Networks, printers may have memory. People will print to PDF
> when they don't have a printer on hand. Mobile users often can't print.
>
> I wrote mine down, by hand, generated from an offline computer booted
> with a readonly OS. 
>
> Feel free to produce a recommendation to replace BIP39/32/44 if you
> like, but it's not broken just because someone had trouble using your
> tool/following your instructions. And no offence but I'd be wary using
> a tool from someone who doesn't read the BIPs closely yet is so
> confident about how other people are wrong.
>
>
> On Sat, Jan 6, 2018 at 6:57 AM, Aymeric Vitte  > wrote:
>
> And Alan, btw, a BIP32 seed is 32 bytes, then 64 characters, not 64
> bytes as your wrote below, which probably corresponds to xprv,
> which is
> another misleading element of BIP39
>
>
> Le 06/01/2018 à 02:56, Aymeric Vitte a écrit :
> > The fact is indeed that "we should really find a way to overhaul
> this
> > whole BIP 39 / 43/ 44 etc ad hoc mess"
> >
> > Because the git example I provided is about someone that knows (to a
> > certain extent) what he is doing, then 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

2018-01-05 Thread Aymeric Vitte via bitcoin-dev
No that's not, some parts of the answer might be but this related, this
just shows how people use wrongly BIP39 and subsequent BIPs (and
globally other things), misleading them, while the advantage of using it
is quite dubious compared to backing up a seed, unless you can convince
me of the contrary


Le 05/01/2018 à 19:16, Alan Evans a écrit :
> Sjors, well in Electrum, validation is optional, but English only. As
> for the Ledger-S, that sounds like a Ledger problem.
>
> Aymeric, that is way off topic, did you reply to wrong email?
>
> On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte  > wrote:
>
> See: https://github.com/Ayms/bitcoin-transactions/issues/3
> 
>
> OK, maybe it's my fault, I did not foresee this case, and now it's
> working for p2sh (non segwit)
>
> From my standpoint this just means that BIP39/44 stuff should be
> eradicated (not BIP141 but see what happened...), this is of no
> use, confusing people, doing dangerous things to recover
>
> Really is it easier to save x words instead of a seed? Knowing
> that people are creating several wallets not understanding that
> this is not the purpose of BIP32?
>
> Multisig wallets (like Electrum) have created a big mess too, on
> purpose or no, I don't know, but multisig is for different parties
> involved, not just one
>
>
> Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
>> I don’t know about Electrum but many wallets validate the English words, 
>> which helps in catching typos.
>>
>> Hardware wallets without a full keyboard, like the Ledger Nano S, won’t 
>> even let you freely type characters; you have to select words from a list.
>>
>> So although the standard technically allows what you say, if you use 
>> anything other than 12, 16 or 24 English words, you’ll have fewer wallets to 
>> choose from.
>>
>> I think it’s better to come up with a new standard than trying to patch 
>> BIP-39 at this point, which is why I brought it up.
>>
>> Sjors
>>
>>> Op 5 jan. 2018, om 17:27 heeft Alan Evans  
>>>  het volgende geschreven:
>>>
>>> "Very few wallets support anything other than English"
>>>
>>> By support do you mean allow recovery, validation or generation or all 
>>> three? For if you can freely type a phrase in (such as Electrum), or even 
>>> word by word, then the likely-hood is it is supported if they remembered to 
>>> normalize.
>>>
>>> Seed generation in BIP0039 requires no dictionary what-so-ever! So 
>>> there is no word list to lose in the first place. Your funds are accessible 
>>> with just the characters and the algorithm as described in BIP0039.
>>>
>>> But your proposal is a million miles away from simply adding some 
>>> standard in-language names to some word lists feels like it's derailing the 
>>> OP's simple proposal. Maybe start own email chain about it.
>>>
>>> Alan
>>>
>>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev 
>>> 
>>>  wrote:
>>> I’m not a fan of language specific word lists within the current BIP-39 
>>> standard. Very few wallets support anything other than English, which can 
>>> lead to vendor lock-in and long term loss of funds if a rare non-English 
>>> wallet disappears.
>>>
>>> However, because people can memorize things better in their native 
>>> tongue, supporting multiple languages seems quite useful.
>>>
>>> I would prefer a new standard where words are mapped to integers rather 
>>> than to a literal string. For each language a mapping from words to 
>>> integers would be published. In addition to that, there would be a mapping 
>>> from original language words to matching (in terms of integer value, not 
>>> meaning) English words that people can print on an A4 paper. This would 
>>> allow them to enter a mnemonic into e.g. a hardware wallet that only 
>>> support English. Such lists are more likely to be around 100 years from now 
>>> than some ancient piece of software.
>>>
>>> This would not work with the current BIP-39 (duress) password, but this 
>>> feature could be replaced by appending words (with or without a checksum 
>>> for that addition).
>>>
>>> A replacement for BIP-39 would be a good opportunity to produce a 
>>> better English dictionary as Nic Johnson suggested a while ago:
>>> • all words are 4-8 characters
>>> • all 4-character prefixes are unique (very useful for hardware 
>>> wallets)
>>> • no two words have edit distance < 2
>>>
>>> Wallets need to be able to distinguish between the old and new 
>>> standard, so un-upgraded BIP 39 wallets should consider all new mnemonics 
>>> invalid. At the same time, some new wallets may not wish 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

2018-01-05 Thread Aymeric Vitte via bitcoin-dev
See: https://github.com/Ayms/bitcoin-transactions/issues/3

OK, maybe it's my fault, I did not foresee this case, and now it's
working for p2sh (non segwit)

From my standpoint this just means that BIP39/44 stuff should be
eradicated (not BIP141 but see what happened...), this is of no use,
confusing people, doing dangerous things to recover

Really is it easier to save x words instead of a seed? Knowing that
people are creating several wallets not understanding that this is not
the purpose of BIP32?

Multisig wallets (like Electrum) have created a big mess too, on purpose
or no, I don't know, but multisig is for different parties involved, not
just one


Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
> I don’t know about Electrum but many wallets validate the English words, 
> which helps in catching typos.
>
> Hardware wallets without a full keyboard, like the Ledger Nano S, won’t even 
> let you freely type characters; you have to select words from a list.
>
> So although the standard technically allows what you say, if you use anything 
> other than 12, 16 or 24 English words, you’ll have fewer wallets to choose 
> from.
>
> I think it’s better to come up with a new standard than trying to patch 
> BIP-39 at this point, which is why I brought it up.
>
> Sjors
>
>> Op 5 jan. 2018, om 17:27 heeft Alan Evans  het 
>> volgende geschreven:
>>
>> "Very few wallets support anything other than English"
>>
>> By support do you mean allow recovery, validation or generation or all 
>> three? For if you can freely type a phrase in (such as Electrum), or even 
>> word by word, then the likely-hood is it is supported if they remembered to 
>> normalize.
>>
>> Seed generation in BIP0039 requires no dictionary what-so-ever! So there is 
>> no word list to lose in the first place. Your funds are accessible with just 
>> the characters and the algorithm as described in BIP0039.
>>
>> But your proposal is a million miles away from simply adding some standard 
>> in-language names to some word lists feels like it's derailing the OP's 
>> simple proposal. Maybe start own email chain about it.
>>
>> Alan
>>
>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev 
>>  wrote:
>> I’m not a fan of language specific word lists within the current BIP-39 
>> standard. Very few wallets support anything other than English, which can 
>> lead to vendor lock-in and long term loss of funds if a rare non-English 
>> wallet disappears.
>>
>> However, because people can memorize things better in their native tongue, 
>> supporting multiple languages seems quite useful.
>>
>> I would prefer a new standard where words are mapped to integers rather than 
>> to a literal string. For each language a mapping from words to integers 
>> would be published. In addition to that, there would be a mapping from 
>> original language words to matching (in terms of integer value, not meaning) 
>> English words that people can print on an A4 paper. This would allow them to 
>> enter a mnemonic into e.g. a hardware wallet that only support English. Such 
>> lists are more likely to be around 100 years from now than some ancient 
>> piece of software.
>>
>> This would not work with the current BIP-39 (duress) password, but this 
>> feature could be replaced by appending words (with or without a checksum for 
>> that addition).
>>
>> A replacement for BIP-39 would be a good opportunity to produce a better 
>> English dictionary as Nic Johnson suggested a while ago:
>> • all words are 4-8 characters
>> • all 4-character prefixes are unique (very useful for hardware 
>> wallets)
>> • no two words have edit distance < 2
>>
>> Wallets need to be able to distinguish between the old and new standard, so 
>> un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the 
>> same time, some new wallets may not wish to support BIP39. They shouldn't be 
>> burdened with storing the old word list.
>>
>> A solution is to sort the new word list such that reused words appear first. 
>> When generating a mnemonic, at least one word unique to the new list must be 
>> present. A wallet only needs to know the index of the last BIP39 overlapping 
>> word. They reject a proposed mnemonic if none of the elements use a word 
>> with a higher index.
>>
>> For my above point and some related ideas, see: 
>> https://github.com/satoshilabs/slips/issues/103
>>
>> Sjors
>>
>>> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev 
>>>  het volgende geschreven:
>>>
>>> I propose and request as an enhancement that the BIP 39 wordlist set should 
>>> specify canonical native language strings to identify each wordlist, as 
>>> well as short ASCII language codes.  At present, the languages are 
>>> identified only by their names in English.
>>>
>>> Strings properly vetted and recommended by native speakers should 
>>> 

Re: [bitcoin-dev] BIP for Legacy Sign Verify functions

2017-12-22 Thread Aymeric Vitte via bitcoin-dev
Scriptsig not "sigscript" below

Now you must answer this question, because this is what we call a hard fork


Le 22/12/2017 à 11:29, Aymeric Vitte a écrit :
>
> Le 22/12/2017 à 00:09, Luke Dashjr via bitcoin-dev a écrit :
>> What is actually done, is using the signature + message to perform key 
>> recovery, to extract the public key of the signer, and then hashing that and 
>> comparing it to the address provided.
> I already posted about this, then what is doing the pubkey in sigscript
> for standard p2pkh transactions? (this was not the case some time ago)
>

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

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


Re: [bitcoin-dev] BIP for Legacy Sign Verify functions

2017-12-22 Thread Aymeric Vitte via bitcoin-dev


Le 22/12/2017 à 00:09, Luke Dashjr via bitcoin-dev a écrit :
> What is actually done, is using the signature + message to perform key 
> recovery, to extract the public key of the signer, and then hashing that and 
> comparing it to the address provided.
I already posted about this, then what is doing the pubkey in sigscript
for standard p2pkh transactions? (this was not the case some time ago)

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

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


[bitcoin-dev] pubkey or not pubkey?

2017-11-24 Thread Aymeric Vitte via bitcoin-dev
I released https://github.com/Ayms/bitcoin-transactions

As you can see the restart of this project (started one year ago) was
motivated by the epic launch of bitcoin gold and many people still
desperately trying to sync, not understanding there was no need to
'transfer' their bitcoins to btg, getting robbed, etc, but there is more
some long term intent

This is somewhere bitcoin-cli outside of bitcoin-qt with a non
synced/outside wallet (where https://github.com/Ayms/bitcoin-wallets can
be used), not only for btg but for any network based on bitcoin

While implementing BIP143 I noticed during the tests/doublechecks with
cli that scriptSig was < pubkey>

This was not the case one year ago, scriptSig was  since you
can get the  from the signature, that's what I did thinking of
some lack of optimization in the bgold client, but this behavior is very
the same for bitcoin core

Then my first transactions did not include the pubkey and I was
immediately banned by my own node (who btw did not realize that it was
banning itself...), I got a reject message stating that OP_EQUALVERIFY
failed

So, the questions are: for basic p2pkh transactions why is pubkey back,
since when and why txs without it are rejected?

At this time where everything is made to reduce the tx's size while the
fees/byte are quite high, this adds 34 useless bytes in each input

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

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


Re: [bitcoin-dev] Proposal: allocate Github issue instead of wiki page to BIP discussion

2017-11-03 Thread Aymeric Vitte via bitcoin-dev
+10k

Indeed, as any project Github issues should be enabled for BIPs,
wondering too since some time why this is not the case, and then if an
issue is worth discussing here it can be redirected to the list


Le 03/11/2017 à 10:50, Sjors Provoost via bitcoin-dev a écrit :
> I often find myself wanting to leave relatively small comments on BIP's that 
> are IMO not worth bothering this list.
>
> By default each BIP has a wiki page for discussion, e.g. 
> https://github.com/bitcoin/bips/wiki/Comments:BIP-0150
> This is linked to from the Comments-URI field in the BIP.
>
> In order to leave a comment, you have to edit the wiki page. This process 
> seems a bit clunky.
>
> I think it would be better to use Github issues, with one Github issue for 
> each BIP.
>
> One concern might be that the ease of use of Github issues would move 
> discussion away from this list. The issue could be temporarily locked to 
> prevent that. The issue description could contain a standard text explaining 
> what should be discussed there and what would be more appropriate to post on 
> the mailinglist.
>
> Another concern might be confusing between PR's which create and update a 
> BIP, and the discussion issue.
>
> If people think this a good idea, would the next step be to propose a change 
> to the process here?
> https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_comments
>
> Or would this be a new BIP?
>
> Sjors
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

2017-09-30 Thread Aymeric Vitte via bitcoin-dev
By "all of this" I meant the other issues that I mentioned too "would
everybody even here say that they feel very comfortable with their keys?
That if something happen to them there is no pb for the family or
trusted parties to retrieve the keys? That this process is secured in
case the trusted parties are finally untrusted? etc", I am extending the
problematic while the very basic concerns are still unsolved

Then I don't agree with the fact that users should not have the control
of their keys, but if I try to summarize, your suggestions probably lead
to the fact that the "wallet" part should be outside of bitcoin-qt, in a
simple offline module (assuming that you can trust the simple sw + the
os + the hw +the cpu, but ok, the pb is the same with a hw wallet),
which I think is a good idea

That's why I made a module some time ago, supposed to be "bitcoin
transactions made simple", you do your transactions offline, check them,
and send them to the network via qt, the web or other, it's working but
is not online on github because unfinished, and unfinished because
nothing is simple and it's unlikely that normal people can use this for
now, unfortunately you need to be a bit online to make your transaction,
fetch the output you want to spend or get the info, then associate the
right key, calculate the fees, that's not simple, that's why it's
different from a standard wallet, but probably a good way

Small sw a bit like a credit card finally, and people know they must not
disclose their code(s) in case they are asked on IRC or elsewhere



Le 30/09/2017 à 23:14, Jonas Schnelli via bitcoin-dev a écrit :
>> uhh do you apply this logic to the bitcoin-core wallet itself?
>> because clearly it generates keys and is intended to be used for signing
>> in online environments.  Lots of real-world use-cases depend on that today.
> The current Bitcoin Core wallet setup is not as ideal as it could be.
> An good example is, that the wallet and the full node (the p2p logic on 8333) 
> do share the same process (same memory space).
> AFAIK a lot of users use Core in watch-only mode and do the signing offline 
> (offline / through HWWs).
> Although, Core has currently no direct support for offline signing (expect 
> the rawtx API which are pretty expert-ish).
>
> The Core development process goes into that direction but it takes time due 
> to the strict and extremely important code quality insurance.
>
>> So if existing bitcoin-core wallet behavior is "ok" in any context then
>> how is it any worse for it to generate a key/address that will not be
>> stored in the internal wallet, and the user may do with it as they wish?
>> That is all my proposed RPC call does and unlike the existing RPC calls
>> it never even stores the key or address to disk.  It is also useful when
>> run on an offline hardware device, such as a laptop connected to an
>> non-networked printer.
> IMO we should make it better not worse.
> Paper wallets delude to do address reuse, the spending-procedure is unclear, 
> and very likely insecure.
> A quick photo-snapshot by an attack may result in a full compromised key.
> Printer buffers, etc. are also something to worry here.
>
>> Further, you mention the word trust.  That's the crux of the matter.  As
>> a full node operator, I've already placed my trust in the bitcoin-core
>> developers and dev/release practices.  Why exactly should I trust the
>> software in this minimal offline hardware/os you mention if it is NOT
>> bitcoin core?  And even if open source software, does that not at least
>> double my workload/expense to audit theat software in addition to
>> bitcoin-core?
> I think Bitcoin Core does a great job there. But not sure about other 
> security layers are outside of Core.
> Especially your operating system.
> The reason why we see a growing demand in hardware wallets is probably 
> because people no longer trust in current available operating systems as well 
> as current used desktop/laptop CPUs (like Intel wit it’s MME, etc.).
>
>>> Users should have no way to view or export the private keys (expect for
>>> the seed backup).
>> I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
>> be removed from bitcoin-core to fit this paradigm?
> Yes. That actually something we are considering (especially if we would allow 
> BIP44 or other HD public key derivation forms).
> Also, we heard of "support sessions“ on IRC where attackers told victims they 
> must enter „dumpprivkey“ in the Console and give them the output in order „to 
> fix the problem“.
>
>> (Personally I actively avoid wallet software that takes this view and
>> treat users like children, preventing individuals direct access to the
>> keys for their own funds, which disempowers and sometimes results in a
>> form of lockin)
> I dislike that as well – in general. But I guess most users like 
> self-protection. Also, the user layer is attackable. If _you_ can access the 
> private-keys, an attacker can do also. What 

Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

2017-09-29 Thread Aymeric Vitte via bitcoin-dev
Everybody knows that https is broken and insecure, and everybody knows
that it's still better than nothing

Just reacting here because there is worse: you are quoting Kraken, did
not check for Coinbase but Kraken is proxying all of its https traffic
via Cloudflare, including the API traffic

This is crazy but that's how things are, that's what everybody is doing,
that's what we have

The https principles are obsolete, the concept of certificates tied to a
domain is a complete stupidity, because there are no concept of domains
in bitcoin for example (and webrtc, Tor, bittorrent, p2p systems, etc)
and should evolve to something like certificates tied to an entityID
managed by something like a blockchain system, and not a stupid domain or CA

Therefore specifying things for bitcoin à la web is not a good idea,
browsers can do far better than standard/usual web, and the "like
everybody is doing" argument is not a valid one


Le 29/09/2017 à 15:14, Tomas via bitcoin-dev a écrit :
> On Fri, Sep 29, 2017, at 04:55, Peter Todd via bitcoin-dev wrote:
>> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment
>> qr
>> codes don't cryptographically commit to the identity of the merchant,
>> which
>> means a MITM attacker can redirect the payment if they can obtain a SSL
>> cert
>> that the wallet accepts.
> By that reasoning, we also shouldn't go to https://coinbase.com or
> https://kraken.com to buy any bitcoins? As a MITM can redirect the site
> _if_ they obtain the coinbase or kraken certificate.
>
> Obviously, HTTPS is secured under the assumption that certificates are
> secure.  
>
> Using the payment protocol simply means paying to a secure endpoint (eg
> https://tomasvdw.nl/pay) instead of an address.
>
>>  That wallet is also likely using an off-the-shelf SSL library,
>> with
>> nothing other than an infrequently updated set of root certificates to
>> use to
>> verify the certificate; your browser has access to a whole host of better
>> technologies, such as HSTS pinning, certificate transparency, and
>> frequently
>> updated root certificate lists with proper revocation (see Symantec).
> So we should not use HTTPS for secure transfer because the
> implementation may not be good enough? This incorrectly conflates
> implementation with specification. There is nothing stopping a developer
> from using a proper implementation.
>
>> As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at
>> least
>> supports a h= parameter with a hash commitment to what the payment
>> request
>> should be, and will reject the MITM attacker if that hash doesn't match.
>> But
>> that's not actually in the standard itself, and as far as I can tell has
>> never
>> been made into a BIP.
> Currently it is widely used by merchants, but not yet for light clients
> _receiving_ money. If it becomes more wide spread,   it offers a range
> of advantages as  the bitcoin-address of the URI can and should be
> deprecated (made impossible with "h="). A payment address just becomes a
> secure endpoint.
>
> This means no more address reuse is possible. Also, it drops the need
> for mempool synchronization among non-miners, solely as a "notification"
> mechanism. In addition it means light clients know exactly when a
> transaction is coming in, so they can efficiently rely on client-side
> filtering a small set of blocks, improving their privacy.
>
> In my opinion, the payment protocol is key to scaling.
>
>> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP
>> made
>> to replace it.
> Sorry, but maybe you  could explain better how secure communication over
> HTTPS is "very dangerous"? I think some websites would like to know :)
>
> Tomas van der Wansem
> bitcrust
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] A Segwit2x BIP

2017-07-12 Thread Aymeric Vitte via bitcoin-dev


Le 12/07/2017 à 03:06, Luke Dashjr via bitcoin-dev a écrit :
> Even with Core's support, many people would oppose the hardfork 
> attempt, and it would fail.

Why with or without Core support are you sure that it will fail, what
can those that are opposing the hardfork attempt do (with or without
Core) and what does "fail" mean here in fact?

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

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


Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits

2017-05-11 Thread Aymeric Vitte via bitcoin-dev
Sorry again, is this discussion really serious?

In this thread, previous ones or others, the level of approximation is
obvious, often shadowed by useless maths/papers and strange calculations
that are not helping, at the end nobody knows what would happen "if",
how far the chain can roll back, etc

Then don't make pruning the default if it's the current concern, pruning
is of no use

Again, the priority should be to scale the full nodes


Le 11/05/2017 à 22:10, Jonas Schnelli via bitcoin-dev a écrit :
>> Is 49 days particularly useful? Would it be a problem to instead leave both-
>> bits undefined? I'm thinking this might be better as a way to indicate "7
>> days, plus a deterministically chosen set of historical blocks"…
> I though two service bits allow three states and we should define all three 
> combinations.
> But I guess an adequate „definition“ would be to reserve it for future 
> „definitions“.
> Or use Gregory's proposal of min 2016*2 blocks & keep it „undefined“ for now.
>
> 49 days was chosen to allow SPV peers to be „offline“ for a month and still 
> be capable to catch-up with a peer pruned to a datadir of ~10GB.
>
>> This is technically true right now, but as soon as segwit activates, it will
>> no longer be... Therefore, I suggest striking it from the BIP, expounding on
>> it in greater detail, or making it true for the longer term.
> AFAIK Core does also guaranteed the 288 blocks post segwit activation:
> https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/validation.h#L204
> But maybe I’m confused.
>
>>> Peers following this BIP SHOULD connect a limited amount of their available
>>> outbound connections to peers signaling one or both of the
>>> NODE_NETWORK_LIMITED_* service bits if they expect to request less blocks
>>> than the signaled number.
>> This isn't entirely clear whether it refers to peers downloading blocks, or
>> peers serving them. (I assume the former, but it should be clarified.)
> Indeed. I’ll try to make that more clear.
>
>>> Light clients (and such) who are not checking the nServiceFlags (service
>>> bits) from a relayed addr-message may unwillingly connect to a pruned peer
>>> and ask for (filtered) blocks at a depth below their pruned depth.
>> Wouldn't this already be a problem, without the BIP?
> AFAIK, Core does currently only relay NODE_NETWORK addresses.
> But yes, It may be a problem already.
>
> 
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Full node "tip" function

2017-05-04 Thread Aymeric Vitte via bitcoin-dev
Yes, as a whole, but I am sorry, your "tip" proposal is very very very
bad as it is, think a little bit more about your latest answer and you
will understand why

I am a bit perplexed sometimes about what is proposed on this list

Adding services paid by the miners is not a bad idea, like some
proposals that were posted here proposing some system to validate/format
the blocks for the miners

But, first, the highest priority is to scale the full nodes and this
cannot depend on miners, then once this is done we can imagine other
services on top of it paid by the miners or others (+lightning & co)

I have already explained many times my thoughts on the subject, I don't
pretend that they represent the perfect solution but at least it's
different from what we can read , so I think that the core dev team
should setup a task force/group to solve this quickly now, the
accumulation of strange proposals/workarounds here does not help

Because it's a real question for everybody in the current context
whether we can trust bitcoin or not, unfortunately the answer currently
tends toward the later, or please explain me why this statement could be
wrong


Le 04/05/2017 à 15:47, Erik Aronesty a écrit :
>  - Full nodes already perform many valuable services, and simply
> allowing people to pay for better service is something operators can
> do now - even without it being baked into bitcoind.   Paying for
> access to a higher-speed relay network, for example, is something that
> many operators would do.
>
> - Baking in the ability to add service fees could make more people
> *want* to run more high quality, highly available full nodes... which
> is really one of the most important things developers can be doing.
>
>
> On Thu, May 4, 2017 at 9:37 AM, Aymeric Vitte via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> Strange idea, incentiving people to run full nodes should
> certainly not depend on miners, should certainly not involve
> another wasteful pow and should certainly not encourage any
> collusion between participants like miners are doing (ie full
> nodes pools for example or miners creating full nodes pools)
>
>
> Le 04/05/2017 à 12:38, Tomas via bitcoin-dev a écrit :
>> The ones that *could* pay non-mining full nodes are miners/pools,
>> by outsourcing transaction selection using a different PoW.  By
>> doing so they could buy proof-of-uncensored-selection and
>> proof-of-goodwill for a small fee.
>>
>> We would allow full nodes to generate and broadcast a template
>> block which:
>>
>> * Does not contain a valid header yet
>> * Contains the transaction selection
>> * Contains a coinbase output with a predetermined part of the
>> block reward (say 0.5%) to themselves
>> * Contains a nonce for PoW of a predetermined currently ASIC
>> resistant hash function behind a OP_RETURN.
>>
>> The template with the highest PoW since the last block would be
>> leading. A miner/pool can then choose to use this instead of
>> their own, adding the rest of the reward and the SHA nonce
>> themselves. That way they would set up a competition among full
>> nodes.
>>
>> This would of course be voluntary but provable, so maybe in a
>> pool's interest to do this via naming and shaming.
>>
>> Tomas
>> bitcrust
>>
>> On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote:
>>> I feel like this would be pointless as the vast majority of
>>> users would likely download the blockchain from a node that was
>>> not enforcing a tip requirement as it would seem like
>>> unnecessary cost as in protocols such as BitTorrent there is no
>>> such tips in sharing files and the blockchain distribution is in
>>> eccense the same thing. However perhaps I am underestimating the
>>> generosity of node operators but I feel that adding a cost to
>>> the blockchain (assuming that all users add a tip requirement)
>>> would lead to centralisation.
>>>
>>> On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev,
>>> <bitcoin-dev@lists.linuxfoundation.org
>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>>
>>> IDEA:
>>> - Full nodes advertise a bitcoin address.   Users that need
>>> to download the block chain from that node can be encouraged
>>> to send a tip to the peers that served them (by % served).  
>>> Recommended tip of 10mbit

Re: [bitcoin-dev] Full node "tip" function

2017-05-04 Thread Aymeric Vitte via bitcoin-dev
Strange idea, incentiving people to run full nodes should certainly not
depend on miners, should certainly not involve another wasteful pow and
should certainly not encourage any collusion between participants like
miners are doing (ie full nodes pools for example or miners creating
full nodes pools)


Le 04/05/2017 à 12:38, Tomas via bitcoin-dev a écrit :
> The ones that *could* pay non-mining full nodes are miners/pools, by
> outsourcing transaction selection using a different PoW.  By doing so
> they could buy proof-of-uncensored-selection and proof-of-goodwill for
> a small fee.
>
> We would allow full nodes to generate and broadcast a template block
> which:
>
> * Does not contain a valid header yet
> * Contains the transaction selection
> * Contains a coinbase output with a predetermined part of the block
> reward (say 0.5%) to themselves
> * Contains a nonce for PoW of a predetermined currently ASIC resistant
> hash function behind a OP_RETURN.
>
> The template with the highest PoW since the last block would be
> leading. A miner/pool can then choose to use this instead of their
> own, adding the rest of the reward and the SHA nonce themselves. That
> way they would set up a competition among full nodes.
>
> This would of course be voluntary but provable, so maybe in a pool's
> interest to do this via naming and shaming.
>
> Tomas
> bitcrust
>
> On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote:
>> I feel like this would be pointless as the vast majority of users
>> would likely download the blockchain from a node that was not
>> enforcing a tip requirement as it would seem like unnecessary cost as
>> in protocols such as BitTorrent there is no such tips in sharing
>> files and the blockchain distribution is in eccense the same thing.
>> However perhaps I am underestimating the generosity of node operators
>> but I feel that adding a cost to the blockchain (assuming that all
>> users add a tip requirement) would lead to centralisation.
>>
>> On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev,
>> > > wrote:
>>
>> IDEA:
>> - Full nodes advertise a bitcoin address.   Users that need to
>> download the block chain from that node can be encouraged to send
>> a tip to the peers that served them (by % served).   Recommended
>> tip of 10mbit should be fine.
>>
>> - A full nodes can *require* a tip to download the blockchain. 
>> If they do, users that don't specify a tip cannot use them.
>>
>> CONS:
>>
>> For some people, this may represent a barrier to hosting their
>> own full node.   After all, if you have to pay $15 just to get a
>> copy of the blockchain, that just adds to the already expensive
>> prospect of hosting a full node.  
>> PROS:
>>
>> As long as you manage to stay online, you should get your money
>> back and more.   This is the an incentive for quality, long term
>> hosting.
>> In the long term, this should cause stable nodes to stick around
>> longer.   It also discourages "installation spam" attacks on the
>> network.
>> Fees for other node operations can be considered if this is
>> successful.
>>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-05-03 Thread Aymeric Vitte via bitcoin-dev


Le 03/05/2017 à 21:10, Natanael via bitcoin-dev a écrit :
>
> Den 3 maj 2017 16:05 skrev "Erik Aronesty via bitcoin-dev"
>  >:
>
> > But as you've observed, the failure probabilities are rather high,
> > especially if an active attacker targets nodes carrying less
> commonly
> > available blocks. 
>
> Wouldn't the solution be for nodes to use whatever mechanism an
> attacker uses to determine less commonly available blocks and
> choose to store a random percentage of them as well as their
> deterministic random set? 
>
> IE X blocks end of chain (spv bootstrap), Y% deterministic random
> set,  Z% patch/fill set to deter attacks
>
>
> Then he uses Sybil attacks to obscure what's actually rare and not.

> Even proof of storage isn't enough,you need proof of INDEPENDENT storage

Yes

> , which is essentially impossible

No, the bittorrent network is a good example

> , as well as a way of determining which nodes are run by the same
> people (all the AWS nodes should essentially count as one).

No, this one is impossible and you don't care in fact, as long as the
system forbids the nodes to position themselves where they like and can
check that the nodes are behaving correctly, same people's nodes/IPs
would then just do the job

And if you add to this a rewarding system that is not necessarily
profitable then you eliminate the incentive for sybil attacking the
network (like the "tip" proposal today) while motivating those that have
the resources to run full nodes, then increasing independence


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

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

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


Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-23 Thread Aymeric Vitte via bitcoin-dev
"Absolutely, I assume if Vorick's proposal were implemented that nodes
would have the follow options: Pruned [UTXO + recent two weeks of
blocks], 20%, 40%, 60%, 80%, 100% (archive)."

Yes, and I think that they can have this in "disorder" (only 20% of
blocks in the middle of the blockchain for example)

There are many reasons why I dislike David's proposal as it is, you
mention some below, why 20%? too much? too small? what will happen
tomorrow? etc, I gave others, and this still does not explain why people
should go for more than two weeks of blocks

Maybe what I suggested here again
https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf#proposal
could be considered

This is just a suggestion based on incremental "torrents", fortunately
it comes from much more than days of work as you require below and is
the concatenation of thoughts from different projects/studies

It does follow your 8 rules (although I am not sure what you mean in
rule 2 "The decision to contact a node should need O(1) communications",
1 M limit works?) and proposes others, and it solves the issues
mentioned below, or please someone tell me why it does not (I know
people here dislike DHTs, not sure why)

Except fingerprinting (and I don't know what is the SPV issue exactly)
but still is better, if the nodes behave like the groups with most
numerous peers (ie the group seeding, 20%, or the one seeding 40%, or
the one seeding about nothing (sic... subliminal message here...), etc)
then they just can't be fingerprinted (at least based on this feature)

I think the main concepts are detailed enough but maybe that's not the
case, it's a really draft, if you look well the pruning case is
considered, but not explained, like some other points, because
continuing this work with no incentive solution for the seeders looks to
me useless


Le 21/04/2017 à 22:38, Gregory Maxwell via bitcoin-dev a écrit :
> On Mon, Apr 17, 2017 at 6:54 AM, David Vorick via bitcoin-dev
>  wrote:
>> Rationale:
>>
>> A node that stores the full blockchain (I will use the term archival node)
>> requires over 100GB of disk space, which I believe is one of the most
>> significant barriers to more people running full nodes. And I believe the
>> ecosystem would benefit substantially if more users were running full nodes.
> Hi David,
>
> I've been thinking about this subject for a long time (Tier Nolan
> linked some of the threads; see also the coloration part of
> https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding) and
> about using FEC with the history for the last year or so. (we use FEC
> in practice in fibre for relay at the tip now, and that has a design
> history going back to 2013).
>
> As Jonas points out, we're all set to also offer the 'recent blocks'
> separately, so that is obviously going to happen and will help. The
> free design parameter is the definition of recent, but we have good
> measurements for setting that now. But about history...
>
> I think I might have designed myself into a corner and perhaps you've
> shown a way out-- I think there are some serious limits in your
> proposal but perhaps we can fix them.  Let me give you what I had been
> thinking about, then hand you at least a couple improvements to your
> thinking:
>
> As you hopefully now know (per Tier Nolan's) post: I'd previously been
> thinking about nodes keeping a deterministic random, independently
> selected subset which is self-leveling based on a small seed.   The
> connection overhead can can be mitigated by working with chunks of
> blocks rather than single blocks.
>
> But as you've observed, the failure probabilities are rather high,
> especially if an active attacker targets nodes carrying less commonly
> available blocks.  So I thought, okay we can use FEC to help improve
> the recovery odds.
>
> So I considered using a sparse random code (E.g. an LDPC erasure code
> like in RFC 5170) the advantage of these codes is that they are very
> fast to decode, and they support having enormous codewords, so you can
> a high probability of every peer having a unique ID, so there would
> effectively never need to be any duplication.
>
> But then I ran into the problem that I had no reasonable way to
> recover from bad data, short of pulling a single group from an archive
> then banning whatever peers gave you bad chunks.
>
> So that is kind of where I got stuck.
>
> I didn't even consider the advantage of only being able to use a few
> peers total, as I still assumed that it would be doing the random
> groups thing as well. That's a great point.
>
> So on your design:
>
> Being able to have a lower bound of 20% seems like a serious
> limitation to me: it would be fine today, but the chain will quite
> possibly be twice the current size in a year and in four years
> we're back to where we are now. What I'd been thinking would be able
> to scale arbitrarily low.
>
> 20% is small, but is it small enough? -- today that would get 

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-20 Thread Aymeric Vitte via bitcoin-dev
??? what do you mean? (https://www.soyoustart.com/fr/serveurs-essential/)


Le 20/04/2017 à 17:50, Erik Aronesty via bitcoin-dev a écrit :
> Try to find 1TB dedicated server hosting ...
>
> If you want to set up an ecommerce site somewhere besides your living
> room, storage costs are still a concern.
>
> On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe via bitcoin-dev
>  > wrote:
>
> 1TB HDD is now available for under $40 USD.  How is the 100GB
> storage requirement preventing anyone from setting up full nodes?
>
> On Apr 16, 2017 11:55 PM, "David Vorick via bitcoin-dev"
>  > wrote:
>
> *Rationale:*
>
> A node that stores the full blockchain (I will use the term
> archival node) requires over 100GB of disk space, which I
> believe is one of the most significant barriers to more people
> running full nodes. And I believe the ecosystem would benefit
> substantially if more users were running full nodes.
>
> The best alternative today to storing the full blockchain is
> to run a pruned node, which keeps only the UTXO set and throws
> away already verified blocks. The operator of the pruned node
> is able to enjoy the full security benefits of a full node,
> but is essentially leeching the network, as they performed a
> large download likely without contributing anything back.
>
> This puts more pressure on the archival nodes, as the archival
> nodes need to pick up the slack and help new nodes bootstrap
> to the network. As the pressure on archival nodes grows, fewer
> people will be able to actually run archival nodes, and the
> situation will degrade. The situation would likely become
> problematic quickly if bitcoin-core were to ship with the
> defaults set to a pruned node.
>
> Even further, the people most likely to care about saving
> 100GB of disk space are also the people least likely to care
> about some extra bandwidth usage. For datacenter nodes, and
> for nodes doing lots of bandwidth, the bandwidth is usually
> the biggest cost of running the node. For home users however,
> as long as they stay under their bandwidth cap, the bandwidth
> is actually free. Ideally, new nodes would be able to
> bootstrap from nodes that do not have to pay for their
> bandwidth, instead of needing to rely on a decreasing
> percentage of heavy-duty archival nodes.
>
> I have (perhaps incorrectly) identified disk space consumption
> as the most significant factor in your average user choosing
> to run a pruned node or a lite client instead of a full node.
> The average user is not typically too worried about bandwidth,
> and is also not typically too worried about initial blockchain
> download time. But the 100GB hit to your disk space can be a
> huge psychological factor, especially if your hard drive only
> has 500GB available in the first place, and 250+ GB is already
> consumed by other files you have.
>
> I believe that improving the disk usage situation would
> greatly benefit decentralization, especially if it could be
> done without putting pressure on archival nodes.
>
> *Small Nodes Proposal:*
>
> I propose an alternative to the pruned node that does not put
> undue pressure on archival nodes, and would be acceptable and
> non-risky to ship as a default in bitcoin-core. For lack of a
> better name, I'll call this new type of node a 'small node'.
> The intention is that bitcoin-core would eventually ship
> 'small nodes' by default, such that the expected amount of
> disk consumption drops from today's 100+ GB to less than 30 GB.
>
> My alternative proposal has the following properties:
>
> + Full nodes only need to store ~20% of the blockchain
> + With very high probability, a new node will be able to
> recover the entire blockchain by connecting to 6 random small
> node peers.
> + An attacker that can eliminate a chosen+ 95% of the full
> nodes running today will be unable to prevent new nodes from
> downloading the full blockchain, even if the attacker is also
> able to eliminate all archival nodes. (assuming all nodes
> today were small nodes instead of archival nodes)
>
> Method:
>
> A small node will pick an index [5, 256). This index is that
> node's permanent index. When storing a block, instead of
> storing the full block, the node will use Reed-Solomon coding
> to erasure code the block using a 5-of-256 scheme. 

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-20 Thread Aymeric Vitte via bitcoin-dev
Thanks but you did not answer all the points and some of your statements
look wrong, like the global ideas behind this proposal from my
standpoint, which basically is inventing strange things not reusing what
is already proven to be working well and could provide the same result,
which at the end is not the expected one, ie increasing full nodes, it
sounds like a strange workaround to prevent the centralization of the
blockchain when pruning will become the default

To answer some other comments in this thread, giving an incentive to run
full nodes does not mean that someone setting up tomorrow 10K nodes will
become rich and/or will be able to control the network, the later being
not unlikely at all to happen in the current situation, the idea is more
to motivate people that already have the resources to run full nodes,
then we mix the concepts of optimizing the resources at no additional
costs (and even decreasing costs since you get rewarded for the part
that you have already paid but don't use) with the one of running nodes
to protect its business

For example
https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf#proposal
is showing some concepts where nodes can't position themselves where
they like and are registered in the system by the others (but forget the
proof of something as written in this gist since I think the rewards
should not depend on usual miners) , so it becomes quite difficult that
they position themselves where they like to possibly get the rewards,
fake the system, freeride, cheat, collude in pools or setup plenty of nodes

Comments below


Le 19/04/2017 à 19:30, David Vorick via bitcoin-dev a écrit :
> On Tue, Apr 18, 2017 at 3:43 AM, Jonas Schnelli <d...@jonasschnelli.ch
> <mailto:d...@jonasschnelli.ch>> wrote:
>
> I know many torrent clients, and clients for protocols like Tor
> and i2p include the ability to set both speed limits and monthly
> bandwidth limits.
>

Yes, that's the easy part, the issue is more for the network to check
that users have sufficient bandwidth and don't cheat

> I worry about any type of CDN being a central point of failure.

Of course

>  Torrenting typically relies on a DHT, which is much easier to attack
> than Bitcoin's peer network.

Then please explain how you would attack the bittorrent DHT and why it's
"much easier" than attacking the btc network today, bittorrent is not
designed for security/privacy, including its DHT, which btw is great,
it's a common sign of misinformation to conclude that all DHTs are
necessarily insecure

> I think the bitcoin p2p network is by significant margin the best
> we've got.

The btc network can't be considered as a p2p network in its current form
then can't be the best one for now (and if it was then we would not be
in today's situation)

>
> Yes, there is finger-print that happens if you have nodes pick an
> index. And the fingerprint gets a lot worse if you have a node pick
> multiple indexes.

This is another problem of your proposal, as well as
fingerprinting/tracking peers based on what they have

> Though, isn't it already required that nodes have some sort of IP
> address or hidden service domain? I want to say that the fingerprint
> created by picking an index is not a big deal, because it can be
> separated from activity like transaction relaying and mining. Though,
> I am not certain and perhaps it is a problem.

Are you suggesting that the btc "p2p" network should be using the Tor
network, and especially the nodes hosting the/(a part of) the
blockchain? This is of course a very bad idea and you would not
eliminate the tracking issue, a simple example is that despite ot the
size of the network it's not difficult to track the peers on the
bittorrent network, you might not know who is the peer but you can
follow whatever he is doing, and hidding behind Tor or a VPN does not
prevent this

>
>
>
> On Mon, Apr 17, 2017 at 6:14 AM, Aymeric Vitte via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> While I fully agree with the intent (increasing full nodes so a
> big miner waking up in a bad mood can't threaten the world any
> longer every day as it is now) I am not sure to get the interest
> of this proposal, because:
>
> - it's probably not a good idea to encourage the home users to run
> full nodes, there are many people running servers far from their
> capacity that could easily run efficient full nodes
>
> Running a full node is the only way to avoid needing to trust others.
> It's also how you make your opinion worthwhile for events like hard
> forks and UASFs. If decentralization is the primary motivation, it
> absolutely makes sense to encourage people to run their own full
> nodes. Without a full node, you are at the merc

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-18 Thread Aymeric Vitte via bitcoin-dev
>From the initial post " The situation would likely become problematic
quickly if bitcoin-core were to ship with the defaults set to a pruned
node."

Sorry to be straight, I read the (painful) thread below, and most of
what is in there is inept, wrong, obsolete... or biased, cf the first
sentence above, if the idea is to invent a workaround to the fact that
pruning might/will become the default or might/will be set by the users
as the default so full nodes might/will disappear then just say it
clearly instead of proposing this kind of non-solution as a solution to
secure the blockchain

I can't believe this is serious, people now are supposed to prune but
will be forced to host a part of the blockchain, how do you expect this
to work, why people would do this? Knowing that to start pruning they
need a full node, then since we are there, why not continuing with a
full node... but indeed, why should they continue with a full node, and
therefore why should they accept to host a part of the blockchain if
they decline the first proposal?

This is absurd, you are not addressing the first priority given the
context which is to quickly increase the full nodes and which obviously
includes an incentive for people to run them

It gives also the feeling that bitcoin wants to reinvent everything not
capitalizing on/knowing what exists, sorry again but the concepts of the
proposal and others like archival nodes are just funny


Le 18/04/2017 à 15:07, Tier Nolan via bitcoin-dev a écrit :
> This has been discussed before.
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html
>
> including a list of nice to have features by Maxwell
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html
>
> You meet most of these rules, though you do have to download blocks
> from multiple peers.
>
> The suggestion in that thread were for a way to compactly indicate
> which blocks a node has.  Each node would then store a sub-set of all
> the blocks.  You just download the blocks you want from the node that
> has them.
>
> Each node would be recommended to store the last few days worth anyway.
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-17 Thread Aymeric Vitte via bitcoin-dev
While I fully agree with the intent (increasing full nodes so a big
miner waking up in a bad mood can't threaten the world any longer every
day as it is now) I am not sure to get the interest of this proposal,
because:

- it's probably not a good idea to encourage the home users to run full
nodes, there are many people running servers far from their capacity
that could easily run efficient full nodes

- if someone can't allocate 100 GB today to run a full node, then we
can't expect him to allocate more in the future

- the download time is a real concern

- this proposal is a kind of reinventing torrents, while limiting the
number of connections to something not efficient at all, I don't see why
something that is proven to be super efficient (torrents) would be
needed to be reinvented, I am not saying that it should be used as the
bittorrent network is doing but the concepts can be reused

- I don't get at all the concept of "archival" nodes since it's another
useless step toward centralization

I think the only way to increase full nodes it to design an incentive
for people to run them


Le 17/04/2017 à 08:54, David Vorick via bitcoin-dev a écrit :
> *Rationale:*
>
> A node that stores the full blockchain (I will use the term archival
> node) requires over 100GB of disk space, which I believe is one of the
> most significant barriers to more people running full nodes. And I
> believe the ecosystem would benefit substantially if more users were
> running full nodes.
>
> The best alternative today to storing the full blockchain is to run a
> pruned node, which keeps only the UTXO set and throws away already
> verified blocks. The operator of the pruned node is able to enjoy the
> full security benefits of a full node, but is essentially leeching the
> network, as they performed a large download likely without
> contributing anything back.
>
> This puts more pressure on the archival nodes, as the archival nodes
> need to pick up the slack and help new nodes bootstrap to the network.
> As the pressure on archival nodes grows, fewer people will be able to
> actually run archival nodes, and the situation will degrade. The
> situation would likely become problematic quickly if bitcoin-core were
> to ship with the defaults set to a pruned node.
>
> Even further, the people most likely to care about saving 100GB of
> disk space are also the people least likely to care about some extra
> bandwidth usage. For datacenter nodes, and for nodes doing lots of
> bandwidth, the bandwidth is usually the biggest cost of running the
> node. For home users however, as long as they stay under their
> bandwidth cap, the bandwidth is actually free. Ideally, new nodes
> would be able to bootstrap from nodes that do not have to pay for
> their bandwidth, instead of needing to rely on a decreasing percentage
> of heavy-duty archival nodes.
>
> I have (perhaps incorrectly) identified disk space consumption as the
> most significant factor in your average user choosing to run a pruned
> node or a lite client instead of a full node. The average user is not
> typically too worried about bandwidth, and is also not typically too
> worried about initial blockchain download time. But the 100GB hit to
> your disk space can be a huge psychological factor, especially if your
> hard drive only has 500GB available in the first place, and 250+ GB is
> already consumed by other files you have.
>
> I believe that improving the disk usage situation would greatly
> benefit decentralization, especially if it could be done without
> putting pressure on archival nodes.
>
> *Small Nodes Proposal:*
>
> I propose an alternative to the pruned node that does not put undue
> pressure on archival nodes, and would be acceptable and non-risky to
> ship as a default in bitcoin-core. For lack of a better name, I'll
> call this new type of node a 'small node'. The intention is that
> bitcoin-core would eventually ship 'small nodes' by default, such that
> the expected amount of disk consumption drops from today's 100+ GB to
> less than 30 GB.
>
> My alternative proposal has the following properties:
>
> + Full nodes only need to store ~20% of the blockchain
> + With very high probability, a new node will be able to recover the
> entire blockchain by connecting to 6 random small node peers.
> + An attacker that can eliminate a chosen+ 95% of the full nodes
> running today will be unable to prevent new nodes from downloading the
> full blockchain, even if the attacker is also able to eliminate all
> archival nodes. (assuming all nodes today were small nodes instead of
> archival nodes)
>
> Method:
>
> A small node will pick an index [5, 256). This index is that node's
> permanent index. When storing a block, instead of storing the full
> block, the node will use Reed-Solomon coding to erasure code the block
> using a 5-of-256 scheme. The result will be 256 pieces that are 20% of
> the size of the block each. The node picks the piece that corresponds
> to its index, 

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

2017-04-06 Thread Aymeric Vitte via bitcoin-dev
Not sure to get how you are answering the question

>  If the original blockchain hard-forks to re-adjust the difficulty,
then it will just represent an alt-coin having 5% of Bitcoin community,
and it can't affect Bitcoin (the segwit2mb fork).

destroys the whole thing

Because if the nodes don't upgrade and just implement the patch to
adjust the difficulty, what happens? You get a 95% mining power chain
with "no" nodes and a 5% one with "all" the nodes

I really don't get in all those discussions why the nodes are always
disconsidered compared to the miners, ie why they seem to be of zero
importance and are supposed to obey whatever you ask them

And apparently the trend is not going to revert if we look at the
priority features sent in the asicboost thread where motivating and
scaling full nodes is still something you need very powerful glasses to
see coming


Le 06/04/2017 à 22:42, Sergio Demian Lerner via bitcoin-dev a écrit :
> The 95% miner signaling is important to prevent two Bitcoin forks,
> such as what happened with Ethereum HF and Ethereum Classic.
>
> Bitcoin has a very slow difficulty re-targeting algorithm. A fork that
> has just 95% miner support will initially (for 2016 blocks) be 5%
> slower (an average block every 10 minutes and 30 seconds). The
> transaction capacity of the new Bitcoin protocol is reduced only 5%. 
> However the chain with 5% if the hashing power not only has a 20x
> capacity reduction, but confirms transactions in 20x more time. So the
> mempool will grow 400 times. It must be noted that fees increased 10x
> from the moment blocks were half full, to the moment blocks became
> saturated. I'm sure no Bitcoin (pre-fork) user will be willing to pay
> 100x times the transaction fees to use such a slow and insecure network.
>
> So a 6-block confirmation will take 20 hours in the original chain and
> the original chain will be in this almost useless slow state for an
> average of 2016 blocks, or 280 days. 
> If the original blockchain hard-forks to re-adjust the difficulty,
> then it will just represent an alt-coin having 5% of Bitcoin
> community, and it can't affect Bitcoin (the segwit2mb fork).
>
>
> On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak  > wrote:
>
> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via
> bitcoin-dev  > wrote:
>
> The hard-fork is conditional to 95% of the hashing power has
> approved the segwit2mb soft-fork and the segwit soft-fork has
> been activated (which should occur 2016 blocks after its
> lock-in time)
>
>
> Miners signalling they have upgraded by flipping a bit in the
> nVersion field has little relevance in a hard fork. If 100% of the
> hash power indicates they are running this proposal, but the nodes
> don't upgrade, what will happen?
>
> For the record, I actually talk a lot about hard forks with
> various developers and am very interested in the research that
> Johnson in particular is pioneering. However, I have failed to
> understand your point about 95% miner signalling in relation to a
> hard fork, so I am eagerly awaiting your explanation.
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Hard fork proposal from last week's meeting

2017-03-29 Thread Aymeric Vitte via bitcoin-dev
I have heard such theory before, it's a complete mistake to think that
others would run full nodes to protect their business and then yours,
unless it is proven that they are decentralized and independent

Running a full node is trivial and not expensive for people who know how
to do it, even with much bigger blocks, assuming that the full nodes are
still decentralized and that they don't have to fight against big nodes
who would attract the traffic first

I have posted many times here a small proposal, that exactly describes
what is going on now, yes miners are nodes too... it's disturbing to see
that despite of Tera bytes of BIPs, papers, etc the current situation is
happening and that all the supposed decentralized system is biased by
centralization

Do we know what majority controls the 6000 full nodes?


Le 29/03/2017 à 22:32, Jared Lee Richardson via bitcoin-dev a écrit :
> > Perhaps you are fortunate to have a home computer that has more than
> a single 512GB SSD. Lots of consumer hardware has that little storage.
>
> That's very poor logic, sorry.  Restricted-space SSD's are not a
> cost-effective hardware option for running a node.  Keeping blocksizes
> small has significant other costs for everyone.  Comparing the cost of
> running a node under arbitrary conditons A, B, or C when there are far
> more efficient options than any of those is a very bad way to think
> about the costs of running a node.  You basically have to ignore the
> significant consequences of keeping blocks small.
>
> If node operational costs rose to the point where an entire wide swath
> of users that we do actually need for security purposes could not
> justify running a node, that's something important for consideration. 
> For me, that translates to modern hardware that's relatively well
> aligned with the needs of running a node - perhaps budget hardware,
> but still modern - and above-average bandwidth caps.
>
> You're free to disagree, but your example only makes sense to me if
> blocksize caps didn't have serious consequences.  Even if those
> consequences are just the threat of a contentious fork by people who
> are mislead about the real consequences, that threat is still a
> consequence itself.
>
> On Wed, Mar 29, 2017 at 9:18 AM, David Vorick via bitcoin-dev
>  > wrote:
>
> Perhaps you are fortunate to have a home computer that has more
> than a single 512GB SSD. Lots of consumer hardware has that little
> storage. Throw on top of it standard consumer usage, and you're
> often left with less than 200 GB of free space. Bitcoin consumes
> more than half of that, which feels very expensive, especially if
> it motivates you to buy another drive.
>
> I have talked to several people who cite this as the primary
> reason that they are reluctant to join the full node club.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Hard fork proposal from last week's meeting

2017-03-29 Thread Aymeric Vitte via bitcoin-dev
Well it's not going off-topic since the btc folks need now to find a way
to counter the attack

The disk space story is know to be a non issue, because encouraging
people to run nodes while they don't know how to dedicate the right
storage space that is trivial and not expensive to get today is just
stupid, they should not try to run full nodes, and no I tested with non
SSD drives, I was more wondering about cpu and bandwidth use, but did
not notice any impact, just stopped because a repeated sw bug or drive
issue desynched the chain and bitcoin-qt was trying to reload it from
the begining each time, which in my case was taking 10 days despite of
good bandwidth (which would allow me to torrent the entire chain + state
in less than 20 hours), so I stopped after the 3rd crash, setting up a
full node on my servers is still in the todo list (very low priority for
the reasons already explained)

Running a prune node implies first to setup a full node, so the same
problematic applies and then the advantage of pruning is not really
obvious, I don't know what's the strange story about "archival nodes", I
proposed something else

Back to the topic, the conclusion is that this is not difficult at all
for many people to run efficient full nodes, ideally the community
should promote this, seed a torrent with a recent state, implement a
patch to defeat BU plans and have everybody upgrade

But of course this will not happen


Le 29/03/2017 à 18:41, Andrew Johnson a écrit :
> I believe that as we continue to add users to the system by scaling
> capacity that we will see more new nodes appear, but I'm at a bit of a
> loss as to how to empirically prove it. 
>
> I do see your point on increasing load on archival nodes, but the
> majority of that load is going to come from new nodes coming online,
> they're the only ones going after very old blocks.   I could see that
> as a potential attack vector, overwhelm the archival nodes by spinning
> up new nodes constantly, therefore making it difficult for a "real"
> new node to get up to speed in a reasonable amount of time. 
>
> Perhaps the answer there would be a way to pay an archival node a
> small amount of bitcoin in order to retrieve blocks older than a
> certain cutoff?  Include an IP address for the node asking for the
> data as metadata in the transaction...  Archival nodes could set and
> publish their own policy, let the market decide what those older
> blocks are worth.  Would also help to incentivize running archival
> node, which we do need.  Of course, this isn't very user friendly. 
>
> We can take this to bitcoin-discuss, if we're getting too far off topic.
>
>
> On Wed, Mar 29, 2017 at 11:25 AM David Vorick  > wrote:
>
>
> On Mar 29, 2017 12:20 PM, "Andrew Johnson"
> >
> wrote:
>
> What's stopping these users from running a pruned node?  Not
> every node needs to store a complete copy of the blockchain. 
>
>
> Pruned nodes are not the default configuration, if it was the
> default configuration then I think you would see far more users
> running a pruned node.
>
> But that would also substantially increase the burden on archive
> nodes.
>
>
> Further discussion about disk space requirements should be taken
> to another thread.
>
>
> -- 
> Andrew Johnson
>

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

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


Re: [bitcoin-dev] Hard fork proposal from last week's meeting

2017-03-29 Thread Aymeric Vitte via bitcoin-dev


Le 29/03/2017 à 17:57, David Vorick via bitcoin-dev a écrit :
> It's too expensive for a home user to run a full node, and user-run
> full nodes are what provide the strongest defence against political
> manuveuring.

Yes but what makes you think that "It's too expensive for a home user to
run a full node" ? Not trivial, maybe, long to setup, for sure, but why
"expensive"? I tested running a full node from home that was normally
correctly configured and did not notice anything annoying/expensive

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

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


Re: [bitcoin-dev] Hard fork proposal from last week's meeting

2017-03-29 Thread Aymeric Vitte via bitcoin-dev


Le 29/03/2017 à 11:16, Jared Lee Richardson via bitcoin-dev a écrit :
> Nodes process transactions and are paid nothing to do so, and their
> costs are 100x more relevant to the blocksize debate than a paper
> about miner costs.
>
> Miners are rewarded with fees; nodes are rewarded only by utility and
> price increases.

Nodes are rewarded by just nothing which is the main problem of the
bitcoin network (who is therefore not a decentralized system today)
although it seems like everybody is eluding the issue (as well as how to
find solutions to setup quickly full nodes as you quoted in another
answer to this thread, and of course design a decentralized system to
make sure that full nodes behave correctly)

Bitcoin would not be in this situation (ie maybe at the mercy of a very
small minority of freeriders among all the entities involved in the
network, ie miners,  just seeking to make more and more money because
they invested in an anti-ecological pow, not understanding that bitcoin
is not just about money) if more nodes were existing and could reject
their blocks

It seems like the initial message of this thread(t) is an ultimatum:
whether you implement what we ask, whether we join BU and then > 50 is
almost reached...


>
> On Tue, Mar 28, 2017 at 10:53 AM, Alphonse Pace via bitcoin-dev
>  > wrote:
>
> Juan,
>
> I suggest you take a look at this
> paper: http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf
>   It may help you
> form opinions based in science rather than what appears to be
> nothing more than a hunch.  It shows that even 4MB is unsafe. 
> SegWit provides up to this limit.
>
> 8MB is most definitely not safe today.
>
> Whether it is unsafe or impossible is the topic, since Wang Chun
> proposed making the block size limit 32MiB.  
>
>
> Wang Chun,
>
> Can you specify what meeting you are talking about?  You seem to
> have not replied on that point.  Who were the participants and
> what was the purpose of this meeting?
>
> -Alphonse
>
> On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia  > wrote:
>
> Alphonse,
>
>  
>
> In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on
> 2016 and 32MB limit valid in next halving, from network,
> storage and CPU perspective or 1MB was too high in 2010 what
> is possible or 1MB is to low today.
>
>  
>
> If is unsafe or impossible to raise the blocksize is a
> different topic. 
>
>  
>
> Regards
>
>  
>
> Juan
>
>  
>
>  
>
> *From:*bitcoin-dev-boun...@lists.linuxfoundation.org
> 
> [mailto:bitcoin-dev-boun...@lists.linuxfoundation.org
> ] *On
> Behalf Of *Alphonse Pace via bitcoin-dev
> *Sent:* Tuesday, March 28, 2017 2:24 PM
> *To:* Wang Chun <1240...@gmail.com
> >; Bitcoin Protocol Discussion
>  >
> *Subject:* Re: [bitcoin-dev] Hard fork proposal from last
> week's meeting
>
>  
>
> What meeting are you referring to?  Who were the participants?
>
>  
>
> Removing the limit but relying on the p2p protocol is not
> really a true 32MiB limit, but a limit of whatever transport
> methods provide.  This can lead to differing consensus if
> alternative layers for relaying are used.  What you seem to be
> asking for is an unbound block size (or at least determined by
> whatever miners produce).  This has the possibility (and even
> likelihood) of removing many participants from the network,
> including many small miners.  
>
>  
>
> 32MB in less than 3 years also appears to be far beyond limits
> of safety which are known to exist far sooner, and we cannot
> expect hardware and networking layers to improve by those
> amounts in that time.
>
>  
>
> It also seems like it would be much better to wait until
> SegWit activates in order to truly measure the effects on the
> network from this increased capacity before committing to any
> additional increases.
>
>  
>
> -Alphonse
>
>  
>
>  
>
>  
>
> On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev
>  > wrote:
>
> I've proposed this hard fork approach last year in Hong
> Kong Consensus
> but 

Re: [bitcoin-dev] Bandwidth limits and LN w/ node relay network topography

2017-03-27 Thread Aymeric Vitte via bitcoin-dev
What you are describing is described here too:
https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf (again, at
very draft and somewhere misleading state)

I don't think that the rewards should depend on subsequent chains built
on top of the main one, it should be handled by the main chain

I am not sure to really get your last sentence and why history should
have an importance based on some ways for historical valid nodes to
prove they are still, supposedly defeating the nodes trying to split,
who would inherently not behave correctly and therefore be banned by the
other nodes

Again, we are not far from switching from decentralized to centralized,
and I must again mention the Tor network, which indeed selects nodes
according to their advertised bandwidth (ie does not select you if you
advertise a very low one, which my nodes are doing because their work is
not to relay the tor traffic), but not only since the network itself
makes some calculations (and then does not select the nodes that are
lying, but this does not work the other way around), unlike this system
the decentralized system should self regulate without being able to
fingerprint the valid nodes over time


Le 27/03/2017 à 00:11, praxeology_guy via bitcoin-dev a écrit :
> Bandwidth limits:
> Would be nice to specify global and per node up/down bandwidth limits.
> Communicate limits to peers.
> Monitor actual bandwidth with peers.
> Adjust connections accordingly to attain bandwidth goals/limits.
>
> With Lightning Network:
> Prepay for bandwidth/data.  Continue paying nodes who continue to send
> new useful data.  Potentially pay different amounts for different
> kinds of data.
> Request refunds when a node sends useless/duplicate/invalid/spam
> data.  Discontinue connection w/ nodes that don't refund.  Hence LN
> payment channel network topography becomes somewhat correlated w/
> bitcoin node relay network topography.
>
> Should help nodes get better data faster, improve spam/DDoS
> resiliance.  Incentivizes relay of unconfirmed txs and new blocks,
> when currently there is only a utilitarian marginal self benefit via
> helping everyone in general.
>
> Maybe relay advertisements of available bandwidth and prices, etc.
>
> To identify network splits:
> Nodes could find hash of "nonce + pub key + tip blockhash" beating a
> difficulty threshold.  Sign, broadcast.  Prove their existence and
> connectedness.  History can be maintained and monitored for
> disruption.  Could be made part of the messages that advertise
> available network bandwidth.
>
> Cheers,
> Praxeology Guy
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

2017-03-27 Thread Aymeric Vitte via bitcoin-dev


Le 27/03/2017 à 00:15, Eric Voskuil via bitcoin-dev a écrit :
> On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote:
>
>
>
> The repeated use of the term "network upgrade" in place of the
> accepted technical term (hard fork) is misleading. This and the
> presupposition that the hard fork is coming, and the claims that it's
> not your proposal, make me feel like I'm shopping for a used car...
> It's not used it's pre-owned, everyone's getting the warranty, let me
> see what my manager has to say about the price - it's not my decision.
>
> This is a development list. Avoidance of standardized terminology and
> use of the presumptive close diminishes your message.
>
>
>
> The idea was so powerful you were converted (another sales tactic).
> Who's proposal is this? Can they not speak for themselves?
>
>

What is the rationale to come on this list (on behalf of we don't know
whom) and explain all the details of the "network upgrade" (ie the
attack) if this is not to try to get some information to confirm the
theory and/or improve it, or some information about how it will be
defeated? This just shows that they are not sure about the whole thing,
they should stop this now, launch their approximative BU if they like
and leave BTC alone


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


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


Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

2017-03-24 Thread Aymeric Vitte via bitcoin-dev
Since I have been working on crypto currencies/bitcoin, I kept
repeating: btc should make a priority to significantly increase the
ridiculous number of full nodes we have today, design an incentive for
people to run full nodes and design a system for people to setup full
nodes in an acceptable timeframe

Unfortunately, this was not a priority at all, maybe because of some
historical consensus between miners and devs, so here we are today, some
miners became crazy, the situation would be much more different if more
full nodes were there

Because, how comes everybody perfectly knows the plans of the conspiring
miners? They were stupid enough to explain very precisely how they will
perform the attack?

If I were them I would in addition setup quite a lot of nodes (which
probably they are planning to do, because anyway they need them for the
new sw), not difficult, not so expensive

Defending against abnormal blocks looks to be a non issue, I suppose
that the btc devs perfectly know how to create a pattern based on
history to detect abnormal blocks (including some strange transactions)
and reject them, but this further depends on the ability of current full
nodes to upgrade, which apparently is not what they do the best

I don't know what "Time is running short I fear" stands for and when 50%
is supposed to be reached

Given that it looks difficult to quickly increase the number of full
nodes, that increasing the mining power by standard means looks too
expensive, useless and not profitable, that a counter attack based on a
new proof of something does not look to be ready, then maybe the btc
folks should ask Bram Cohen (who by some luck is participating to this
list) to resurrect the bitcoin miner Epic Scale which Bittorrent Inc (in
an umpteenth dubious attempt to make money) tried some time ago to
include quietly in utorrent forgetting to ask the authorization of the
selected users, then utorrent users might upgrade (potentially 150 M),
and the resulting mining power might be sufficient, depending on the
incentive for this, which is TBD

Or activate by anticipation proof of space... unlike bitcoin-qt,
utorrent sw is quite good to be intrusive, run in background when you
think you have closed it, run things you don't know, etc, so quite
efficient in this situation

Then if btc folks wants to promote full nodes too, it would not be a bad
idea to put the bitcoin-qt blockchain + chain state in a torrent making
sure it is seeded correctly (there are plenty of academics here, they
can do it and run full nodes too) so people can download it and setup
full nodes (incentive TBD too) assuming they know about upnp/port forwarding


Le 24/03/2017 à 17:03, CANNON via bitcoin-dev a écrit :
> When the original white paper was written the idea was that nodes
> would be miners at same time. That the distribution of mining power
> being mostly on par with the distribution of nodes if I understand
> correctly. The problem we face now I fear, is the mining power
> becoming centralized. Even if every bitcoin node invested a $1000
> into mining power and mined at a loss, it still would not even
> make a dent in hash distribution. Currently there are around 6000
> known nodes. If each node invested $1000 for say 10 ths of hashing
> power. At current hashrate of around 3,674,473,142 GH/s this would
> only make up %16 of hash power. This is out of balance as while
> nodes are distributed mining power is becoming very centralized
> due to the creation of monopolization of ASICs. The problem we
> are facing is a small group of a couple people whom control a
> large amount and growing of hash power. At time of this writing
> it has quickly risen to 39% and at current rate will soon become
> 50% of hashing power that is controlled by a small group of a few
> people. Their intentions are too hijack the bitcoin network to a
> cryptocurrency that suits their dangerous agenda. Dangerous because
> their plan would centralize power of consensus as I understand it,
> to themselves the miners. Dangerous also because the code base of
> the attempting subverters is buggy, insecure, and reckless from a
> technological standpoint. Even though they only have very minute
> amount of nodes compared to legitimate bitcion nodes, the danger
> is that they are very quickly taking over in mining power. While
> it is true that nodes will not accept invalid blocks that would be
> attempted to be pushed by the conspirators, they are threatening to
> attack the valid (or in their words, "minority chain") by dedicating
> some mining power soley to attacking the valid chain by mining empty
> blocks and orphaning the valid chain. So even though the majority
> of nodes would be enforcing what blocks are valid and as a result
> block the non-compliant longer chain, the conspiring miner can simply
> (as they are currently threatening to) make the valid chain unuseable
> by mining empty blocks.
>
> If a malicious miner with half or majority control passes invalid
> 

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

2017-03-24 Thread Aymeric Vitte via bitcoin-dev
Since I have been working on crypto currencies/bitcoin, I kept
repeating: btc should make a priority to significantly increase the
ridiculous number of full nodes we have today, design an incentive for
people to run full nodes and design a system for people to setup full
nodes in an acceptable timeframe

Unfortunately, this was not a priority at all, maybe because of some
historical consensus between miners and devs, so here we are today, some
miners became crazy, the situation would be much more different if more
full nodes were there

Because, how comes everybody perfectly knows the plans of the conspiring
miners? They were stupid enough to explain very precisely how they will
perform the attack?

If I were them I would in addition setup quite a lot of nodes (which
probably they are planning to do, because anyway they need them for the
new sw), not difficult, not so expensive

Defending against abnormal blocks looks to be a non issue, I suppose
that the btc devs perfectly know how to create a pattern based on
history to detect abnormal blocks (including some strange transactions)
and reject them, but this further depends on the ability of current full
nodes to upgrade, which apparently is not what they do the best

I don't know what "Time is running short I fear" stands for and when 50%
is supposed to be reached

Given that it looks difficult to quickly increase the number of full
nodes, that increasing the mining power by standard means looks too
expensive, useless and not profitable, that a counter attack based on a
new proof of something does not look to be ready, then maybe the btc
folks should ask Bram Cohen (who by some luck is participating to this
list) to resurrect the bitcoin miner Epic Scale which Bittorrent Inc (in
an umpteenth dubious attempt to make money) tried some time ago to
include quietly in utorrent forgetting to ask the authorization of the
selected users, then utorrent users might upgrade (potentially 150 M),
and the resulting mining power might be sufficient, depending on the
incentive for this, which is TBD

Or activate by anticipation proof of space... unlike bitcoin-qt,
utorrent sw is quite good to be intrusive, run in background when you
think you have closed it, run things you don't know, etc, so quite
efficient in this situation

Then if btc folks wants to promote full nodes too, it would not be a bad
idea to put the bitcoin-qt blockchain + chain state in a torrent making
sure it is seeded correctly (there are plenty of academics here, they
can do it and run full nodes too) so people can download it and setup
full nodes (incentive TBD too) assuming they know about upnp/port forwarding


Le 24/03/2017 à 17:03, CANNON via bitcoin-dev a écrit :
> When the original white paper was written the idea was that nodes
> would be miners at same time. That the distribution of mining power
> being mostly on par with the distribution of nodes if I understand
> correctly. The problem we face now I fear, is the mining power
> becoming centralized. Even if every bitcoin node invested a $1000
> into mining power and mined at a loss, it still would not even
> make a dent in hash distribution. Currently there are around 6000
> known nodes. If each node invested $1000 for say 10 ths of hashing
> power. At current hashrate of around 3,674,473,142 GH/s this would
> only make up %16 of hash power. This is out of balance as while
> nodes are distributed mining power is becoming very centralized
> due to the creation of monopolization of ASICs. The problem we
> are facing is a small group of a couple people whom control a
> large amount and growing of hash power. At time of this writing
> it has quickly risen to 39% and at current rate will soon become
> 50% of hashing power that is controlled by a small group of a few
> people. Their intentions are too hijack the bitcoin network to a
> cryptocurrency that suits their dangerous agenda. Dangerous because
> their plan would centralize power of consensus as I understand it,
> to themselves the miners. Dangerous also because the code base of
> the attempting subverters is buggy, insecure, and reckless from a
> technological standpoint. Even though they only have very minute
> amount of nodes compared to legitimate bitcion nodes, the danger
> is that they are very quickly taking over in mining power. While
> it is true that nodes will not accept invalid blocks that would be
> attempted to be pushed by the conspirators, they are threatening to
> attack the valid (or in their words, "minority chain") by dedicating
> some mining power soley to attacking the valid chain by mining empty
> blocks and orphaning the valid chain. So even though the majority
> of nodes would be enforcing what blocks are valid and as a result
> block the non-compliant longer chain, the conspiring miner can simply
> (as they are currently threatening to) make the valid chain unuseable
> by mining empty blocks.
>
> If a malicious miner with half or majority control passes invalid
> 

Re: [bitcoin-dev] Unique node identifiers

2017-03-09 Thread Aymeric Vitte via bitcoin-dev
As stated in this thread and as I see it the use of BIP150 is optional, 
so if some parties want to trust each others and use it, then they can, 
if they don't like it and don't want to use it, then they don't use it


Unless I misread, some statements in this thread involving the Tor 
network are wrong, the Tor network is a centralized network, each node 
(except the bridges) have a long term identity key and have to prove  
periodically to the authority servers that they are the owners of this 
key, if not the other nodes will never extend circuits to them, then 
they will be of course quite difficult to reach


Unfortunately the original proposal starting this thread seems to be 
reinventing this system that probably can only lead to something 
centralized which cannot apply for the bitcoin network (the Tor network 
is centralized because the team want to control what is happening: 
sybils, bugs, attacks, blacklist etc)


Unless some peers/nodes have decided to trust each others (BIP150) I 
don't think it's a good idea at all that bitcoin nodes have anything 
similar to long term nodeIDs (see 
https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf , already 
posted, not final, not finished, and the title does not really reflect 
what would be the proposal today, but it carefully avoids any 
possibility for a full node to have a long term ID)



Le 09/03/2017 à 02:55, Pieter Wuille via bitcoin-dev a écrit :

On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil  wrote:

On 03/08/2017 03:12 PM, Pieter Wuille wrote:

In that way, I see BIP150 as an extension of IP addresses, except more
secure against network-level attackers. If you believe the concept of
people establishing links along existing trust lines is a problem, you
should be arguing against features in Bitcoin software that allows
configuring preferred IP addresses to connect to as well (-addnode and
-connect in Bitcoin Core, for example).

Weak identity is insufficient to produce the problem scenario that is at
the heart of my concern (excluding people). It is this "[same] except
more secure" distinction that is the problem. You brush past that as if
it did not exist.

So you're saying that a -onlyacceptconnectionsfrom=IP option wouldn't
be a concern to you because it can't exclude people? Of course it can
exclude people - just not your ISP or a state-level attacker.

Please, Eric. I think I understand your concern, but this argument
isn't constructive either.

The proposal here is to introduce visible node identities on the
network. I think that's misguided as node count is irrelevant and
trivial to fake anyway. But you bringing up BIP150 here isn't useful
either. I know that you equate the concept of having verifiable
identity keys in the P2P with a step towards making every node
identifiable, but they are not the same. It's just a cryptographic
tool to keep a certain class of attackers from bypassing restrictions
that people can already make.



--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

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


Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

2017-02-24 Thread Aymeric Vitte via bitcoin-dev
??? apparently we are not discussing the same thing

Maybe I did not provide the right links (reading them again I myself
don't find them so clear), see maybe again
https://github.com/whatwg/streams/issues/33#issuecomment-28045860

a - b - c -d

hash(a)

hash(a+b)

etc

But you are not going to rehash from the beginning, then:

update a --> keep the remaining bytes a_ (+ hash state 1) --> digest
a=hash(a)

update a_+b from hash state 1--> keep the remaining bytes b_ (+ hash
state 2) --> digest a_+b=hash(a+b)

etc

Basically that's similar to a real time progressive hash of chunks of a
file that you are streaming and therefore don't know what will come next
(per opposition to hashing a file that you already have), this could
apply to trees

This is different from something like:

hash(a)

hash(hash(a) +hash(b))

etc

There is no initial state, and the attacker can't modify what was
already hashed, to make it more difficult you can probably modify the
hash state N


Le 24/02/2017 à 17:30, Tim Ruffing via bitcoin-dev a écrit :
> On Fri, 2017-02-24 at 16:18 +0100, Aymeric Vitte via bitcoin-dev wrote:
>> Not sure that you really read deeply what I sent, because stating
>> that
>> hashing files continuously instead of hashing the intermediate steps
>> just gives more latitude to the attacker can't be true when the
>> attacker
>> has absolutely no control over the past files
> What prevents the attacker to provide different past files when talking
> to parties who are still in the initial state?
>
> Then the question is: knowing the hash state, is it as easy to find a
>> collision between two files that will be computed in the next round
>> than
>> finding a collision between two files only?
> With the original usage of the hash function, the hash state is always
> the initial state. Now that the attacker has some control over the hash
> state even. In other words, if the original use of the hash function
> was vulnerable, then your scheme is vulnerable for the initial state.
>
> Concrete attack: If you can find x != y with H(x) = H(y), then you can
> also find m, x != y, with H(m||x) = H(m||y), just by setting m = "". 
>
> Not sure if this is the right place to discuss that issue though...
>
> Best,
> Tim
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

2017-02-24 Thread Aymeric Vitte via bitcoin-dev
Not sure that you really read deeply what I sent, because stating that
hashing files continuously instead of hashing the intermediate steps
just gives more latitude to the attacker can't be true when the attacker
has absolutely no control over the past files

I did not write this as a workaround to fix SHA1, which will be dead
soon or later but as maybe some general concept that could possibly help
whatever hash function you are using for objects that are not frozen but
extending (ie the original email stating that trees might be some kind
of worse candidates for collisions reminded me this), indeed it makes no
sense to patch SHA1 or play around, but this kind of proposal could
accompany the defunct

The drawback is that you have to keep the hash state when you close the
latest hash computation in order to start the next one

Then the question is: knowing the hash state, is it as easy to find a
collision between two files that will be computed in the next round than
finding a collision between two files only?

Knowing that you can probably modify the hash state with some
unpredictable patterns

Most likely the answer is: no, it's (astronomically?) more difficult

Please take it as a suggestion that might be explored (ps: I have the
code for this if needed) rather than an affirmation, still amazed as
shown in the few links provided (among others) that each time I raise
this subject nobody really pays attention (what's the use case?, etc)
and by the fact that it's apparently used by only one project in the
world and not supported by any library


Le 24/02/2017 à 11:04, Tim Ruffing via bitcoin-dev a écrit :
> On Fri, 2017-02-24 at 00:57 +0100, Aymeric Vitte via bitcoin-dev wrote:
>> I have not worked on this since some time, so that's just thoughts,
>> but maybe it can render things much more difficult
>> than   computing two files until the same hash is found
>>
> You basically rely on the idea that specific collisions are more
> difficult to find. This trick or similar tricks will not help. (And
> actually, the more files you add to the hash, the more freedom you give
> the attacker.)
>
> Even if certain collisions are more difficult to find today (which is
> certainly true), the general rule is that someone will prove you wrong
> in a year.
>
> Even if ignore security entirely, switching to new hash function is
> much simpler trying to fix the usage of a broken hash function.
>
> Relying on SHA1 is hopeless. We have to get rid of it.
>
> Best,
> Tim
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

2017-02-23 Thread Aymeric Vitte via bitcoin-dev
Maybe not, unlike frozen objects (certificates, etc), trees are supposed
to extend

Then you can perform progressive hash operations on the objects, ie
instead of hashing the intermediate hash of the objects you do it
continuously (ie instead of hashing the hash of hash file a + hash file
b + hash file c, wait for file d and then do the same, instead hash(file
a + file b + file c), when d comes compute the hash of (file a + file b
+ file c + file d), which implies each time to keep the intermediary
hash state because you are not going to recompute everything from the
beginning)

I have not worked on this since some time, so that's just thoughts, but
maybe it can render things much more difficult than computing two files
until the same hash is found

The only living example I know implementing this is the Tor protocol,
fact apparently unknown, this is probably why nobody cares and nobody is
willing to take it into account (please follow bwd/fwd [1] and see [2]),
this is not existing in any crypto implementations, unless you hack into
it, and this applies to progressive encryption too

[1]
https://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Feb/0018.html


[2] https://github.com/whatwg/streams/issues/33#issuecomment-28554151


Le 23/02/2017 à 22:28, Peter Todd via bitcoin-dev a écrit :
> On Thu, Feb 23, 2017 at 01:14:09PM -0500, Peter Todd via bitcoin-dev wrote:
>> Worth noting: the impact of the SHA1 collison attack on Git is *not* limited
>> only to maintainers making maliciously colliding Git commits, but also
>> third-party's submitting pull-reqs containing commits, trees, and especially
>> files for which collisions have been found. This is likely to be exploitable 
>> in
>> practice with binary files, as reviewers aren't going to necessarily notice
>> garbage at the end of a file needed for the attack; if the attack can be
>> extended to constricted character sets like unicode or ASCII, we're in 
>> trouble
>> in general.
>>
>> Concretely, I could prepare a pair of files with the same SHA1 hash, taking
>> into account the header that Git prepends when hashing files. I'd then submit
>> that pull-req to a project with the "clean" version of that file. Once the
>> maintainer merges my pull-req, possibly PGP signing the git commit, I then 
>> take
>> that signature and distribute the same repo, but with the "clean" version
>> replaced by the malicious version of the file.
> Thinking about this a bit more, the most concerning avenue of attack is likely
> to be tree objects, as I'll bet you you can construct tree objs with garbage 
> at
> the end that many review tools don't pick up on. :(
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


Re: [bitcoin-dev] Proof of Nodework (PoNW) - a method to trustlessly reward nodes for storing and verifying the blockchain

2017-02-14 Thread Aymeric Vitte via bitcoin-dev
I started writing this
https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf some time
ago, but stopped since I was under the impression that this was of very
little interest for the Bitcoin community

It's not final and finished at all, but since I wrote it and don't have
plans right now to pursue it, I placed it in a gist and publish the
link, probably not everything is correct and this does not cover
everything but it can maybe give some ideas (which are for some the
combination of concepts from former/other projects) that could be
reused, addressing:

- incentive to run full nodes

- make sure that they are indeed full nodes

- make sure that they participate to the network and are efficient enough

- make sure that they don't collude in pools to get the rewards and are
independent

- set up quickly a full node (incremental torrent-like download)

As this was written this was supposed to add some modifications to the
bitcoin protocol but I don't think that's necessarily a good idea, most
likely this can be handled via sidechains and/or external systems


Le 13/02/2017 à 15:48, Sergio Demian Lerner via bitcoin-dev a écrit :
>
>
> On Mon, Feb 13, 2017 at 8:58 AM, John Hardy  > wrote:
>
> Hi Sergio,
>
>
> Thanks for your response, interesting work, very excited for RSK.
>
>
> I like the ephemeral payload, I suppose that aspect of my proposal
> could be described as ephemeral blockspace.
>
>
> I'm curious about the challenge phase, what incentive do nodes to
> have to check other nodes' responses?
>
> The reward is split between all full nodes. Therefore each full node
> has an incentive to check at least some other full nodes responses
> because there is a competition for the full node reward. At the end,
> each full node response will be checked by more than other node with
> high probability. Also each full node does a small pre-deposit, that
> is consumed if the node cheats.
>
> Is any validation of responses mandatory, or does policing the
> system rely on altruism?
>
>
> As previously said,  validation is not mandatory.
>
> I also wondered how time-based responses are enforced? What
> prevents a miner censoring challenge responses so they do not get
> included in a block 'in time' - if  inclusion within a block is
> the mechanism used?
>
> There is not many defenses against censorship but try to hide your
> identity until the end of the protocol. But if somebody knows that
> your transactions belong to you, then there is little defense. We just
> wait more than a single block for the commitments, so several miners
> must collude in order to censor a transaction. 
>
>
> I saw your tweet on Lumino - sounds very promising. Would be keen
> to take a look at the paper if you're looking for any additional
> review at this stage.
>
> I'm keeping it private against all my desire because I want it to be
> reviewed before I publish it. Credibility is very easily lost. 
> The same idea (Ephemeral Data) has been used to design the Lumino Network.
>
>
> Regards,
>
>
> John Hardy
>
>
>
> 
> *From:* Sergio Demian Lerner  >
> *Sent:* Sunday, February 12, 2017 8:22 PM
> *To:* John Hardy; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] Proof of Nodework (PoNW) - a method
> to trustlessly reward nodes for storing and verifying the blockchain
>  
> Hi John,
>  RSK platform (a Bitcoin sidechain) is already prepared to do
> something similar to this, although very efficiently. We set apart
> 1% of the block reward to automatically reward full nodes.
>
> We have two systems being evaluated: the first is based on PoUBS
> (Proof of Unique Blockchain Storage) which uses asymmetric-time
> operations to encode the blockchain based on each user public key
> such that decoding is fast, but encoding is slow. The second is
> more traditional proof of retrievability, but it requires some
> ASIC-resistance assumptions. 
>
> In both cases, a special smart contract is being called at every
> block that creates periodic challenges. Every full node that wants
> to participate can submits a commitment to the Merkle hash root of
> a pseudo-random sequence of encoded blocks. Then the smart
> contract chooses random elements from the committed dataset, and
> each full node has a period to submit Merkle-proofs that such
> random elements belong to the commitment.
>
> To prevent blockchain bloat we designed a very cool new type of
> transaction payload: Ephemeral Payload. Ephemeral payload is a
> payload in a transaction that gets discarded after N blocks if no
> smart contract does reference it. If is does, it's solidified
> forever in the blockchain.
> 

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

2017-01-07 Thread Aymeric Vitte via bitcoin-dev


Le 07/01/2017 à 21:26, Chris Priest via bitcoin-dev a écrit :
> Bitcoin Classic only changes the block format (by changing the rule
> that they have to be 1MB or less). Miners are the only ones who make
> blocks, so they are the only ones who mater when it comes to changing
> block rules.

Certainly not

>  Nodes, wallets and other software are not affected by
> changing block rules. Unlike segwit, where *everybody* has to write
> code to support the new transaction format.

This is what we could call a decentralized system, when everybody is
affected

>
> Also, it doesn't matter that 75% of hashpower is made up of a dozen
> people. That's how the system works, it's not a matter of opinion.

That's an obvious weakness of the system

>  If
> you are just a node or just a wallet, and you want your voice to
> matter, then you need to get a hold of some hashpower.

Well, probably you did not mean this, this is not fair. "Just a node"...

Still wondering why you guys don't care about the ridiculous number of
full nodes, no incentive to run one and what would happen if someone
were to control a majority of full nodes

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

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


Re: [bitcoin-dev] Planned Obsolescence

2016-12-15 Thread Aymeric Vitte via bitcoin-dev
Maybe there are still some advantages but I don't know why this is not
considered as a major issue by the bitcoin community for the future and
why this looks to be never discussed:

- the size of the bitcoin network in terms of full nodes is ridiculous
and this is continuously decreasing, we cannot consider the bitcoin
network as a decentralized p2p network, what you are proposing is
logical but will of course amplify the problem

>For reasons I am unable to determine a significant number of node
operators do not upgrade their clients.

Why should they? What is the incentive for people to run full nodes and
upgrade? FYI I am part of the 2071 0.13.1 nodes for some good reasons
but will just shut it down when I am done, same for zcash (which as a
matter of fact I upgraded today since by some chance I noticed some
updates I was not aware of neither notified, just running it because I
need it from time to time and just don't kill it so I don't have to wait
for the restart process, maybe others are doing the same or just forgot
that they were running a full node)

Because, again, why should I or we maintain it/them?

I have looked at the proposals in the past (as well as the incentive
program) to reward those that are running full nodes but only found a
very few, never implemented (or even considered)

This is the very same for proposals allowing to start a full node from
zero in an acceptable timeframe (ie not 10 days in my case)

If the consensus is not to solve those two points and have a bitcoin
network controlled then it would be interesting to know why, so people
don't waste time trying to find solutions

Satoshi himself predicted that the full nodes will get centralized, I
think it's wrong, or in that case the bitcoin network cannot pretend to
be a decentralized immutable system (can be compared then to the Tor
network which does not pretend to be decentralized, because it is
centralized, and in addition does not encourage small nodes)

PS: IMHO the email notificiation system makes it difficult to follow
whom is answering to whom/what on this list compared to other lists

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


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