A better solution is to just have the sending wallet check to see if the
address you are about to send to has been used before. If it's a fresh
address, it sends it through without any popup alert. If the address has
history going back a certain amount of time, then a popup comes up and
notifies th
On 11/5/15, Eric Voskuil via bitcoin-dev
wrote:
> On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
>> ...
>> Validators: Economically dependent full nodes are an important part of
>> Bitcoin's security model because they assure Bitcoin security by
>> enforcing consensus rules. While full
> The bigger point however, which Erik explained, was: widespread use of
> APIs as a sole means of interfacing with the blockchain also
> contributes to reducing network security for everyone, because it
> erodes the consensus rule validation security described under
> "Validators" in the OP.
I co
Here is the problem I'm trying to solve with this idea:
Lets say you create an address, publish the address on your blog, and
tell all your readers to donate $0.05 to that address if they like
your blog. Lets assume you receive 10,000 donations this way. This all
adds up to $500. The problem is th
the private key holder intended all inputs to be
included. Hence the need for a new opcode.
btw, this scheme is definitely in the 10x or higher gain. You could
potentially spend an unlimited number of UTXOs this way.
On 11/24/15, Gavin Andresen wrote:
> On Tue, Nov 24, 2015 at 12:34 PM, Ch
on that used this opcode.
>
> Please be blunt about any of my own misunderstandings that this email makes
> clear.
>
> On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Nov 24
east 100
> blocks in the past. Maybe add a minimum block height as well to prevent
> unnecessary scanning (with the requirement that at least one utxo must be
> in that minimum block).
>
> 3. Seems like a nice way to the reduce utxo set. But hard to say how
> effective it would r
I made a post a few days ago where I laid out a scheme for
implementing "coalescing transactions" using a new opcode. I have
since come to the realization that an opcode is not the best way to do
this. A much better approach I think is a new "transaction type" field
that is split off from the versi
I proposed in my Wildcard Inputs BIP that the version field be split
in two. The first 4 bytes are version number (which in practice is
being used for script version), and the second 4 bits are used for
transaction type.
I don't think the BIP9 mechanism really applies to transactions. A
block is e
A wallet doesn't receive transactions from other wallets. That is what
a node does. Wallets just make transactions and then sends them to the
nodes. Nodes then send them to other nodes.
In the early days of bitcoin, all wallets were nodes, but now a lot of
wallets are just wallets with out any spe
I don't like this scheme at all. It doesn't seem to make bitcoin
better, it makes it worse.
Lets say it's 2050 and I want to sweep a paper wallet I created in
2013. I can't just make the TX and send it to the network, I have to
first contact an "archive node" to get the UTXO data in order to make
> In none of these cases do you lose anything.
Nor do you gain anything. Archive nodes will still need to exist
precisely because paper wallets don't include UTXO data. This is like
adding the ability to partially seed a movie with bittorrent. You
still need someone who has the whole thing has to
Block witholding attacks are only possible if you have a majority of
hashpower. If you only have 20% hashpower, you can't do this attack.
Currently, this attack is only a theoretical attack, as the ones with
all the hashpower today are not engaging in this behavior. Even if
someone who had a lot of
By that same logic, any wallet that implemented P2SH is also voting
for an increased block size, since P2SH results in smaller
transactions, in the same way SW results in smaller transactions.
On 12/19/15, Peter Todd via bitcoin-dev
wrote:
> On Sat, Dec 19, 2015 at 11:49:25AM -0500, jl2012 via bi
Then shouldn't this be something the pool deals with, not the bitcoin protocol?
On 12/19/15, Matt Corallo wrote:
> Peter was referring to pool-block-withholding, not selfish mining.
>
> On December 19, 2015 7:34:26 PM PST, Chris Priest via bitcoin-dev
> wrote:
>>Block
On 12/19/15, jl2012 wrote:
> Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到:
>> Block witholding attacks are only possible if you have a majority of
>> hashpower. If you only have 20% hashpower, you can't do this attack.
>> Currently, this attack is only a theoretica
On 12/19/15, Emin Gün Sirer wrote:
>
> Chris Priest is confusing these attacks with selfish mining, and further,
> his characterization of selfish mining is incorrect. Selfish Mining is
> guaranteed to yield profits for any pool over 33% (as a result, Nick
> Szabo has dubbed this the "34% attack")
The term "mining centralization" is very common. It come up almost in
every single discussion relating to bitcoin these days. Some people
say "mining is already centralized" and other such things. I think
this is a very bad term, and people should stop saying those things.
Let me explain:
Under no
Its mostly a problem for exchanges and miners. Those entities need to
be on the network 100% of the time because they are using the network
100% of the time. A normal wallet user isn't taking payments every few
minutes like the exchanges are. "Getting booted off the network" is
not something to wor
Segwit requires work from exchanges, wallets and services in order for
adoption to happen. This is because segwit changes the rules regarding
the Transaction data structure. A blocksize increase does not change
the Transaction rules at all. The blocksize increase is a change to
the Block structure.
On 5/17/16, Eric Lombrozo via bitcoin-dev
wrote:
> Nice!
>
> We’ve been talking about doing this forever and it’s so desperately needed.
>
"So desperately needed"? How do you figure? The UTXO set is currently
1.5 GB. What kind of computer these days doesn't have 1.5 GB of
memory? Since you people
I'm currently working on a wallet called multiexplorer. You can check
it at https://multiexplorer.com/wallet
It supports all the BIPs, including the ones that lets you export and
import based on a 12 word mnemonic. This lets you easily import
addresses from one wallet to the next. For instance, yo
On 6/30/16, Erik Aronesty via bitcoin-dev
wrote:
>
> I would like to see a PGP-like "web of trust" proposal for both the
> security of the bitcoin network itself /and/ (eventually) of things like
> transmission of bitcoin addresses.
>
> Something where nodes of any kind (full, spv, mobile wallets)
Because the blocksize limit is denominated in bytes, miners choose
transactions to add to a block based on fee/byte ratio. This mean that
if you make a transaction with a lot of inputs, your transaction will
be very big, an you'll have a to pay a lot in fees to get that
transaction included in a bl
How does your system prevent against insider attacks? How do you know
the money is stolen by someone who compromised server #4, and not
stolen by the person who set up server #4? It is my understanding
these days most attacks are inside jobs.
On 8/24/16, Peter Todd via bitcoin-dev
wrote:
> On Thu
>From my experience working with coin selection algorithms, there are
three "goals" to it:
1. Minimize cost
2. Maximize privacy
3. Minimize UTXO footprint
You can build a coin selection algorithm that achieves 1 and 3, but
will sacrifice 2. If you want coin selectin to maximize your privacy,
it w
On 1/3/17, Jonas Schnelli via bitcoin-dev
wrote:
>
> There are plenty, more sane options. If you can't run your own full-node
> as a merchant (trivial), maybe co-use a wallet-service with centralized
> verification (maybe use two of them), I guess Copay would be one of
> those wallets (as an examp
1/4/17, Eric Voskuil wrote:
> On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:
>> On 1/3/17, Jonas Schnelli via bitcoin-dev
>> wrote:
>>>
>>> There are plenty, more sane options. If you can't run your own full-node
>>> as a merchant (triv
Bitcoin Classic only activates if 75% of the network adopts it. That
is not irresponsible or dangerous. It would only be dangerous if it
activates at 50%, because that would create a situation where its not
clear which side of the fork has the most proof of work.
On 1/7/17, Eric Lombrozo via bitco
and other tomfoolery as 75% of the
> hashrate is ultimately only a dozen people or so.
>
> You have plenty of channels through which you can make your announcements,
> this particular one is not okay.
>
> On Jan 7, 2017 3:12 PM, "Chris Priest via bitcoin-dev" <
>
Its too bad you're not the one who decides what gets posted here or
not. If you don't like whats being discussed, then don't open those
emails.
On 1/7/17, Eric Lombrozo via bitcoin-dev
wrote:
> Can you guys please take this discussion elsewhere? Perhaps to
> bitcoin-discuss? This is not the place
I approve of this idea. Counterparty has the same problem. Their API
returns a unsigned transaction that is formed differently from how
other unsigned transactions, which causes friction. Someone needs to
write up a specification that is standardized so that all unsigned
transactions are of the sam
I don't think the solution should be to "fix the replay attack", but
rather to "force the replay effect". The fact that transactions can be
relayed should be seen as a good thing, and not something that should
be fixed, or even called an "attack".
The solution should be to create a "bridge" that r
> If there is a split, it becomes 2 incompatible ledgers.
Not necessarily. When the BIP50 hard fork happened, it didn't create
two incompatible ledgers. It *could* have, but it didn't. If every
single transaction mined during that time has been "double spent" on
the other chain, then it would have
Personally I think once the blocksize arguments are solved, there will
be no more contentious changes for this voting system to deal with.
What other contentious issues have come up in the past 3 years or so
that wasn't blocksize/scaling related? Do other protocols like TCP/IP
and the HTTP protocol
On 2/22/17, Peter Todd via bitcoin-dev
wrote:
> Reposting something that came up recently in a private discussion with some
> academics:
>
> Concretely, let's define a prunable MMR with the following grammar. This
> definition is an improvement on whats in the python-proofmarshal by
> committing
>
36 matches
Mail list logo
