I was thinking about a change to the rules for distinguishing between forks
and maybe a BIP..
*Summary*
- Low POW headers should be broadcast by the network
If a header has more than 1/64 of the POW of a block, it should be
broadcast. This provides information on which fork is getting most of
On Wed, Jul 24, 2013 at 10:42 AM, Peter Todd p...@petertodd.org wrote:
Please provide equations and data justifying the 'magic constants' in
this proposal.
The are a range of workable values. Ideally, there would first need to be
agreement on the general principle.
Distributing headers with
On Sun, Jul 28, 2013 at 7:42 PM, John Dillon
john.dillon...@googlemail.comwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, Jul 24, 2013 at 11:55 AM, Tier Nolan tier.no...@gmail.com wrote:
Distributing headers with 1/64 of the standard POW means that a header
would
On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo bitcoin-l...@bluematt.mewrote:
Relay node details:
* The relay nodes do some data verification to prevent DoS, but in
order to keep relay fast, they do not fully verify the data they are
relaying, thus YOU SHOULD NEVER mine a block building on top
On Tue, Dec 24, 2013 at 8:52 AM, Jeremy Spilman jer...@taplink.co wrote:
Are there any past instances of applications hijacking or interfacing with
the exiting p2p messages, or abusing 'getaddr' functionality? Are there
any guidelines on this, or should there be?
There was a BIP by Stefan
The random number that the buyer uses could be generated from a root key
too.
This would allow them to regenerate all random numbers that they used and
recreate their receipts. The master root would have to be stored on your
computer though.
The payment protocol is supposed to do something like
On Mon, Feb 10, 2014 at 7:47 PM, Oliver Egginger bitc...@olivere.de wrote:
As I understand this attack someone renames the transaction ID before
being confirmed in the blockchain. Not easy but if he is fast enough it
should be possible. With a bit of luck for the attacker the new
transaction
On Mon, Apr 7, 2014 at 8:50 PM, Tamas Blummer ta...@bitsofproof.com wrote:
You have to load headers sequantially to be able to connect them and
determine the longest chain.
The isn't strictly true. If you are connected to a some honest nodes, then
you could download portions of the chain and
be used with the getheaders message and if the new peer is on a
different chain, then it will just send you the headers starting at the
genesis block.
If that happens, you need to download the entire chain from that peer and
see if it is better than your current best.
*From:* Tier Nolan tier.no
Error correction is an interesting suggestion.
If there was 1 nodes and each stored 0.1% of the blocks, at random,
then the odds of a block not being stored is 45 in a million.
Blocks are stored on average 10 times, so there is already reasonable
redundancy.
With 1 million blocks, 45 would
On Thu, Apr 10, 2014 at 7:32 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
If you trust hashrate for determining which UTXO set is valid, a 51%
attack becomes worse in that you can be made to believe a version of
history which is in fact invalid.
If there are invalidation proofs, then this
How does this system handle problems with the lower chains after they have
been locked-in?
The rule is that if a block in the child chain is pointed to by its parent,
then it effectively has infinite POW?
The point of the system is that a node monitoring the parent chain only has
to watch the
On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd p...@petertodd.org wrote:
Of course, in reality smaller miners can just mine on top of block headers
and include no transactions and do no validation, but that is extremely
harmful to the security of Bitcoin.
I don't think it reduces security much.
On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak st...@gk2.sk wrote:
Setting the gap limit to high is just a small extra cost in that case.
Not if you have 100 accounts on 10 different devices.
I meant for a merchant with a server that is handing out hundreds of
addresses.
The point is to
An interesting experiment would be a transaction proof of publication
chain.
Each transaction would be added to that chain when it is received. It
could be merge mined with the main chain.
If the size was limited, then it doesn't even require spam protection.
Blocks could be discouraged if
On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@gmail.comwrote:
You can see me proposing this kind of thing in a number of places (e.g.
http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt p2pool
only forces the subsidy today, but the same mechnism could instead
force
This is a BIP to allow the spender to choose one of multiple standard
scripts to use for spending the output.
https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
This is required as part of the atomic cross chain transfer protocol. It
is required so that outputs can be retrieved, if
On Fri, Apr 25, 2014 at 8:18 PM, Luke-Jr l...@dashjr.org wrote:
This one looks entirely useless (it cannot be made secure)
The hash locking isn't to prevent someone else stealing your coin. Once a
user broadcasts a transaction with x in it, then everyone has access to x.
It is to release the
to verify a script is present in the transaction (except
that the output actually exists).
A soft fork that expands P2SH functionality would be even better, but I
would rather not let the best be the enemy of the good.
Luke
On Friday, April 25, 2014 6:49:35 PM Tier Nolan wrote:
This is a BIP
On Fri, Apr 25, 2014 at 8:58 PM, Peter Todd p...@petertodd.org wrote:
Keep in mind that P2SH redeemScripts are limited to just 520 bytes;
there's going to be many cases where more complex transactions just
can't be encoded in P2SH at all.
True. Having said that, this is just a change to
On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr l...@dashjr.org wrote:
They define standard for interoperability between
software. So, if you want nodes to relay these transactions, you need to
convince them, not merely write a BIP for the transaction format.
I agree with you in theory, each miner
On Fri, Apr 25, 2014 at 10:14 PM, Peter Todd p...@petertodd.org wrote:
Along those lines, rather than doing up yet another format specific type
as Tier Nolan is doing with his BIP, why not write a BIP looking at how
the IsStandard() rules could be removed?
Removal of isStandard() would
Maybe the solution is to have a defined way to import an unknown wallet?
This means that the gap space and a search ordering needs to be defined.
Given a blockchain and a root seed, it should be possible to find all the
addresses for that root seed.
The hierarchy that the wallet actually uses
Due to popular demand, I have created a BIP for cross chain atomic
transfers.
Unlike the previous version, this version only requires hash locking. The
previous version required a selector transaction based on if statements.
OP_HASH160 OP_EQUAL_VERIFY [public key] OP_CHECKSIG
On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr l...@dashjr.org wrote:
Instead of TX0, TX1, etc, can you put some kind of meaningful identifier
for
these transactions?
Sorry, that is the names come from the original thread, where I was
outlining the idea. I updated the names.
TX1 and TX2
at 9:48 PM, Tier Nolan tier.no...@gmail.com wrote:
On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr l...@dashjr.org wrote:
Instead of TX0, TX1, etc, can you put some kind of meaningful identifier
for
these transactions?
Sorry, that is the names come from the original thread, where I
On Fri, Apr 11, 2014 at 5:54 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
For the non-error-coded case I believe nodes
with random spans of blocks works out asymptotically to the same
failure rates as random.
If each block is really 512 blocks in sequence, then each slot is more
likely to
I created a draft BIP detailing a way to add auxiliary headers to Bitcoin
in a bandwidth efficient way. The overhead per auxiliary header is only
around 104 bytes per header. This is much smaller than would be required
by embedding the hash of the header in the coinbase of the block.
It is a
.
The private key for the output would be known. However, miners who mine
version 2 blocks wouldn't be able to spend them early.
On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan tier.no...@gmail.com wrote:
I created a draft BIP detailing a way to add auxiliary headers to Bitcoin
in a bandwidth efficient
, Tier Nolan tier.no...@gmail.com wrote:
I made some changes to the draft. The merkleblock now has the auxiliary
header information too.
There is a tradeoff between overhead and delayed transactions. Is 12.5%
transactions being delayed to the next block unacceptable? Would adding
I updated the BIP to cover only the specification of the transactions that
need to be added. I will create a network BIP tomorrow.
On Mon, Nov 10, 2014 at 11:42 AM, Tier Nolan tier.no...@gmail.com wrote:
The aheaders message is required to make use of the data by SPV clients.
This could
to mine version 3 blocks. I could
add a new field to the getblocktemplate that has the 2 transactions ready
to go.
What do pools actually use for generating blocks. I assume it's custom
code but that they use (near) standard software for the memory pool?
On Mon, Nov 10, 2014 at 11:39 PM, Tier Nolan
One of the suggestions to avoid the problem of fees going to zero is
assurance contracts. This lets users (perhaps large merchants or
exchanges) pay to support the network. If insufficient people pay for the
contract, then it fails.
Mike Hearn suggests one way of achieving it, but it doesn't
In terms of miners, a strong supermajority is arguably sufficient, even 75%
would be enough.
The near total consensus required is merchants and users. If (almost) all
merchants and users updated and only 75% of the miners updated, then that
would give a successful hard-fork.
On the other hand,
On Wed, May 6, 2015 at 8:37 AM, Jorge Timón jti...@jtimon.cc wrote:
This gives you less flexibility and I don't think it's necessary.
Please let's try to avoid this if it's possible.
It is just a switch that turns on and off the new mode.
In retrospect, it would be better to just up the
On Wed, May 6, 2015 at 11:12 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
Personally, I'm rather strongly against any commitment to a block size
increase in the near future.
Miners can already soft-fork to reduce the maximum block size. If 51% of
miners agree to a 250kB block size, then
On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
The point of the hard block size limit is exactly because giving miners
free rule to do anything they like with their blocks would allow them to
do any number of crazy attacks. The incentives for miners to pick block
Just to clarify the process.
Pledgers create transactions using the following template and broadcast
them. The p2p protocol could be modified to allow this, or it could be a
separate system.
*Input: 0.01 BTC*
*Signed with SIGHASH_ANYONE_CAN_PAY*
*Output 50BTC*
*Paid to: 1 million
I think that should be greater than in the comparison? You want it to fail
if the the height of the UTXO plus the sequence number is greater than the
spending block's height.
There should be an exception for final inputs. Otherwise, they will count
as relative locktime of 0x. Is this
On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote:
The soft-limit is there miners themselves produce smaller blocks; the
soft-limit does not prevent other miners from producing larger blocks.
I wonder if having a miner flag would be good for the network.
Clients for general
On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
RE: fixing sigop counting, and building in UTXO cost: great idea! One of
the problems with this debate is it is easy for great ideas get lost in all
the noise.
If the UTXO set cost is built in, UTXO database
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
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 =
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
On Tue, May 12, 2015 at 6:16 PM, Peter Todd p...@petertodd.org wrote:
Lots of people are tossing around ideas for partial archival nodes that
would store a subset of blocks, such that collectively the whole
blockchain would be available even if no one node had the entire chain.
A compact
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 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?
by the network should be uniform, and should
remain uniform as the blockchain grows; ideally it you shouldn't need
to update your state to know what blocks a peer will store in the
future, assuming that it doesn't change the amount of data its
planning to use. (What Tier Nolan proposes sounds like it fails
On Fri, May 15, 2015 at 10:54 AM, s7r s...@sky-ip.org wrote:
Hello,
How will this exactly be safe against:
a) the malleability of the parent tx (2nd level malleability)
The signature signs everything except the signature itself. The normalized
txid doesn't include that signature, so
On Sat, May 16, 2015 at 1:22 AM, Rusty Russell ru...@rustcorp.com.au
wrote:
Some tweaks:
1) Nomenclature: call tx_size tx_cost and real_size tx_bytes?
Fair enough.
2) If we have a reasonable hard *byte* limit, I don't think that we need
the MAX(). In fact, it's probably OK to go
On Sat, May 9, 2015 at 4:08 AM, Peter Todd p...@petertodd.org wrote:
I wonder if having a miner flag would be good for the network.
Makes it trivial to find miners and DoS attack them - a huge risk to the
network as a whole, as well as the miners.
To mitigate against this, two chaintips
On Sat, May 16, 2015 at 5:39 AM, Stephen stephencalebmo...@gmail.com
wrote:
I think this could be mitigated by counting confirmations differently. We
should think of confirmations as only coming from blocks following the
miners' more strict rule set. So if a merchant were to see payment for
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
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
On Mon, May 18, 2015 at 2:42 AM, Rusty Russell ru...@rustcorp.com.au
wrote:
OK. Be nice if these were cleaned up, but I guess it's a sunk cost.
Yeah.
On the plus side, as people spend their money, old UTXOs would be used up
and then they would be included in the cost function. It is only
On Tue, May 19, 2015 at 9:28 AM, Christian Decker
decker.christ...@gmail.com wrote:
Thanks Stephen, I hadn't thought about BIP 34 and we need to address this
in both proposals. If we can avoid it I'd like not to have one
transaction hashed one way and other transactions in another way.
The
On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
How about this for mitigating this potential attack:
1. Limit the memory pool to some reasonable number of blocks-worth of
transactions (e.g. 11)
2. If evicting transactions from the memory pool, prefer to evict
On Fri, Jun 19, 2015 at 5:42 PM, Eric Lombrozo elombr...@gmail.com wrote:
If we want a non-repudiation mechanism in the protocol, we should
explicitly define one rather than relying on “prima facie” assumptions.
Otherwise, I would recommend not relying on the existence of a signed
transaction
I agree giving notice that the change is going to happen is critical for a
hard fork. If miners vote in favor, they need to give people time to
upgrade (or to decide to reject the fork).
The BIP 100 proposal is that no change will happen until a timestamp is
reached. It isn't clear exactly how
I think it would be better to have the deadlines set as block counts. That
eliminates the need to use the median time mechanism.
The deadline could be matched to a start-line. The definition would then
be something like
BIP 105
Start block: 325000
End block: 35
Activation: 750 of 1000
the final deadline is passed,
the expected mask is zeros.
On Wed, May 27, 2015 at 11:15 AM, Jorge Timón jti...@jtimon.cc wrote:
On May 27, 2015 11:35 AM, Tier Nolan tier.no...@gmail.com wrote:
Was the intention to change the 95% rule. You need 750 of the last 1000
to activate and then must
This could cause legacy transactions to become unspendable.
A new transaction version number should be used to indicate the change of
the field from sequence number to relative lock time.
Legacy transactions should not have the rule applied to them.
On Wed, May 27, 2015 at 9:18 AM, Gregory
On Fri, May 29, 2015 at 12:26 PM, Mike Hearn m...@plan99.net wrote:
IMO it's not even clear there needs to be a size limit at all. Currently
the 32mb message cap imposes one anyway
If the plan is a fix once and for all, then that should be changed too. It
could be set so that it is at least
On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
But if there is still no consensus among developers but the bigger blocks
now movement is successful, I'll ask for help getting big miners to do the
same, and use the soft-fork block version voting mechanism to
On Fri, May 29, 2015 at 5:39 PM, Raystonn . rayst...@hotmail.com wrote:
Regarding Tier’s proposal: The lower security you mention for extended
blocks would delay, possibly forever, the larger blocks maximum block size
that we want for the entire network. That doesn’t sound like an optimal
Can you update it so that it only applies to transactions with version
number 3 and higher. Changing the meaning of a field is exactly what the
version numbers are for.
You could even decode version 3 transactions like that.
Version 3 transactions have a sequence number of 0x and the
On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach m...@friedenbach.org
wrote:
Why 3? Do we have a version 2?
I meant whatever the next version is, so you are right, it's version 2.
As for doing it in serialization, that would alter the txid making it a
hard fork change.
The change is
I am glad to see the transaction version number increase. The commit
doesn't update the default transaction version though. The node would
still produce version 1 transactions.
Does the reference client already produce transactions with final sequence
numbers? If so, then they will be valid
On Fri, May 29, 2015 at 3:09 PM, Tier Nolan tier.no...@gmail.com wrote:
On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
But if there is still no consensus among developers but the bigger
blocks now movement is successful, I'll ask for help getting big miners
72 matches
Mail list logo
