I like the idea but I think we should leave at least 16 bits of the
version fixed as an extra-nonce.
If we don't then miners may use them as a nonce anyway, and mess with
the soft-fork voting system.
My original proposal was this: https://github.com/bitcoin/bitcoin/pull/5102
Best regards
On 11/05/2015 04:25 p.m., Leo Wandersleb wrote:
I assume that 1 minute block target will not get any substantial support but
just in case only few people speaking up might be taken as careful
support of
the idea, here's my two cents:
In mining, stale shares depend on delay between
El 10/05/2015 06:07 p.m., Gregory Maxwell escribió:
On Sun, May 10, 2015 at 8:45 PM, Sergio Lerner
sergioler...@certimix.com wrote:
Can the system by gamed?
Users can pay fees or a portion of fees out of band to miner(s); this
is undetectable to the network.
Then this is exactly what
In this e-mail I'll do my best to argue than if you accept that
increasing the transactions/second is a good direction to go, then
increasing the maximum block size is not the best way to do it. I argue
that the right direction to go is to decrease the block rate to 1
minute, while keeping the
Two years ago I presented a new way to create a fee market that does not
depend on the block chain limit.
This proposal has not been formally analyzed in any paper since then,
but I think it holds a good promise to untangle the current problem
regarding increasing the tps and creating the fee
Matt is right: the goal is to prove digital copies of a public file.
Nothing more, nothing less.
Regarding the IP, I don't claim that every machine should provide the
protocol. Mobiles phones shouldn't. But machines that what to be
prioritized in some way or that want to be rewarded for hosting
If I understand correctly, transforming raw blocks to keyed blocks
takes 512x longer than transforming keyed blocks back to raw. The key
is public, like the IP, or some other value which perhaps changes less
frequently.
Yes. I was thinking that the IP could be part of a first layer of
The problem of pseudo-nodes will come over and over. The cat and mouse
chase is just beginning.
It has been discussed some times that the easiest solution world be to
request some kind of resource consumption on each peer to be allowed to
connect to other peers.
Gmaxwell proposed Proof of Storage
On 30/12/2014 01:51 a.m., Gregory Maxwell wrote:
On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner
sergioler...@certimix.com wrote:
I propose to allow miners to voluntarily lock funds by letting miners
add additional inputs to the coinbase transaction. Currently the
coinbase transaction does
I propose to allow miners to voluntarily lock funds by letting miners
add additional inputs to the coinbase transaction. Currently the
coinbase transaction does not allow any real input to be added (only a
pseudo-input).
This is a hard-fork, and we could include it the next time a hardfork is
Is that the full terminology or are there more acronyms?
Is this documented somewhere?
Best regards,
Sergio.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge
Instead of discussing what will happen when the subsidy is halved (which
nobody really knows) maybe we can think about of what we can do to
mitigate any damage in case something unwanted happens. Let's be proactive.
For instance, any form of merged-mining (like higher frequency
side-chains) will
On 06/10/2014 08:43 p.m., Tom Harding wrote:
On 10/5/2014 4:00 PM, Sergio Lerner wrote:
If everyone acts rationally in his own interest, then the best choice
for the remaining miners is to try to mine a competing block at the
same height n including the high-fee transaction, to collect
On 07/10/2014 04:16 p.m., Gregory Maxwell wrote:
Then I spend the output of the fraudulent spend nlocked
one block higher, and spend the output of that one again, nlocked one
block higher, and so on... each step paying fees.
Yes, you're right. I didn't consider that case. But the problem is
Comments between lines...
On 06/10/2014 03:42 a.m., Alex Mizrahi wrote:
.
This doesn't require protocol changes(*) and can be simply
incorporated into a piece of code which decides what to do when a
transaction with unusually large fee appears. (I.e. it will
automatically share the fee,
I would like to share with you a vulnerability in the Bitcoin protocol
I've been thinking of which might have impact on the future of Bitcoin.
Please criticize it!
*The Freeze on Transaction Problem
*
The freeze problem occurs if someone publishes a transaction with fees
much higher than the
I like the proposal.
I suggest that applications and nodes should only broadcast transactions
having OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value.
If a node broadcasts a TX having OP_CHECKLOCKTIMEVERIFY and nLockTime is
equal to the current height and equal to the timeout value,
We've coded and tested changes to the Bitcoin testing framework to allow
the creation and processing of blocks in unit test cases in order to
test ProcessBlock(), CheckBlock(), ActivateBestChain(),
ActivateBestChainStep() and ConnectTip(), including block-chain
reorganizations, majority rules,
Since the information exchanged between the pool and the miner is
public, all that's needed is a mutual private MAC key that authenticates
messages.
This requires a registration step, that can be done only once using a
simple web interface over https to the miner website.
But the miner website is
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.
There are two possible solutions to this:
1. Derive the first order of parties in the shuffle from
I'm working on a BIP which needs to modify the block acceptance rules. I
have two ways of testing:
- Mining blocks on the testnet
- Creating test cases for Bitcoin Core.
I want to create those test cases for block.CheckBlock(), which involves
verifying 100 dynamically generated blocks.
What is
I propose a setting that prevent mining pools AND reduce payoff variance
which requires two changes: increasing the block-rate and changing the
Bitcoin PoW (but still allowing current Bitcoin ASICs to work (as far as
I know)). The block rate must be increased at least 20 times and block
must still
Alex,
I think that what you are talking about more or less something like
the Firmcoin
Check: http://firmcoin.com/?p=92
On 18/05/2014 08:47 a.m., Alex Kotenko wrote:
One problem we couldn't figure out here though - how to protect the
notes from unauthorized redeem. Like if someone
This e-mail is an extract of my post:
http://bitslog.wordpress.com/2014/05/07/decor-2/
Some posts ago I presented the DECOR protocol. One of the assumptions I
did was that the amount of coins each miner earned in competing blocks
was approximately the same. This could be true for cryptocurrencies
On 02/05/2014 10:56 a.m., Joseph Bonneau wrote:
This is an interesting idea Sergio. I have two concerns:
You mention 50% of the block reward going to the uncle block. Does
this mean the parent gets 1, and the uncle 0.5, or both get 0.5? In
the first interpretation (which I assumed was the
On 27/04/2014 02:05 p.m., Mark Friedenbach wrote:
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
El 27/04/2014 03:43 a.m., Mark Friedenbach escribió:
I don't think there's an official definition of SPV proof. I wasn't
trying to make a argument from definition (that would be fallacious!).
Rather I suspected that we had different concepts in mind and wanted to
check.
So to disambiguate I
I read the post in this threads about Compact SPV proofs via block
header commitments (archived e-mail in
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04318.html).
I was working on the same problem almost at the same time, which is
something that's becoming very common
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 be transmitted as part of a non-interactive
protocol that convincingly establishes for a client without access to
the block chain that for
On 23/04/2014 05:51 p.m., Mike Hearn wrote:
On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter arit...@gmail.com
mailto:arit...@gmail.com wrote:
Isn't a faster blockchain for transactions (maybe as a sidechain)
solving the problem? If there would be a safe way for
0-confirmation
(this e-mail is cc to the bitcoin-research list)
Hi everyone from the bitcoin-development mailing list!
I decided to join this legendary list because it seems that all the
research fun is taking place in here, and I don't want to miss the
research party.
Regarding the discussion about BitUndo, a
31 matches
Mail list logo
