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

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

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

2021-12-12 Thread Aymeric Vitte via bitcoin-dev
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 vi

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:

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

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

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

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:

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 >

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

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

[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

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,

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

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

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

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

[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

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

[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

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

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 à

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

2019-05-27 Thread Aymeric Vitte via bitcoin-dev
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 s

[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

Re: [bitcoin-dev] IsStandard

2019-05-03 Thread Aymeric Vitte via bitcoin-dev
aries 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 > > O

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

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

Re: [bitcoin-dev] IsStandard

2019-05-02 Thread Aymeric Vitte via bitcoin-dev
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

[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    

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,

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

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

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

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

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

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

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

[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 

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

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

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

Re: [bitcoin-dev] BIP39 seeds

2019-01-01 Thread Aymeric Vitte via bitcoin-dev
. "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:bitc

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

Re: [bitcoin-dev] BIP39 seeds

2018-12-27 Thread Aymeric Vitte via bitcoin-dev
s 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

Re: [bitcoin-dev] BIP39 seeds

2018-12-24 Thread Aymeric Vitte via bitcoin-dev
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: >

[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

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

Re: [bitcoin-dev] bitcoin-transactions

2018-08-01 Thread Aymeric Vitte via bitcoin-dev
hat 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.

[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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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,

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

2017-05-04 Thread Aymeric Vitte via bitcoin-dev
, 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

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

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

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

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

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

2017-04-20 Thread Aymeric Vitte via bitcoin-dev
hatever 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: > > W

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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