Sorry for the duplication Amir, I meant to send this to everyone:
BitTorrent might be an example to look to here. It's a peer-to-peer network
that has undergone many significant protocol upgrades over the years while
maintaining compatibility. More recent clients have had the ability to
expose
On Tue, Jun 19, 2012 at 10:33 AM, Alan Reiner etothe...@gmail.com wrote:
I hope that someone else here would chime in on the issue raised in the
thread, about using a tree-structure that has multiple valid
configurations for the same set of unspent-TxOuts. If you use any
binary tree, you
the necessary dependencies installed.
I hope that others find this useful. I have submitted these scripts as
pull-request #1597 on github.
Cheers,
Mark Friedenbach
--
Live Security Virtual Conference
Exclusive live event
Running a concurrent Mantis tracker would be confusing and fragment the
development pathway. We have an issue tracker; it's on github.
What's being talked about here are two separate things. Jenkins is a
continuous integration system. It can be configured to run the suite of
unit tests,
My only comment is that it should be called escheatment, not demurrage ;)
It's relation to demurrage is only that it might be desirable to garbage
collect decayed bit-dust. We looked at it early-on in the Freicoin
development, but rejected it as a possibility due to reasons others have
mentioned,
Alan's UTxO meta-chain proposal becomes vastly easier to do now that
ultraprune is merged. That would allow the Satoshi client to know it's
wallet balance and operate with a =SPV level of security during the
initial block download, and keep them on the path of becoming a full node.
If users can
or nRefHeight is what we call this
value internally, but blocktime or blockheight would work as well.
Github is currently down, so I apologize if a suitable field has already
been added.
Cheers,
Mark Friedenbach
[1] http://freico.in/ Freicoin: a P2P digital currency delivering freedom
from usury
I'm not sure I understand the need for hard forks. We can get through this
crisis by mining pool collusion to prevent forking blocks until there is
widespread adoption of patched clients.
Proposal:
1) Patch the pre-0.8 branches to support an increased lock count, whatever
number is required to
and give them time to react, then move on. Let's
not codify the bug in the protocol.
Mark
On Wed, Mar 13, 2013 at 10:58 AM, Pieter Wuille pieter.wui...@gmail.comwrote:
On Wed, Mar 13, 2013 at 10:41:29AM -0700, Mark Friedenbach wrote:
4) At some point in the future once we've crossed an acceptable
If you're considering a datagram protocol, you might be interested in some
more modern alternatives to UDP:
UDT: Breaking the Data Transfer Bottleneck
http://udt.sourceforge.net/
Stream Control Transmission Protocol
http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
On Sat, Mar
. Multiple UDT flows can share a single UDP
port, thus a firewall can open only one UDP port for all UDT connections.
The latter appears not so friendly to NAT.
On 3/23/2013 3:30 PM, Mark Friedenbach wrote:
If you're considering a datagram protocol, you might be interested in
some more
is to give
network the bytes type, but defining a UUID message type is also
possible. In either case bitcoin mainnet would be the default, so the
extra 12 bytes (vs: main or test) would only be an issue for
alt-chains or colored coins.
Kind regards,
Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Jun 01, 2013 at 10:32:07PM -0400, Gavin wrote:
Feels like a new opcode might be better.
Eg data 100 OP_NOP1
... Where op_nop1 is redefined to be 'verify depth' ...
I would suggest the more general 'push depth onto stack'. You can then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John,
What you are recommending is a drastic change that the conservative
bitcoin developers probably wouldn't get behind (but let's see). However
proof-of-stake voting on protocol soft-forks has vast implications even
beyond the block size limit.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/18/13 8:09 PM, John Dillon wrote:
On the other hand, a tx with some txin proofs can be safely relayed by SPV
nodes, an interesting concept. Do the UTXO commitment people have
keeping proof
size small in mind?
More than a kilobyte, probably
cryptographic
protocols expressed as bitcoin scripts. Input from any of the resident
cryptographers would be very appreciated.
Happy hacking,
Mark Friedenbach
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG
Getting OT...
For a while I've wanted to combine one of these mnemonic code generators
with an NLP engine to do something like output a short story as the
passphrase, even a humorous onem with the key encoded in the story
itself (remember the gist of the story and that's sufficient to
reconstruct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Also somewhat related, I have been looking for some time now to
abstract out the UTXO and block databases so that a variety of
key/value stores could be used as a backend, configured by a command
line parameter. In particular, it would be interesting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There's no reason the signing can't be done all at once. The wallet
app would create and sign three transactions, paying avg-std.D, avg,
and avg+std.D fee. It just waits to broadcast the latter two until it
has to.
On 10/25/13 5:02 AM, Andreas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If I understand the code correctly, it's not about rejecting blocks.
It's about noticing that 50% of recent blocks are declaring a version
number that is meaningless to you. Chances are, there's been a soft
fork and you should upgrade.
On 10/30/13
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Or SIGHASH of a transaction spending those coins or updating the SIN...
On 11/2/13 2:14 PM, Johnathan Corgan wrote: On 11/01/2013 10:01 PM,
bitcoingr...@gmx.com wrote:
Server provides a token for the client to sign.
Anyone else concerned about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 10:16 AM, Peter Todd wrote:
Again, the right way to do this is define the standard to use the
last txout so that midstate compression can be applied in the
future. We can re-use this for merge-mining and other commitments
easily by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 11:38 AM, Mike Hearn wrote:
The Merkle branch doesn't get stored indefinitely though, whereas
the coinbase hash does. The data stored in the coinbase [output]
can always just be the 256-bit root hash truncated to less.
I doubt the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For this reason I'm in favor of skipping mBTC and moving straight to
uBTC. Having eight, or even five decimal places is not intuitive to
the average user. Two decimal places is becoming standard for new
national currencies, and we wouldn't be too far
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/14/13 2:00 PM, Alan Reiner wrote:
Just keep in mind it will be a little awkward that 54.3 uBTC is
the smallest unit that can be transferred [easily] and the standard
fees are 500 uBTC.It's not a deal breaker, it's just something
that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/14/13 3:01 PM, Luke-Jr wrote:
I think we all know the problems with the term address. People
naturally compare it to postal addresses, email addresses, etc,
which operate fundamentally different. I suggest that we switch to
using invoice id
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/13 4:41 PM, Drak wrote:
For years, people had a problem with email address, instead
using email number but they got there eventually. Most people
nowadays use email address So payment address or bitcoin
address make better sense here
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/13 5:19 PM, Drak wrote:
Maybe, but again from the user's perspective they pay someone, and
they receive money - just like you do with paypal using an email
address. The technical bits in the middle dont matter to the user
and trying to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/13/2013 09:26 AM, Mike Hearn wrote:
I'm thinking about a use case I hope will become common next year
- pastebin style hosting sites for payment requests. Like, if I as
a regular end user wish to use the payment protocol, I could just
upload
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Transactions != blocks. There is no need for a merge block.
You are free to trade transactions off-line, so long as you are
certain the other parties are not secretly double-spending coins they
send you on the block chain.
When connection to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello fellow bitcoin developers. Included below is the first draft of
a BIP for a new Merkle-compressed data structure. The need for this
data structure arose out of the misnamed Ultimate blockchain
compression project, but it has since been
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
JSON-RPC is a huge security risk. It's perfectly reasonable that
enabling it requires some technical mumbo-jumbo.
Are there specific configuration settings that you would like to see
exposed by the GUI?
On 12/19/2013 11:49 PM, Chris Evans wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jeremy, Let's give a preview of the application-oriented BIPs I
mentioned:
Stateless validation and mining involves prefixing transaction and
block messages with proofs of their UTxO state changes. These are the
operational proofs I describe in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Sorry Peter, this was meant for the whole list:)
On 12/20/2013 05:17 AM, Peter Todd wrote:
I've thought about this for awhile and come to the conclusion that
UTXO commitments are a really bad idea. I myself wanted to see them
implemented about a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/20/2013 11:48 AM, Gregory Maxwell wrote:
A couple very early comments— I shared some of these with you on
IRC but I thought I'd post them to make them more likely to not get
lost.
I got the inputs from IRC, but thank you for posting to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/2014 10:13 AM, Peter Todd wrote:
On Sun, Jan 05, 2014 at 07:43:58PM +0100, Thomas Voegtlin wrote:
I have written a Python-levelDB implementation of this UTXO
hashtree, which is currently being tested, and will be added to
Electrum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/2014 10:31 PM, Thomas Voegtlin wrote:
You are right. The 256-way branching follows from the fact that the
tree was implemented using a key-value database operating with byte
strings (leveldb). With this implementation constraint, a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/15/2014 04:05 PM, Jeremy Spilman wrote:
Might I propose reusable address.
Say it like it is. This is the only suggestion so far that I really like.
No amount of finger wagging got people to stop using the block chain
for data storage, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/17/2014 01:15 AM, Mike Hearn wrote:
I must say, this shed is mighty fine looking. It'd be a great place
to store our bikes. But, what colour should we paint it?
How about we split the difference and go with privacy address?
As
Too close
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CPFP is *extremely* important. People have lost money because this
feature is missing. I think it's critical that it makes it into 0.9
If I get a low-priority donation from a blockchain.info wallet, that
money can disappear if it doesn't make it into
On 01/18/2014 03:05 AM, Wladimir wrote:
On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla
ABISprotocol hat: on
regarding:
stuff not getting into blockchain in a day's time,
microdonations not facilitated as much as they could be,
Please point to your pull requests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since you are taking the hash of Unicode data, I would strongly
recommend using a canonical form, e.g. Normalized Form C.
On 01/20/2014 09:42 AM, slush wrote:
Hi all,
during recent months we've reconsidered all comments which we
received from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Proper Unicode handling is a serious issue however. You don't want
someone to move from one input method / machine to another and
suddenly find that their coins are inaccessible, because of an issue
of decomposed vs. compatibility forms or whatever.
On 02/12/2014 08:44 AM, Alan Reiner wrote:
Changing the protocol to use these static IDs is a pretty fundamental
change that would never happen in Bitcoin. But they can still be
useful at the application level to mitigate these issues.
Not to mention that it would be potentially very
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What follows is a proposed BIP for human-friendly base-32
serialization with error correction encoding. A formatted version is
viewable as part of a gist with related code:
https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki
An
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Transaction fees are a DoS mitigating cost to the person making the
transaction, but they are generally not paid to the people who
actually incur costs in validating the blockchain. Actual transaction
processing costs are an externality that is
Only if you view bitcoin as no more than a payment network.
On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote:
This is wandering far off-topic for this mailing list.
On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org wrote:
You can make the same argument against
This ship may have already sailed, but...
Using milli- and micro- notation for currency units is also not very
well supported. Last time this thread was active, I believe there was a
suggestion to use 1 XBT == 1 uBTC. This would bring us completely within
the realm of supported behavior in
Timon, and Mark Friedenbach. It
is believed that the first explanation of this general idea is due to
Andrew Miller in his 7 Aug 2012 forum post titled The High-Value-Hash
Highway[2].
[1]http://sourceforge.net/p/bitcoin/mailman/message/32108143/
[2]https://bitcointalk.org/index.php?topic=98986.0
Please, by all means: ignore our well-reasoned arguments about
externalized storage and validation cost and alternative solutions.
Please re-discover how proof of publication doesn't require burdening
the network with silly extra data that must be transmitted, kept, and
validated from now until
Jeff, there are *plenty* of places that lack local Internet access for
one or both participants.
Obviously making the case where both participants lack access to the
bitcoin network is difficult to secure, but not impossible (e.g. use a
telephany-based system to connect to a centralized
This isn't distributed-systems-development, it is bitcoin-development.
Discussion over chain parameters is a fine thing to have among people
who are interested in that sort of thing. But not here.
On 03/23/2014 04:17 PM, Troy Benjegerdes wrote:
I find it very irresponsible for Bitcoiners to on
On 03/24/2014 01:34 PM, Troy Benjegerdes wrote:
I'm here because I want to sell corn for bitcoin, and I believe it will be
more profitable for me to do that with a bitcoin-blockchain-based system
in which I have the capability to audit the code that executes the trade.
A discussion over such a
I'm afraid I'm going to be the jerk that requested more details and then
only nitpicks seemingly minor points in your introduction. But its
because I need more time to digest the contents of your proposal. Until
then:
But moving value between chains is inconvenient; right now moving
value
Flavien, capital is wealth or resources available for the stated purpose
of the company. These bitcoins represent nothing more than a speculative
floor owned by the investors, not the company.
On 04/07/2014 07:00 AM, Flavien Charlon wrote:
Jorge, they'd have to be. Otherwise, assuming the price
Right now running a full-node on my home DSL connection (1Mbps) makes
other internet activity periodically unresponsive. I think we've already
hit a point where resource requirements are pushing out casual users,
although of course we can't be certain that accounts for all lost nodes.
On
On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
That is an implementation issue— mostly one that arises as an indirect
consequence of not having headers first and the parallel fetch, not a
requirements issue.
Oh, absolutely. But the question why are people not running full
nodes? has to do with
On 04/07/2014 12:00 PM, Tamas Blummer wrote:
Once a single transaction in pruned in a block, the block is no longer
eligible to be served to other nodes.
Which transactions are pruned can be rather custom e.g. even depending
on the wallet(s) of the node,
therefore I guess it is more handy to
On 04/07/2014 12:20 PM, Tamas Blummer wrote:
Validation has to be sequantial, but that step can be deferred until the
blocks before a point are loaded and continous.
And how do you find those blocks?
I have a suggestion: have nodes advertise which range of full blocks
they possess, then you
On 04/09/2014 09:09 AM, Tamas Blummer wrote:
Yes, SPV is a sufficient API to a trusted node to build sophisticated
features not offered by the core.
SPV clients of the border router will build their own archive and
indices based on their interest of the chain therefore the
border router core
I've advocated for this in the past, and reasonable counter-arguments I
was presented with are: (1) bittorrent is horribly insecure - it would
be easy to DoS the initial block download if that were the goal, and (2)
there's a reasonable pathway to doing this all in-protocol, so there's
no reason
You took the quote out of context:
a full node can copy the chain state from someone else, and check that
its hash matches what the block chain commits to. It's important to
note that this is a strict reduction in security: we're now trusting
that the longest chain (with most proof of work)
Checkpoints will go away, eventually.
On 04/10/2014 02:34 PM, Jesus Cea wrote:
On 10/04/14 18:59, Pieter Wuille wrote:
It's important to
note that this is a strict reduction in security: we're now trusting
that the longest chain (with most proof of work) commits to a valid
UTXO set (at some
XP is no longer receiving security patches from Microsoft, and hasn't been
for some time. There are known remote exploits that aren't going to be
fixed, ever.
On Apr 16, 2014 8:15 AM, Kevin kevinsisco61...@gmail.com wrote:
On 4/16/2014 4:14 AM, Wladimir wrote:
Hello,
Today I noticed that
On 04/16/2014 09:27 AM, Kevin wrote:
Should we then add an alert message to wallet installers such as, Such
and such will not run on windows xp?
It's not really our place to police that ... plus it's perfectly safe to
be running Bitcoin Core as a full node on XP. It's just the wallet
platform that the original
vendor (MS) no longer supports themselves.
On Apr 16, 2014, at 9:35 AM, Mark Friedenbach m...@monetize.io wrote:
On 04/16/2014 09:27 AM, Kevin wrote:
Should we then add an alert message to wallet installers such as, Such
and such will not run on windows xp?
It's
On 04/16/2014 02:29 PM, Kevin wrote:
Okay, so how about an autoupdate function which pulls a work around off
the server? Sooner or later, the vulnerabilities must be faced.
NO. Bitcoin Core will never have an auto-update functionality. That
would be a single point of failure whose compromise
Not necessarily. Running a private server involves listening to the p2p
network for incoming transactions, performing validation on receipt and
organizing a mempool, performing transaction selection, and relaying
blocks to auditors - none of which is tested in a reindex.
A reindex would give you
As soon as we switch to headers
first - which will be soon - there will be no difference in propagation
time no matter how large the block is. Only 80 bites will be required to
propagate the block header which establishes priority for when the block is
fully validated.
On Apr 20, 2014 6:56 PM,
That wasn't what I was saying. Right now the primacy of a block is
determined by the time at which the `block` message is received, which
is delays due to both the time it takes to transmit the block data and
the time it takes to validate. Headers-first, on the other hand, has the
option of basing
Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin.
Unfortunately few of the alts ever figured this out.
On 04/22/2014 01:39 AM, Tamas Blummer wrote:
Extra encoding for testnet is quite useless complexity in face of many
alt chains.
BIPS should be chain agnostic.
Regards,
I think you're misunderstanding the point. The way you get IsStandard
changed is that you make an application-oriented BIP detailing the use
of some new standard transaction type (say, generalized hash-locked
transactions for atomic swaps). We then discuss that proposal for its
technical merits
There's no need to be confrontational. I don't think anyone here objects
to the basic concept of proof-of-stake. Some people, myself included,
have proposed protocols which involve some sort of proof of stake
mechanism, and the idea itself originated as a mechanism for eliminating
checkpoints,
remember who I saw discussing this idea. Might have been Vitalik
Buterin?
On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach m...@monetize.io wrote:
There's no need to be confrontational. I don't think anyone here
objects
to the basic concept of proof-of-stake. Some people, myself included
Sergio,
First of all, let's define what an SPV proof is: it is a succinct
sequence of bits which can be transmitted as part of a non-interactive
protocol that convincingly establishes for a client without access to
the block chain that for some block B, B has an ancestor A at some
specified
I would prefer to avoid. By
using back-links you make it have log(N) space usage.
On 04/26/2014 07:39 PM, Sergio Lerner wrote:
El 26/04/2014 10:43 p.m., Mark Friedenbach escribió:
Sergio,
First of all, let's define what an SPV proof is: it is a succinct
sequence of bits which can
I'm not convinced of the necessity of this idea in general, but if it
were to be implemented I would recommend serializing the nVersion field
as a VarInt (Pieter Wuille's multi-byte serialization format) and using
the remaining space of the 4 bytes as your extra nonce.
That would allow
On 04/27/2014 05:36 AM, Sergio Lerner wrote:
Without invoking moon math or assumptions of honest peers and
jamming-free networks, the only way to know a chain is valid is to
witness the each and every block. SPV nodes on the other hand,
simply trust that the most-work chain is a valid
On 04/28/2014 07:32 AM, Sergio Lerner wrote:
So you agree that: you need a periodic connection to a honest node, but
during an attack you may loose that connection. This is the assumption
we should be working on, and my use case (described in
I don't think such a pull request would be accepted. The point was to
minimize impact to the block chain. Each extras txout adds 9 bytes
minimum, with zero benefit over serializing the data together in a
single OP_RETURN.
On 05/03/2014 11:39 AM, Peter Todd wrote:
The standard format ended up
Is it more complex? The current implementation using template matching
seems more complex than `if script.vch[0] == OP_RETURN
script.vch.size() 42`
On 05/03/2014 12:08 PM, Gregory Maxwell wrote:
On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach m...@monetize.io wrote:
I don't think
I know the likelihood of this happening is slim, but if these are the
desired features we should consider switching to monotone (monotone.ca)
which has a much more flexible DAG structure and workflow built around
programmable multi-sig signing of commits. We could still maintain the
github account
The correct approach here is header hash-tree commitments which enable
compact (logarithmic) SPV proofs that elide nearly all intervening
headers since the last checkpoint. You could then query the hash tree
for references to any of the headers you actually need.
See this message for details:
Not with current script, but there are mechanisms by which you can do a
digital signature where signing two pieces of information reveals the
ECDSA k parameter, thereby allowing anyone to recover the private key
and steal the coins.
Practically speaking, these are not very safe systems to use.
Sergio, why is preventing mining pools a good thing? The issue is not
mining pools, which provide a needed service in greatly reducing
variance beyond what any proposal like this can do.
The issue is centralized transaction selection policies, which is
entirely orthogonal. And the solution
Do you need to do full validation? There's an economic cost to mining
invalid blocks, and even if that were acceptable there's really no
reason to perform such an attack. The result would be similar to a block
withholding attack, but unlike block withholding it would be trivially
detectable
Can someone explain to these guys and the public why promising to limit
yourselves to *only* a 50% chance of successfully double-spending a 6
confirm transaction is still not acceptable?
q=0.4
z=0 P=1
z=1 P=0.828861
z=2 P=0.736403
z=3 P=0.664168
z=4 P=0.603401
z=5
On 08/06/2014 11:42 AM, Peter Todd wrote:
On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
decker.christ...@gmail.com wrote:
+1 for the new field, overloading fields with new meaning is
definitely not a good idea.
To add a new field the best way to do it is create a new, parallel,
tx
On 08/06/2014 01:02 PM, Tom Harding wrote:
With first-eligible-height and last-eligible-height, creator could
choose a lifetime shorter than the max, and in addition, lock the whole
thing until some point in the future.
Note that this would be a massive, *massive* change that would
completely
On 08/06/2014 01:20 PM, Peter Todd wrote:
The general case doesn't require transmission of any merkle data; it
is derived from the tx data.
How can that possibly be the case? The information is hidden behind the
Merkle root in the transaction. The validator needs to know whether
there is an
On Sat, Aug 9, 2014 at 6:10 AM, Sergio Lerner sergioler...@certimix.com
wrote:
Hi Tim,
It's clear from the paper that the second party in the protocol can
de-anonymize the first party. So it's seems that dishonest shufflers would
prefer to be in that position in the queue.
That's not
There should not be a requirement at this level to ensure validity. That
would too constrain use cases of implementations of your protocol. It is
not difficult to imagine use cases where parties generate chained
transactions on top of unconfimed transactions. Although malleability
currently makes
Thank you Jorge for the contribution of the Stag Hunt terminology. It is
much better than a politically charged scorched earth.
On Feb 21, 2015 11:10 AM, Jorge Timón jti...@jtimon.cc wrote:
I agree scorched hearth is a really bad name for the 0 conf protocol
based on game theory. I would have
wrote:
Le 08/05/2015 22:33, Mark Friedenbach a écrit :
* For each block, the miner is allowed to select a different difficulty
(nBits) within a certain range, e.g. +/- 25% of the expected difficulty,
and this miner-selected difficulty is used for the proof of work check.
In
addition
constrains the maximum allowed block size to be within a range supported by
fees on the network, providing an emergency relief valve that we can be
assured will only be used at significant cost.
Mark Friedenbach
* There has over time been various discussions on the bitcointalk forums
about dynamically
Transactions don't expire. But if the wallet is online, it can periodically
choose to release an already created transaction with a higher fee. This
requires replace-by-fee to be sufficiently deployed, however.
On Fri, May 8, 2015 at 1:38 PM, Raystonn . rayst...@hotmail.com wrote:
I have a
Micropayment channels are not pie in the sky proposals. They work today on
Bitcoin as it is deployed without any changes. People just need to start
using them.
On May 10, 2015 11:03, Owen Gunden ogun...@phauna.org wrote:
On 05/08/2015 11:36 PM, Gregory Maxwell wrote:
Another related point
On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine vois...@gmail.com wrote:
This is a clever way to tie block size to fees.
I would just like to point out though that it still fundamentally is using
hard block size limits to enforce scarcity. Transactions with below market
fees will hang in limbo
resorting to dropping transactions after a prolonged delay.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach m...@friedenbach.org
wrote:
On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine vois...@gmail.com wrote:
This is a clever way to tie
The problems with that are larger than time being unreliable. It is no
longer reorg-safe as transactions can expire in the course of a reorg and
any transaction built on the now expired transaction is invalidated.
On Fri, May 8, 2015 at 1:51 PM, Raystonn rayst...@hotmail.com wrote:
Replace by
1 - 100 of 114 matches
Mail list logo
