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, tha
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 st
gt;
> 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?
>>>
>>
>
> 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) Choosing
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.
>
> I
@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 participat
@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 passivel
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
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 pl
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
> template-transactio
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
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 port
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 boo
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
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 becau
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 practic
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
an
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 is
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 i
> 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
bitcoin-dev
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
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
transactions
>
> >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 a
Hello all,
Today we are submitting some updates to BIP75:
-- Example use cases have been reworded to more accurately describe the
goal of this BIP and how the technology works.
-- ECDSA and PGP have been added to the supported public key infrastructure
(PKI) types to increase flexibility and use
Why not just have a single 1-of-m multisig transaction, with one key on
each server? Based on which key is used you would know which server is
compromised, and (in my opinion) it wouldn't look nearly as suspicious.
On Thu, Aug 25, 2016 at 11:26 AM Gregory Maxwell via bitcoin-dev <
bitcoin-dev@list
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 was
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 <
bit
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 to
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 wrote:
> This troll is
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 in
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
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
t
> 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 wri
>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
tool
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 wo
> 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 e
Thomas,
I like your idea about expanding Bitcoin URI's to include signatures. For
BIP75 store and forward servers we are already thinking the DNS record
would have the user's public key as well as the URL of their store and
forward endpoint, so as soon as that becomes a standard you could use it
j
> 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 standards
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 it
Matthew,
Other than gambling, do you have any specific examples of how this could be
useful?
On Fri, May 20, 2016, 20:34 Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Using the hash of multiple blocks does not make it any safer. The miner of
> the last block alway
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 tha
On Sun, Mar 27, 2016 at 5:49 AM Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > I guess my question didn't get across.
> >
> > Why would you want to make your usecase do connections over the
> > peer2peer
> > (net.cpp) connection at all?
> >
> >
On Sat, Mar 26, 2016 at 1:34 AM Tom via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Friday 25 Mar 2016 19:43:00 Jonas Schnelli via bitcoin-dev wrote:
> > An encrypted channel together with a trusted full node would finally
> > allow to have a secure and save SPV communication.
dbach via bitcoin-dev
> > > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> > I think it's a bad idea to pollute the original idea of this BIP with
> > other extensions. Other extensions should go to separate BIPs,
> > especially sin
should 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,
> >
> > Our BIP (o
Hi everyone,
Our BIP (officially proposed on March 1) has tentatively been assigned
number 75. Also, the title has been changed to "Out of Band Address
Exchange using Payment Protocol Encryption" to be more accurate.
We thought it would be good to take this opportunity to add some optional
fields
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 PaymentRequ
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
Mo
48 matches
Mail list logo
