On Wed, May 13, 2015 at 6:19 AM, Daniel Kraft wrote:
> 2) Divide the range of all blocks into intervals with exponentially
> growing size. I. e., something like this:
>
> 1, 1, 2, 2, 4, 4, 8, 8, 16, 16, ...
>
Interesting. This can be combined with the system I suggested.
A node broadcasts 3 p
Le 12/05/2015 18:10, Gavin Andresen a écrit :
> Added back the list, I didn't mean to reply privately:
>
> Fair enough, I'll try to find time in the next month or three to write up
> four plausible future scenarios for how mining incentives might work:
>
> 1) Fee-supported with very large blocks
On Wed, May 13, 2015 at 10:49 AM, Thomas Voegtlin
wrote:
>
> The reason I am asking that is, there seems to be no consensus among
> core developers on how Bitcoin can work without miner subsidy. How it
> *will* work is another question.
>
The position seems to be that it will continue to work fo
> With POW, a new node only needs to know the genesis block (and network
> rules) to fully determine which of two chains is the strongest.
>
But this matters if a new node has access to the globally strongest chain.
If attacker is able to block connections to legitimate nodes, a new node
will happ
On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell wrote:
> An example would
> be tx_size = MAX( real_size >> 1, real_size + 4*utxo_created_size -
> 3*utxo_consumed_size).
This could be implemented as a soft fork too.
* 1MB hard size limit
* 900kB soft limit
S = block size
U = UTXO_adjusted_siz
08.05.2015 at 5:49 Jeff Garzik wrote:
> To repeat, the very first point in my email reply was: "Agree that 7 tps
> is too low"
For interbank trading that would maybe enough but I don't know.
I'm not a developer but as a (former) user and computer scientist I'm
also asking myself what is the cor
> Personally, for privacy reasons I do not want to leave a footprint in the
blockchain for each pizza. And why should this expense be good for trivial
things of everyday life?
Then what's the point?
Isn't this supposed to be an Open transactional network, it doesn't matter
if you don't want that,
On Wed, May 13, 2015 at 11:31 AM, Alex Mizrahi
wrote:
>
> But this matters if a new node has access to the globally strongest chain.
>
A node only needs a path of honest nodes to the network.
If a node is connected to 99 dishonest nodes and 1 honest node, it can
still sync with the main network
Let's consider a concrete example:
1. User wants to accept Bitcoin payments, as his customers want this.
2. He downloads a recent version of Bitcoin Core, checks hashes and so on.
(Maybe even builds from source.)
3. Let's it to sync for several hours or days.
4. After wallet is synced, he gives hi
Hi All,
I'd like to propose a BIP to normalize transaction IDs in order to address
transaction malleability and facilitate higher level protocols.
The normalized transaction ID is an alias used in parallel to the current
(legacy) transaction IDs to address outputs in transactions. It is
calculate
I think this is a good way to handle things, but as you say, it is a hard
fork.
CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
fix malleability once and for all.
This has the effect of doubling the size of the UTXO database. At minimum,
there needs to be a legacy txid
Checkpoints will be replaced by compiled-in 'at THIS timestamp the main chain
had THIS much proof of work.'
That is enough information to prevent attacks and still allow optimizations
like skipping signature checking for ancient transactions.
I don't think anybody is proposing replacing checkpo
On Wed, May 13, 2015 at 1:26 PM, Alex Mizrahi
wrote:
> He tries to investigate, and after some time discovers that his router (or
> his ISP's router) was hijacked. His Bitcoin node couldn't connect to any of
> the legitimate nodes, and thus got a complete fake chain from the attacker.
> Bitcoins
I think this needs more details before it gets a BIP number; for example,
which opcodes does this affect, and how, exactly, does it affect them? Is
the merkle root in the block header computed using normalized transaction
ids or normalized ids?
I think there might actually be two or three or four
> I don't really see how you can protect against total isolation of a node
> (POS or POW). You would need to find an alternative route for the
> information.
>
"Alternative route for the information" is the whole point of weak
subjectivity, no?
PoS depends on weak subjectivity to prevent "long te
Glad you like it, I was afraid that I missed something obvious :-)
The points the two of you raised are valid and I will address them as soon
as possible. I certainly will implement this proposal so that it becomes
more concrete, but my C++ is a bit rusty and it'll take some time, so I
wanted to g
On Tue, May 12, 2015 at 7:48 PM, Adam Back wrote:
> I think its fair to say no one knows how to make a consensus that
> works in a decentralised fashion that doesnt weaken the bitcoin
> security model without proof-of-work for now.
>
Yes.
> I am presuming Gavin is just saying in the context of
On Wed, May 13, 2015 at 4:24 PM, Christian Decker <
decker.christ...@gmail.com> wrote
> It does and I should have mentioned it in the draft, according to my
> calculations a mapping legacy ID -> normalized ID is about 256 MB in size,
> or at least it was at height 330'000, things might have change
I think this hardfork is dead-on-arrival given the ideas for OP_CHECKSIG
softforking. Instead of referring to previous transactions by a normalised
hash, it makes better sense to simply change the outpoints in the signed data
and allow nodes to hotfix dependent transactions when/if they are mall
Normalized transaction ids are only effectively non-malleable when all
inputs they refer to are also non-malleable (or you can have malleability
in 2nd level dependencies), so I do not believe it makes sense to allow
mixed usage of the txids at all. They do not provide the actual benefit of
guarant
I hope to keep continuing this conversations. Pardon my absence, but I
don't alway feel like I have much to contribute especially if it's not
techincal.
On my part I have been a proponent, of an alterrnativ consensus, that
begins shifting away from teh current cooinbase reward system in order to
r
If the inputs to my transaction have been long confirmed I can be
reasonably safe in assuming that the transaction hash does not change
anymore. It's true that I have to be careful not to build on top of
transactions that use legacy references to transactions that are
unconfirmed or have few confir
On Wed, May 13, 2015 at 6:14 PM, Pieter Wuille
wrote:
> Normalized transaction ids are only effectively non-malleable when all
> inputs they refer to are also non-malleable (or you can have malleability
> in 2nd level dependencies), so I do not believe it makes sense to allow
> mixed usage of the
On Wed, May 13, 2015 at 11:04 AM, Christian Decker <
decker.christ...@gmail.com> wrote:
> If the inputs to my transaction have been long confirmed I can be
> reasonably safe in assuming that the transaction hash does not change
> anymore. It's true that I have to be careful not to build on top of
On Wed, May 13, 2015 at 8:40 PM Pieter Wuille
wrote:
> On Wed, May 13, 2015 at 11:04 AM, Christian Decker <
> decker.christ...@gmail.com> wrote:
>
>> If the inputs to my transaction have been long confirmed I can be
>> reasonably safe in assuming that the transaction hash does not change
>> anymo
On Wed, May 13, 2015 at 12:14 PM, Christian Decker <
decker.christ...@gmail.com> wrote:
>
> On Wed, May 13, 2015 at 8:40 PM Pieter Wuille
> wrote:
>
>> On Wed, May 13, 2015 at 11:04 AM, Christian Decker <
>> decker.christ...@gmail.com> wrote:
>>
>>> If the inputs to my transaction have been long
Thank you for your response, that does make sense. It's going to be
interesting to follow what is going to happen!
2015-05-14 3:41 GMT+12:00 Gavin Andresen :
> On Tue, May 12, 2015 at 7:48 PM, Adam Back wrote:
>
>> I think its fair to say no one knows how to make a consensus that
>> works in a d
After more thought, I think I came up with a clearer description of the
recursive version.
The simple definition is that the hash for the new signature opcode should
simply assume that the normalized txid system was used since the
beginning. All txids in the entire blockchain should be replaced w
On Wed, May 13, 2015 at 1:27 PM, Tier Nolan wrote:
> After more thought, I think I came up with a clearer description of the
> recursive version.
>
> The simple definition is that the hash for the new signature opcode should
> simply assume that the normalized txid system was used since the
> beg
On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille
wrote:
>
> This was what I was suggesting all along, sorry if I wasn't clear.
>
>
That's great. So, basically the multi-level refund problem is solved by
this?
--
One dashbo
On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen wrote:
> I think long-term the chain will not be secured purely by proof-of-work. I
> think when the Bitcoin network was tiny running solely on people's home
> computers proof-of-work was the right way to secure the chain, and the only
> fair way to
On Wed, May 13, 2015 at 1:32 PM, Tier Nolan wrote:
>
> On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille
> wrote:
>
>>
>> This was what I was suggesting all along, sorry if I wasn't clear.
>>
>> That's great. So, basically the multi-level refund problem is solved by
> this?
>
Yes. So to be clear,
On Wed, May 13, 2015 at 12:31 PM, Alex Mizrahi wrote:
> But this matters if a new node has access to the globally strongest chain.
> If attacker is able to block connections to legitimate nodes, a new node
> will happily accept attacker's chain.
If you get isolated from the network you may not ge
On 11 May 2015 at 18:28, Thomas Voegtlin wrote:
> The discussion on block size increase has brought some attention to the
> other elephant in the room: Long-term mining incentives.
>
> Bitcoin derives its current market value from the assumption that a
> stable, steady-state regime will be reache
> increasing the block size is simply not a solution, it's just kicking
> the can down the road (while reducing the incentives to deploy real
> solutions like payment channels).
Placing hard limits on blocksize is not the right solution. There are still
plenty of options to be explored to increase
On Wed, May 13, 2015 at 5:48 PM, Aaron Voisine wrote:
> We have $3billion plus of value in this system to defend. The safe,
> conservative course is to increase the block size. Miners already have an
> incentive to find ways to encourage higher fees and we can help them with
> standard recommend
Conservative is a relative term. Dropping transactions in a way that is
unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
increasing the blocksize, drastic as it is, is the more conservative
choice. I would recommend that the fork take effect when some specific
large super
On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine wrote:
> Conservative is a relative term. Dropping transactions in a way that is
> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
> increasing the blocksize, drastic as it is, is the more conservative choice.
>
Transacti
> by people and businesses deciding to not use on-chain settlement.
I completely agree. Increasing fees will cause people voluntary economize
on blockspace by finding alternatives, i.e. not bitcoin. A fee however is a
known, upfront cost... unpredictable transaction failure in most cases will
be a
> I concede the point. Perhaps a flag date based on previous observation of
network upgrade rates with a conservative additional margin in addition to
supermajority of mining power.
It occurs to me that this would allow for a relatively small percentage of
miners to stop the upgrade if the flag da
40 matches
Mail list logo
