It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?
Best,
Stephen
On Fri, Jun 19
capacity
limits gracefully.
Best,
Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin
to dynamically increase a
lower limit, but that there should still be a hard upper limit like 20 MB.
I think that just changing the upper limit might be simpler and better,
though.
- Stephen
fairly unlikely to get enough support to be merged into bitcoin core.
Best,
Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https
, is technically
infeasible. Miners can fill their blocks with any type of transactions,
including their own specially designed transactions. And any fees from
these transactions can be collected right back into their coinbase
transaction.
- Stephen
} CHECKSIGVERIFY
This ensures that Alice has to spend the output in the next 100 blocks or
risk it being taken from her (she just has to put an OP_TRUE on the end of
her scriptSig). So, it seems we can forget about an inverted CLTV/CSV,
great!
Best,
Stephen
that it doesn't have now, which is what we are trying to
avoid.
Best,
Stephen
On Jun 2, 2015, at 12:16 AM, Mark Friedenbach m...@friedenbach.org wrote:
You are correct! I am maintaining a 'checksequenceverify' branch in my git
repository as well, an OP_RCLTV using sequence numbers:
https
is nice.
Hopefully we can repurpose one of the OP_NOPs for CHECKLOCKTIMEVERIFY and
one for OP_CHECKSEQUENCEVERIFY. Very complementary.
Best,
Stephen
On Tue, Jun 2, 2015 at 12:16 AM, Mark Friedenbach m...@friedenbach.org
wrote:
You are correct! I am maintaining a 'checksequenceverify' branch
-featured
than just repurposing an OP_NOP to create OP_RCLTV. The benefits are
obviously that it saves transaction space by repurposing unused space, and
would likely work for most cases where an OP_RCLTV would be needed.
Best,
Stephen
On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach m...@friedenbach.org
An option would be that the height is included in the scriptSig for all
transactions, but for non-coinbase transctions, the height used is zero.
No need to add an extra field to the transaction just to include the
height. We can just add a rule that the height specified in the scriptSig
in
the
default client limit set to some higher number, and have miners agree out of
band on the latest block size limit. Or maybe even build in a way to vote into
the blockchain.
Best,
Stephen
--
One dashboard for servers
to some kind of a merklized
abstract syntax tree, but am not fully sure how that would work. Maybe someone
on here could explain it?
Best,
Stephen
On May 15, 2015, at 5:54 AM, s7r s...@sky-ip.org wrote:
Hello,
How will this exactly be safe against:
a) the malleability of the parent tx
their block creation protocol.
There are many arguments for and against changing the consensus limit on block
size. I'm simply saying that to force a marketplace for fees/block space
should not be one of them. Let the market develop on it's own.
- Stephen
On May 10, 2015, at 4:45 PM, Sergio
(such as micropayment
channels).
Best,
Stephen
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports
version 3 transactions
and the rules associated with them over time.
Best,
Stephen
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Hi Mike,
Hi Stephen,
It's an interesting idea. I'm not sure that all the combinations make
sense. Excluding the connected output script or value but still signing the
prev tx hash appears pointless: the script cannot change anyway, and you
still need to know what it is to actually calculate
Seeking feedback on a proposal that will allow a transaction signer to
explicitly specify what is to be serialized for the signature hash. The
basic idea is to make the nHashType general enough that we won't need a new
sighash flag every time a new use case comes up.
If implemented into bitcoin
You might consider the dimension taken by the cooperative mining approach of AI
Coin, an altcoin that will launch April 27. The coin is an embodiment of
principles described in my whitepaper last May, Bitcoin Cooperative Proof of
Stake.
http://arxiv.org/abs/1405.5741
Currently we do not use
with the coinbase having the same TxID referenced by the new
transaction's input. It's still a hard fork, but might be easier than
allowing the coinbase to spend prevouts. I guess, at that point though, why
not just hard fork to allow the coinbase to spend prevouts...
Best,
Stephen
On Tue, Dec 30, 2014 at 1
diary. I
plan a hard fork of the Bitcoin blockchain in early 2016, after a year of
public system testing, and conditioned on wide approval.
https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403
-Steve
Stephen L. Reed
Austin, Texas, USA
512.791.7860
.
Stephen L. Reed
Austin, Texas, USA
512.791.7860
On Friday, April 25, 2014 4:42 AM, Jeffrey Paul sn...@acidhou.se wrote:
Are proof of stake blockchains compatible with the sidechain/two-way peg system
invented by Greg (and maybe others - reports unclear)?
http://letstalkbitcoin.com/blockchain-2-0
ask you simply if creating the branch is harmful? My goal is
to develop, test and document PoS, while exploring its vulnerabilities and
fixing them in a transparent fashion.
Thanks for taking a bit of your time to read this message.
-Steve
Stephen L. Reed
Austin, Texas, USA
512.791.7860
On Wed, Mar 13, 2013 at 2:28 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
But we cannot just drop support for old nodes. It is completely
unreasonable to put the
_majority_ of the network on a fork, without even as much as a discussion
about it.
Oh, you didn't get the memo? The rules
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Stephen Pair, Co-Founder, CTO
Does *your* website accept cash? bitpay.com
[image: bitpay-small]
ABC6 C11B BF75 9E2B FC6A
On Wed, Feb 13, 2013 at 7:28 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
bunch of stuff
I understand your arguments, but don't agree with many of your conclusions.
The requirement for everyone to hear the history doesn't get talked
about much
One of the beauties of bitcoin is that the
On Wed, Feb 13, 2013 at 10:38 PM, Gregory Maxwell gmaxw...@gmail.comwrote:
On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair step...@bitpay.com wrote:
(by which I mean the fee or cost associated with the bandwidth and
validation that a transaction requires) with some amount of profit
Here are my (mostly half baked) thoughts on the payments protocol proposal.
My first observation is that the proposal is too heavily oriented around a
merchant/customer interaction. I think it's equally important to consider
the person to person scenarios. It would be very cool if people could
On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn m...@plan99.net wrote:
you may find yourself in a situation needing to parse a protobuf
message in a web browser
Nothing stops you converting them into whatever form you want on the
server side. If you don't care about the signature checking then
On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn m...@plan99.net wrote:
Second thing, it's best to carefully separate anonymity from
privacy. Privacy is supposed to be a feature of the system (it says
so in Satoshis paper) because people demand it. If I loan a tenner to
my friend and he is able to
29 matches
Mail list logo
