Re: [bitcoin-dev] Security problems with relying on transaction fees for security

On Tue, Jul 12, 2022 at 12:26 AM Peter Todd wrote: > Anyway, designing protocols for "price go up forever" hopium is a bad idea. > I'm quite disappointed that this is what you've reduced my argument to. The price doesn't need hopium; if it stays between where it is now and the all time high,

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

I think many of these discussions about the loss of the mining reward are fatally shortsighted. It's always daytime somewhere--when you talk about volume dropping at night, that simply means there is not enough activity outside the US. If Bitcoin continues its rise in price, mining rewards will

Re: [bitcoin-dev] No Order Mnemonic

; > > On Fri, 8 Jul 2022 at 16:09, James MacWhyte via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> What do you do if the "first" word (of 12), happens to be the last word >>> in the list alphabetically? >>> >> >

Re: [bitcoin-dev] No Order Mnemonic

> What do you do if the "first" word (of 12), happens to be the last word in > the list alphabetically? > That couldn't happen. If one word is the very last from the wordlist, it would end up at the end of your mnemonic once you rearrange your 12 words alphabetically. However! (@vjudeu)

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

Hi Billy! See above, but to break down that situation a bit further, these are the > two situations I can think of: > >1. The opcode limits user/group A to send the output to user/group B >2. The opcode limits user A to send from one address they own to >another address they own. > >

Re: [bitcoin-dev] Opinion on proof of stake in future

@Lloyd wrote: Of course in reality no one wants to keep their coin holding keys online so > in Alogorand you can authorize a set of "participation keys"[1] that will > be used to create blocks on your coin holding key's behalf. > Hopefully you've spotted the problem. > You can send your

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

@Billy I like the idea. It is very obvious how useful an opcode like this would be! (My background is in wallet implementation) @Russell I do understand your concerns of monotonism, however I'm having a hard time really coming up with an attack vector. You said "one can design a wallet to

Re: [bitcoin-dev] Fortune Cookies to Bitcoin Seed

On Tue, Mar 5, 2019 at 4:39 PM Trey Del Bonis via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Keeping 20 around is a little excessive but it gives 390700800 possible > wallets. So security can be trivially parameterized based on how secure you > want your wallet to be if someone

Re: [bitcoin-dev] Card Shuffle To Bitcoin Seed

James On Sun, Feb 3, 2019 at 10:27 AM Ryan Havar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Conveniently a shuffled deck of cards also can serve as a physical backup > which is easy to hide in plain sight with great plausible deniability. > To make sure someone doesn't

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

On Tue, Jan 29, 2019 at 6:46 PM wrote: > > If the sender refuses to sign the final transaction, the receiver just > propagates the template transaction which pays the receiver! So it's a > pretty weak attack. > > The only real attack is that the sender could double-spend the >

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

James On Sun, Jan 27, 2019 at 2:11 PM wrote: > > It isn't passed "back and forth so many times". > You are right, I got the wrong impression the first time I read it. > This is an important anti-DoS/anti-spy tactic, as it proves the sender > actually owns those inputs and if the protocol is

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

Why does the template transaction need to be signed in step one and passed back and forth so many times? What is wrong with: 1. Sender creates unsigned tx with their relevant inputs and outputs. This tx is passed to receiver. 2. Receiver adds their relevant inputs and outputs and signs their

Re: [bitcoin-dev] BIP39 seeds

On Wed, Jan 2, 2019 at 3:40 AM Alan Evans via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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

Re: [bitcoin-dev] BIP39 seeds

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

Re: [bitcoin-dev] BIP39 seeds

On Mon, Dec 24, 2018 at 2:48 PM Aymeric Vitte via bitcoin-dev < 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

Re: [bitcoin-dev] Proposal for Palindromic (Reversible) Mnemonics

I agree with Joseph. If you want plausible deniability, it would be better to simply hide the funds somewhere in the HD chain. Same if you want a second vault tied to the same phrase. You are reducing security by eliminating all entropy that doesn't fit the reversible criteria, although in

Re: [bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability)

Hi Yuval! Sorry for reviving an old email thread. Could you describe what the UX would be like, or how a wallet developer might implement this? Is the intention that someone would open their non-private wallet, and choose an option that slowly siphons their funds into a different app? Why would

Re: [bitcoin-dev] BIP Proposal - Address Paste Improvement

I liked the cheekiness of your summary, Adam ;) I'm not sure why this needs to be a BIP. It is a UX detail--not really related to bitcoin protocol or procedures. I wouldn't even call it a description of best practices, since every product's use case is going to be different. If you think there

Re: [bitcoin-dev] MultiSig request URI proposal

Hello! A URI is useful as a standard for one-way communication, but on-chain multisig requires many steps. multiple parties need to provide signatures, and one party needs to aggregate all the signatures and publish the transaction. This URI scheme would allow one to pass along a raw transaction

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

> The 1MB classic block size prevents quadratic hashing > problems from being any worse than they are today. > > Add a transaction-size limit of, say, 10kb and the quadratic hashing problem is a non-issue. Donezo. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

It's my opinion that the purpose of this list and bitcoin protocol development in general is to build the base functionality that other companies and individuals require to provide usability to the end-user. The 0-conf debate is a UX issue. If end users shouldn't rely on 0-conf, it is up to wallet

Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)

Hi All, I'm coming late to the party. I like the Block75 proposal. Multiple people have said miners would/could stuff blocks with insincere transactions to increase the block size, but it was never adequately explained what they would gain from this. If there aren't enough legitimate

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

> > >I've always assumed honeypots were meant to look like regular, yet > >poorly-secured, assets. > > Not at all. Most servers have zero reason to have any Bitcoin's accessible > via them, so the presence of BTC privkeys is a gigantic red flag that they > are part of a honeypot. > I was talking

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

I've always assumed honeypots were meant to look like regular, yet poorly-secured, assets. If the intruder could identify this as a honeypot by the strange setup (presigned, non-standard transactions lying around) and was aware that the creator intended to doublespend as soon as the transaction

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

For reasons others have pointed out, it's not really plausible. Either way, this has nothing to do with transmitting data over audio. Please start a new thread if you want to discuss your idea instead of hijacking this one. Thanks ;) On Fri, Aug 12, 2016, 05:36 Erik Aronesty via bitcoin-dev <

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

I agree, audio-based transference isn't really great for a podcast or radio ad. It could be used to transmit payment details between phones that don't have cameras, though. I think it would be better to define a standard for transmitting information over audio, but not define what information is

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

Signed by the key pair that was referenced in the output of the on-chain transaction? (Bob in my example, actually) Doesn't that mean it's easy to follow who is paying whom, you just can't see how much is going to reach recipient? On Tue, Aug 9, 2016, 04:40 Tony Churyumoff

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

One more thought about why verification by miners may be needed. Let's say Alice sends Bob a transaction, generating output C. A troll, named Timothy, broadcasts a transaction with a random hash, referencing C's output as its spend proof. The miners can't tell if it's valid or not, and so they

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

That is a good point. As you said, it puts a lot more burden on the coin holders. One big downside would be data management. Instead of simply backing up a single HD private key, the user would have to back up entire histories of every output that has been sent to them if they want to secure their

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

Wouldn't you lose the ability to assume transactions in the blockchain are verified as valid, since miners can't see the details of what is being spent and how? I feel like this ability is bitcoin's greatest asset, and by removing it you're creating an altcoin different enough to not be connected

Re: [bitcoin-dev] Fees and Accounts

> Most people? I'm talking about services that are built to handle multiple accounts, like exchanges and payment processors. > You realize that you need to set up bitcoind to make an > external request on every reception of funds on any address in the whole > system. > No, you don't. You can

Re: [bitcoin-dev] Fees and Accounts

>From what I've seen, most people build their own account system separately (including fee management) and just use bitcoind to send, receive, and verify transactions. It's not meant to be a drop-in solution for running an entire bitcoin deposit and withdrawal system, it just provides the bare

Re: [bitcoin-dev] BIP Number Request: Open Asset

I'm curious to hear the answers to the questions Luke asked earlier. I also read through the documentation and wasn't convinced it was thought out well enough to actually build something on top of, but there's no reason it can't get a number as a work-in-progress. I hope it does continue to get

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

> Clearly the primary purpose of BIP0075 is to enshrine a DNSSEC protocol > for giving wallet addresses memorable names. > > I can't tell if you're being sarcastic or not, but if you aren't, I don't think this is an accurate description at all. BIP75 is, at its most simplest, nothing more than an

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

> Note that "client supplied identification" is being pushed for AML/KYC > compliance, e.g. Netki's AML/KYC compliance product: > > > http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/ > > This is an extremely undesirable feature to be baking into

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

Thanks for starting this discussion, Erik. > Should this be a new BIP? I know netki's BIP75 is out there - but I think > it's too specific and too reliant on the domain name system. > This is not quite accurate. BIP75 is designed to be independent of any name resolution system. You could use

[bitcoin-dev] BIP75 update & PR - Simplification

Hi all, We've made some significant changes to BIP75 which we think simplify things greatly: Instead of introducing encrypted versions of all BIP70 messages (EncryptedPaymentRequest, EncryptedPayment, etc), we have defined a generic EncryptedProtocolMessage type which is essentially a wrapper

Re: [bitcoin-dev] BIP75 - Out of Band Address Exchange

d go to separate BIPs, > > especially since methods to clarify the fee have nothing to do with > > secure and authenticated bi-directional BIP70 communication. > > > > > > On 03/10/2016 10:43 PM, James MacWhyte via bitcoin-dev wrote: > > > Hi everyone, > &g

Re: [bitcoin-dev] BIP75 - Out of Band Address Exchange

eparate BIPs, > especially since methods to clarify the fee have nothing to do with > secure and authenticated bi-directional BIP70 communication. > > > On 03/10/2016 10:43 PM, James MacWhyte via bitcoin-dev wrote: > > Hi everyone, > > > > Our BIP (officially propo

Re: [bitcoin-dev] Proposed BIP extension to BIP 0070

I accidentally replied to Luke off-list, and this was his reply to my last message: "But wouldn't the server be a trusted third-party in this case? I'm thinking it's very close to being possible for an untrusted server to do this..." If you are okay with anyone being able to view your

Re: [bitcoin-dev] Proposed BIP extension to BIP 0070

Our BIP just defines protocol definitions, and doesn't really dictate how people use them (we're coming up with a new title for the BIP, by the way, to more accurately convey that). Using our definitions as building blocks, someone could definitely accomplish what you described. For example, Joe