Re: [bitcoin-dev] Witness script validation to reject arbitrary data

Le 08/05/2023 à 23:43, Christopher Allen via bitcoin-dev a écrit : > There was a recent thread discussing raising the limit on > OP_RETURN https://github.com/bitcoin/bitcoin/issues/27043 Indeed we already discussed all of this, and the conclusion was: there are no reasons to impose limits,

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

; i think the w3c is a very good example of a slow train wreck, and we > should do everything possible to avoid the decisions they made > > On Thu, Apr 20, 2023 at 7:09 AM Aymeric Vitte via bitcoin-dev > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > Pers

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

ers of (N)ACKs > is delusional. > As I explained above, there is a whole lot more nuance to determining > even just the status of the opinions on a PR, nevermind the code itself. > > In this specific example of a soft fork, there is also consideration of > the opinions outside of t

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

The different emails are overlong, it's difficult to follow It is super surprising to see that Bitcoin has only 4 maintainers funded by Brink and Blockstream, but I think the decisions are taken elsewhere And I think the job of the maintainers is not only to be maintainers but to do the PR

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

So with datacarrier we can store data in taproot annex with one tx which will be data and/or extension of the script validation via PUSH_ANNEX I looked at your links and plenty of others, but had some hard time to find the proposal

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

gt; > Cheers > Claus > > On Thu, Feb 16, 2023 at 7:30 PM Aymeric Vitte via bitcoin-dev > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > It's super unclear how long it could take for such a change to be > adopted > >

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

It's super unclear how long it could take for such a change to be adopted Then the answer is simple, see: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation Outstandingly, very, mega, bad, but working, bringing bitcoin back 10 years ago But

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403 "What is the process to have someone do the PR for this? Or I do it and most likely it will be a very shxtty one since I am not a C/C++ expert, then wasting the time of everybody It's urgently required, I did consider

Re: [bitcoin-dev] Ordinal Inscription Size Limits

Le 06/02/2023 à 19:05, Erik Aronesty via bitcoin-dev a écrit : > my favorite one is the javascript exploit for people that like to > render untrusted blockchain data in their browser Taking this example to show that from my standpoint it's not a good idea to store "big things" in the

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

Yes I agree, let people decide and since taproot has no limits then it sould be the same for OP_RETURN I posted https://github.com/bitcoin/bitcoin/issues/27043 Le 05/02/2023 à 13:06, Peter Todd a écrit : > > On February 5, 2023 12:40:38 PM GMT+01:00, Aymeric Vitte > wrote: >> I think

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

Then how can we move forward with several OP_RETURN and no size limit? I can start posting a bug/enhancement proposal in bitcoin repo but can't write the PR Le 05/02/2023 à 01:04, Peter Todd a écrit : > > On February 5, 2023 12:09:02 AM GMT+01:00, Aymeric Vitte via bitcoin-dev > wr

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

I don't know, what number would you advise? When I made the bitcoin-transactions nodejs module some years ago the limit (from the specs) was 512B It's not a fork, super easy to do And necessary because bitcoin on ground of I don't know what rule allowing the IF/ENDIF "unlimited" storage just

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

Thanks Christopher, then I understand the process: - I must issue a PR where I switch 80 to another number, even if I am not a C/C++ expert it looks easy - I must stay calm and answer all outstanding concerns about this trivial change - Since I am not as clever as the bitcoin devs I must be

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > I think the right way so people don't invent deviant things is to > increase the size of OP_RETURN, I don't get this number of >

Re: [bitcoin-dev] Purely off-chain coin colouring

I still don't see in both proposals how you avoid that someone steals your NFT, double mint it or sell it several time, because the thief can do the very same that what your are describing, a hash of the content is not enough, you can slightly modify an image or a document and it gives another

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

Indeed the witness envelope is more costly and less easy to use (or read/track) But let's take a standard P2PKH or P2WPKH output, what prevents me from adding in the beginning of scriptSig or witness while spending it: OP_PUSH OP_DROP ? Non standard ? This one makes one transaction only There

Re: [bitcoin-dev] Purely off-chain coin colouring

I am not an expert with RGB, but it looks limited (only bitcoin chains from the github repo, apparently on hold), distributed over the "lightning network" or LN nodes (what is it?), or Bifrost extension, with a dubious token floating around, like ethereum mess as RGB docs describe Ethereum (and

Re: [bitcoin-dev] Purely off-chain coin colouring

In your system what is the off-chain mechanism? And what prevent a thief to steal your NFT? I have submitted several time "A Bitcoin NFT system" https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 It's more simple, the NFT (whether real or electronic) is referenced by a initial hash

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

Thanks, then this limitation should be rethought I think (see the email I just sent replying to the coloured thread) Because it forces people to store in witness (less easy to track/show I believe) or adopt some deviant behavior (like storing in addresses where the utxo will remain unspendable

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

As far as I can read nobody replied to the initial question: what is considered as good/best practice to store in Bitcoin? Reiterating my question: what are the current rules for OP_RETURN, max size and number of OP_RETURN per tx Le 02/02/2023 à 12:22, Peter Todd via bitcoin-dev a écrit : > On

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

Could someone clarify what is the standard for OP_RETURN? As far as I understand the data is limited to 80B and only one OP_RETURN is allowed in one transaction, if not the tx is non standard, correct? Then the debate can be to store in witness indeed Or you can store in output addresses (with

Re: [bitcoin-dev] A Universal Coin Swap system based on bitcoin and a Bitcoin NFT system

I am not sure to understand the current discussion about ordinals relayed by the press, it's from my standpoint a no for storing things in witness, and a no to use ordinals as a NFT system Please remember that NFTs are not only electronic things, it can be real things, or whatever you like, just

Re: [bitcoin-dev] Ordinal Inscription Size Limits

I saw the other posts, then storage in witness, no, ordinals no for now, let's keep things simple and understandable I forgot to mention that the proposals envision a "local bitcoin" (for a metaverse for example) wich is a fork of Bitcoin code, but of course not a fork of Bitcoin, and which of

Re: [bitcoin-dev] Ordinal Inscription Size Limits

Le 27/01/2023 à 14:21, Andrew Poelstra via bitcoin-dev a écrit : > if people were storing NFTs and other crap on the > chain, then the Bitcoin fee market would become entangled with random > pump markets So you mean that Bitcoin is out for NFTs, Metaverse and "web3"? LN is good but I don't

[bitcoin-dev] A Universal Coin Swap system based on bitcoin and a Bitcoin NFT system

Please see: "A Bitcoin NFT system" https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 "The purpose of this proposal is to propose a simple NFT system based on the Bitcoin blockchain, assuming that the main purpose of a NFT is to be sold/bought, but not only, it can be something that

Re: [bitcoin-dev] A Bitcoin NFT System

29, 2022 at 5:49 PM CET, Aymeric Vitte via bitcoin-dev wrote: >> I am not a fan of NFTs as currently designed and used, centralized, >> insecure, duplicable, virtual, stealable, not signed, expensive >> >> But if you consider that a NFT is anything that you can buy or

[bitcoin-dev] A Bitcoin NFT System

I am not a fan of NFTs as currently designed and used, centralized, insecure, duplicable, virtual, stealable, not signed, expensive But if you consider that a NFT is anything that you can buy or store, as something real, or electronic, or whatever, in the real world, web or metaverse, then it

Re: [bitcoin-dev] Bitcoin Legal Defense Fund

(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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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

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

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

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

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

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

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

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

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

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.

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

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

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.

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.

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

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

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?

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?

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?

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

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

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

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

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

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

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

[bitcoin-dev] pubkey or not pubkey?

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

+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

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

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

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

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

, 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

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

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

"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

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

  1   2   >