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
ng #1 so that your wallet software can handle hitting capacity
limits gracefully.
Best,
Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
votes to ensure a
fast confirmation time. Users are incentivized to be in agreement with miners
because the miners provide them with the confirmations they need, but fees do
not provide a great incentive for miners to be in agreement with users, and
likely won't for some time.
Best
nputs are spending? These both require information that may not be readily
available, however, and use of normalized transaction IDs is not fully
developed yet.
Best,
Stephen
> On Jun 5, 2015, at 8:12 PM, Kristov Atlas
> wrote:
>
> Hello all,
>
> I have written a draft
your wallet).
>
The idea of voting with your wallet, while appealing, 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 co
ink an idea like this has its merits, I would bet that it's
fairly unlikely to get enough support to be merged into bitcoin core.
Best,
Stephen
--
___
Bitcoin-development m
usion we came to chatting on #bitcoin-wizards the
other day. I now think that this could be useful to dynamically increase a
lower limit, but that there should still be a hard upper limit like 20 MB.
I think
x27;s pub} CHECKSIGVERIFY
ELSE
{curr_height + 100} CLTV {B's pub} 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 see
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 wrote:
>
> You are correct! I am maintaining a 'checksequenceverify' branch in my git
> repository as well, an OP_RCLTV using sequence
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
wrote:
> You are correct! I am maintaining a 'checksequenceverify' bra
fully-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
wrote:
>
This exact question came up on the Bitcoin Stack Exchange once. I gave an
answer here:
http://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maximum-block-size/37303#37303
On Mon, Jun 1, 2015 at 2:32 PM, Jim Phillips wrote:
> Ok, I understand at least some of the reason that bl
ould work. I
think it's time we just pick one and run with it.
Please let me know your thoughts. I will start working on a pull request if
this receives any support from miners/core devs/community members, unless
someone w
>
> 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 scriptS
-minermaxblocksize
configuration, depending on how it is implemented) in a long time.
I actually like Tier's suggestion quite a bit. I think we could have 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 i
vague references 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 wrote:
>
> Hello,
>
> How will this exactly be safe against:
> a) the ma
only to
alter 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.
- Steph
opefully the suggested proposal
won't be necessary as wallets will upgrade to use version 3 transactions
and the rules associated with them over time.
Best,
Stephen
--
One dashboard for servers and applicatio
hained transactions (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
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 kn
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 (v
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
e miner specified
solves a block 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 p
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 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-let-a-th
the proper way of doing things in
this community, I 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
On Wed, Mar 13, 2013 at 2:28 PM, Pieter Wuille wrote:
> 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 implemented in your cl
ot; in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______
> Bitcoin-development mailing list
> Bitcoi
On Thu, Feb 14, 2013 at 1:07 AM, Peter Todd wrote:
> On Wed, Feb 13, 2013 at 09:44:11PM -0500, Stephen Pair wrote:
> > One of the beauties of bitcoin is that the miners have a very strong
> > incentive to distribute as widely and as quickly as possible the blocks
> > they fi
On Wed, Feb 13, 2013 at 10:38 PM, Gregory Maxwell wrote:
> On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair wrote:
> >(by which I mean the fee or cost associated with the bandwidth and
> validation that a transaction requires) with some amount of profit. This
> means that the rela
On Wed, Feb 13, 2013 at 7:28 PM, Gregory Maxwell wrote:
>
>
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 miners have a very strong
incent
On Wed, Feb 13, 2013 at 4:02 PM, Gavin Andresen wrote:
> On Wed, Feb 13, 2013 at 10:42 AM, Gregory Maxwell wrote:
>
>> Since, in the long run,
>> Bitcoin can't meet its security and decenteralization promises without
>> blockspace scarcity to drive non-trivial fees and without scaling
>> limits t
The more I think about this topic, the more I think the first task at hand
is to implement secure, private messaging...the nature of any messages
(payment requests or otherwise) sent between wallets is such that it needs
to be secured. And the great thing is that it's easy to do and you don't
need
On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn 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 it's
> no
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
s
On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn 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 find ou
Test post.
--
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.source
37 matches
Mail list logo
