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 core
On Wed, May 13, 2015 at 10:49 AM, Thomas Voegtlin thom...@electrum.org
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
On Wed, May 13, 2015 at 11:31 AM, Alex Mizrahi alex.mizr...@gmail.com
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
On Wed, May 13, 2015 at 6:19 AM, Daniel Kraft d...@domob.eu 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
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
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
On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell gmaxw...@gmail.com 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 =
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,
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
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
On Wed, May 13, 2015 at 1:26 PM, Alex Mizrahi alex.mizr...@gmail.com
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
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
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
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
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 term
On Wed, May 13, 2015 at 8:40 PM Pieter Wuille pieter.wui...@gmail.com
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
On Wed, May 13, 2015 at 1:27 PM, Tier Nolan tier.no...@gmail.com 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
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
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
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 gavinandre...@gmail.com:
On Tue, May 12, 2015 at 7:48 PM, Adam Back a...@cypherspace.org wrote:
I think its fair to say no one knows how
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 pieter.wui...@gmail.com
wrote:
On Wed, May 13, 2015 at 11:04 AM, Christian Decker
decker.christ...@gmail.com wrote:
If the inputs to my transaction have
On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille pieter.wui...@gmail.com
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?
On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen gavinandre...@gmail.com 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
On Tue, May 12, 2015 at 7:48 PM, Adam Back a...@cypherspace.org 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
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 changed a
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
On Wed, May 13, 2015 at 5:48 PM, Aaron Voisine vois...@gmail.com 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
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
On Wed, May 13, 2015 at 12:31 PM, Alex Mizrahi alex.mizr...@gmail.com 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
On Wed, May 13, 2015 at 1:32 PM, Tier Nolan tier.no...@gmail.com wrote:
On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille pieter.wui...@gmail.com
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
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
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
On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine vois...@gmail.com 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
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
On 11 May 2015 at 18:28, Thomas Voegtlin thom...@electrum.org 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
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
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
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
On Wed, May 13, 2015 at 6:14 PM, Pieter Wuille pieter.wui...@gmail.com
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
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
40 matches
Mail list logo
