Lately someone launched Finney attacks as a service (BitUndo). As a
reminder for newcomers, Finney attacks are where a miner secretly works on
a block containing a double spend. When they eventually find a block, they
run to the merchant and pay, then broadcast the block. In a simpler variant
of
It seems to me that xbit is no more distinct or intuitive than µbit. In
either case it's simply an arbitrary character in front of the word bit.
Of course, for the majority of the world familiar with SI, the µ actually
adds additional meaning that is lost with the x.
Furthermore, given the
The problem is µBTC that bit tries to solve.
BTC, mBTC and µBTC are just too similiar for enyone else than engineers. The
mixed use of them leads to misunderstanding.
I think adoption would benefit of a single unit with easily remembered and
associated name that has no smaller than 1/100
On Wednesday 23 Apr 2014 08:55:30 Mike Hearn wrote:
Even with their woeful security many merchants see 1-2% credit card
chargeback rates, and chargebacks can be disputed. In fact merchants win
about 40% of chargeback disputes. So if N was only, say, 5%, and there
was a large enough population
I have a rather off-beat suggestion. Perhaps decimal was not satoshi's
intention.
In old English money 1 guinea is 21 shillings. I wonder if 1 million guineas is
more or less the total number of bitcoins = 21 million shillings. There was
also the notion of bits (two bob bits = 1 florin = 2
Just a few issues with the idea as it currently stands:
1. This provides a very strong incentive to always vote for
reallocating a block if it isn't yours, regardless of whether it's bad
or not (there's a positive expected return to voting to reallocate
coinbases from other miners). The incentive
On Wednesday 23 Apr 2014 12:45:34 Mike Hearn wrote:
OK, sure, let's say most Bitcoin users will be honest (we hope). But
unfortunately in a situation where fraud is possible users wouldn't
necessarily distribute evenly over transactions.
That's true, but even in the worst that that 5% hashing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/23/2014 07:55 AM, Mike Hearn wrote:
2. Miners can vote to reallocate the coinbase value of bad blocks
before they mature. If a majority of blocks leading up to maturity
vote for reallocation, the value goes into a pot that subsequent
blocks
This is outright ridiculous.
Zero-confirmation double-spending is a small problem, and possible
solutions are known. (E.g. trusted third party + multi-sig addresses for
small-value transactions.)
On the other hand, protocol changes like described above might have
game-theoretical implications
On Mon, Apr 21, 2014 at 01:30:28AM +, Jonathan Levin wrote:
CC'ing bitcoin-research - may be more appropriate to move the discussion
there as this discussion is delving into future scenarios.
Hi all,
I am a post-graduate economist writing a paper on the incentives of mining.
Even
And it still would. Non-collusive miners cast votes based on the outcome
of their own attempts to double spend.
Individually rational strategy is to vote for coinbase reallocation on
every block.
Yes, in that case nobody will get reward. It is similar to prisoner's
dilemma: equilibrium has
On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote:
I have some questions:
1. How can we work towards solving the double-spending problem?
We have this awesome technology that solves the double-spending
problem. It's called a blockchain. Of course, it only works when
On Wed, Apr 23, 2014 at 05:41:26PM +0200, Pieter Wuille wrote:
On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote:
I have some questions:
1. How can we work towards solving the double-spending problem?
We have this awesome technology that solves the double-spending
It's not necessary that this coinbase retribution be either
profitable or risk-free for this scheme to work. I think we should
separate out the different layers of the proposal:
1. Attacking the coinbase instead of orphaning allows for 100 blocks'
time for a consensus to be reached, rather than
What is the advantage of this proposal over just orphaning the block with
double spends?
There's currently a set of rules which government what constitutes a valid
block. Miners don't build on blocks that don't accord with those rules out
of fear that a major won't follow and they will waste
On 4/23/2014 12:04 PM, Christophe Biocca wrote:
It's not necessary that this coinbase retribution be either
profitable or risk-free for this scheme to work. I think we should
separate out the different layers of the proposal:
1. Attacking the coinbase instead of orphaning allows for 100
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/23/2014 03:07 PM, Mike Hearn wrote:
On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier
justusranv...@gmail.comwrote:
If enough miners don't like a block that has been mined, they can
all work to orphan it without any change to the protocol
On Tue, Apr 8, 2014 at 5:41 PM, slush sl...@centrum.cz wrote:
I've discussed the solution of Litecoin seed in BIP32 HMAC with Litecoin
devs already, and after long discussion we've concluded that it is generally
bad idea.
When changing Bitcoin seed constant to something different, same
I've formulated my replies to you and this proposal in a more public
venue, where such discussions of existential changes to the protocol
more rightfully belong
I strongly disagree. It makes perfect sense to discuss changes here,
first, where there are lots of people who understand how the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/23/2014 05:47 PM, Gavin Andresen wrote:
And why do you think your blog is more public than this open,
publicly archived mailing list???
Non-developers are more comfortable using social media tools. Blog
posts can be shared, Tweeted, and
Non-developers are more comfortable using social media tools. Blog
posts can be shared, Tweeted, and commented upon using nothing more
than a web browser.
I don't think Twitter is an appropriate medium for discussing the details
of byzantine consensus algorithms.
I'm not going to bother
On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
Storing the seed is superior to storing the master node already
(whether coin specific or not), as it is smaller.
...Except that you're loosing flexibility (serialization, deserialization)
which gives you BIP32 node.
On 04/23/2014 08:39 PM, Tier Nolan wrote:
A merchant could easily send 20 addresses in a row to customers and none of
them bother to actually buy anything.
Such merchant would surely use some merchant system instead of generic
wallet software.
Setting the gap limit to high is just a small
The most useful meta data to optimize chain scan is the key birth date, then
the allowed gap size.
Tamas Blummer
http://bitsofproof.com
On 23.04.2014, at 20:39, Tier Nolan tier.no...@gmail.com wrote:
Different users could have different gap limit requirements. 20 seems very
low as the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/23/2014 06:37 PM, Mike Hearn wrote:
If you want to try and argue that the development list is the wrong
place to discuss development, please do so on another thread (or
your blog). Let's keep this thread for discussion of the original
On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn m...@plan99.net wrote:
Lately someone launched Finney attacks as a service (BitUndo). As a reminder
for newcomers, Finney attacks are where a miner secretly works on a block
containing a double spend.
Hm? I didn't think this is at all what they did.
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
Cut it out with the ad hominem attacks please. If you cant be civil, please
go away until you learn some manners.
I think the issue being discussed is do you orphan an entire block causing
distress to users as well, or try to just cause distress just to the evil
miner? This discussion is about
I built such a merchant system handing out BIP32 addresses.
The gap size problem does not arise there since such a system has to have an
extra database keeping track of requests, so there is no added cost of storing
the key coordinates used by them. A scan is not needed the keys can be
Using higher gap limit in the software is not prohibited, but then it
breaks the standard as is, in mean that importing such wallet to another
BIP64 wallet won't recover the funds properly, without proper settings of
gap limit...
Gap limit 20 is the most sane defaults for majority of users
On Wed, Apr 23, 2014 at 8:57 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
Hm? I didn't think this is at all what they did. What they claim to
do is to prioritize transactions in their mempool from people who pay
them
That's the definition of a Finney attack, right? A tx is broadcast and
On 04/23/2014 09:00 PM, Tier Nolan wrote:
The point is to have a single system that is compatible over a large number
of systems.
There is such system and it is called BIP32.
On the other hand, in BIP64 we try to put a set of restrictions and
rules on top of BIP32. There will always be some
Pieter suggested in IRC couple of months ago to append key birth to key
serialization in xprv….@unixtime format.
What about picking this idea up in BIP64? It would greatly help the importing
client.
Regards,
Tamas Blummer
http://bitsofproof.com
signature.asc
Description: Message signed
On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
On 04/23/2014 09:00 PM, Tier Nolan wrote:
The point is to have a single system that is compatible over a large
number of systems.
There is such system and it is called BIP32.
On the other hand, in BIP64 we try to put a set of
(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
On 04/23/2014 09:44 PM, Luke-Jr wrote:
Why do clients need to use the features in BIP 64? If Electrum doesn't want
to
use accounts, then it can just use account 0 for everything. Refund chains
are
As Andreas wrote earlier in this thread: There is no bare minimum.
Either you implement the
On Wednesday, April 23, 2014 7:49:38 PM Pavol Rusnak wrote:
On 04/23/2014 09:44 PM, Luke-Jr wrote:
Why do clients need to use the features in BIP 64? If Electrum doesn't
want to use accounts, then it can just use account 0 for everything.
Refund chains are
As Andreas wrote earlier in
On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote:
Any wallet should import all the coins just fine, it just wouldn't *use*
any
account other than 0. Remember addresses are used to receive bitcoins; once
the UTXOs are in the wallet, they are no longer associated with the
address
On Wednesday, April 23, 2014 7:57:46 PM slush wrote:
On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote:
Any wallet should import all the coins just fine, it just wouldn't *use*
any
account other than 0. Remember addresses are used to receive bitcoins;
once the UTXOs are in
On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote:
Any wallet should import all the coins just fine, it just wouldn't *use* any
account other than 0. Remember addresses are used to receive bitcoins; once
the UTXOs are in the wallet, they are no longer associated with the address
or
On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote:
Any wallet should import all the coins just fine, it just wouldn't *use*
any account other than 0. Remember addresses are used to receive
bitcoins; once the UTXOs are in the
On 23.04.2014, at 22:02, Luke-Jr l...@dashjr.org wrote:
On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote:
Any wallet should import all the coins just fine, it just wouldn't *use*
any account other than 0. Remember addresses
On 04/23/2014 10:01 PM, Luke-Jr wrote:
Yes, it should scan all possible (under the BIP-defined structure) branches
regardless of which features it supports.
So you suggest to scan for accounts, show balances but don't allow user
to spend them? Does not seem right to me.
--
Best Regards / S
That's the point. BIP64 specifies such a structure, and you have to scan
all that it defines.
If you want to write wallet software that does not have the complexity to
deal with just one account, it is not BIP64 compliant. It could try to
define its own purpose system, with a hierarchy without
On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
On 04/23/2014 10:01 PM, Luke-Jr wrote:
Yes, it should scan all possible (under the BIP-defined structure)
branches regardless of which features it supports.
So you suggest to scan for accounts, show balances but don't allow user
On 23.04.2014, at 22:09, Luke-Jr l...@dashjr.org wrote:
On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
On 04/23/2014 10:01 PM, Luke-Jr wrote:
Yes, it should scan all possible (under the BIP-defined structure)
branches regardless of which features it supports.
So you suggest to
On 04/23/2014 10:09 PM, Luke-Jr wrote:
Scan all branches for UTXOs, then you have the balance for the wallet.
Account
balances are metadata, so cannot be known from the seed alone. If you want to
have a way to restore accounts, you must define some more detailed wallet
file
format
I see that the latest nightly build (thanks for that, Warren) is still not
compatible with Tails/Debian Squeeze. Is there still an intention to address
this issue? Might it be fixed by 0.9.2?
Can you be more specific as to what problem you're having?
Wladimir
On Wednesday, April 23, 2014 8:16:45 PM Pavol Rusnak wrote:
On 04/23/2014 10:09 PM, Luke-Jr wrote:
Scan all branches for UTXOs, then you have the balance for the wallet.
Account balances are metadata, so cannot be known from the seed alone.
If you want to have a way to restore accounts, you
On 04/23/2014 10:32 PM, Luke-Jr wrote:
f) I missed the part where BIP 32 redefined account to mean subwallet
instead of what has traditionally been called account in Bitcoin.
Ah, okay. The last time I saw Bitcoin-qt it was still using independent
addresses.
In that case, single-subwallet
On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell gmaxw...@gmail.comwrote:
Right, this works in the Bitcoin network today absent any collusion by
the miners. You give one miner a transaction and you give every other
node you can reach another transaction.
Yes, but that can be fixed with
On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas kristovat...@gmail.comwrote:
I see that the latest nightly build (thanks for that, Warren) is still not
compatible with Tails/Debian Squeeze. Is there still an intention to
address this issue? Might it be fixed by 0.9.2?
If I understand the
On Wednesday, April 23, 2014 8:35:50 PM Pavol Rusnak wrote:
On 04/23/2014 10:32 PM, Luke-Jr wrote:
f) I missed the part where BIP 32 redefined account to mean subwallet
instead of what has traditionally been called account in Bitcoin.
Ah, okay. The last time I saw Bitcoin-qt it was still
Isn't a faster blockchain for transactions (maybe as a sidechain) solving
the problem? If there would be a safe way for 0-confirmation transactions,
the Bitcoin blockchain wouldn't even be needed.
On Wed, Apr 23, 2014 at 10:37 PM, Mike Hearn m...@plan99.net wrote:
On Wed, Apr 23, 2014 at 10:24
On 04/23/2014 10:41 PM, Luke-Jr wrote:
I don't see how. The user knows he has money in different subwallets. As long
as he has a way to specify which subwallet he is accessing in
single-subwallet
clients, there shouldn't be a problem.
Right. But these clients have no right to call
On 04/23/2014 04:39 PM, Warren Togami Jr. wrote:
On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas
kristovat...@gmail.com mailto:kristovat...@gmail.com wrote:
I see that the latest nightly build (thanks for that, Warren) is
still not compatible with Tails/Debian Squeeze. Is there still
On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter 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 transactions,
the Bitcoin blockchain wouldn't even be needed.
Large scale consensus can't
On Wed, Apr 23, 2014 at 10:43 PM, Pavol Rusnak st...@gk2.sk wrote:
On 04/23/2014 10:41 PM, Luke-Jr wrote:
I don't see how. The user knows he has money in different subwallets. As long
as he has a way to specify which subwallet he is accessing in
single-subwallet
clients, there shouldn't be a
On Wednesday, April 23, 2014 8:43:57 PM Pavol Rusnak wrote:
On 04/23/2014 10:41 PM, Luke-Jr wrote:
I don't see how. The user knows he has money in different subwallets. As
long as he has a way to specify which subwallet he is accessing in
single-subwallet clients, there shouldn't be a
On Wed, Apr 23, 2014 at 10:54 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
Would you consider software which scans all accounts as specified by
BIP64, but has no user interface option to distinguish them in any
way, view them independently, and has no ability to keep the coins
apart...
The memory pool is just talk. There is no expectation that the memory pool
has to satisfy some standard as to what will eventually exist in the block
chain, and there are any number of ways that people could communicate
transactions to one another without putting them in the memory pool. The
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 04/23/2014 11:18 PM, Luke-Jr wrote:
Only a very niche user base needs funds isolated...
Our users do and we are creating this BIP for them, because we love them. ;)
--
Best Regards / S pozdravom,
Pavol Rusnak st...@gk2.sk
On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
Hopefully it would be clarified as only a MUST NOT do so silently...
I have funds split across two wallets and it WONT LET ME SPEND THEM
sounds like a terrible user experience. :)
That is a subjective matter. To me it makes PERFECT SENSE that
On Wed, Apr 23, 2014 at 2:23 PM, Tier Nolan tier.no...@gmail.com wrote:
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
On Wed, Apr 23, 2014 at 11:33 PM, Pavol Rusnak st...@gk2.sk wrote:
On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
Hopefully it would be clarified as only a MUST NOT do so silently...
I have funds split across two wallets and it WONT LET ME SPEND THEM
sounds like a terrible user experience. :)
On 04/23/2014 11:42 PM, Pieter Wuille wrote:
In that case, maybe it makes sense to define another purpose id
without accounts as well already.
I believe many simple wallets will find multiple subwallets too
burdening for the user experience, or not worth the technical
complexity.
Right.
On Wed, Apr 23, 2014 at 2:42 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
In that case, maybe it makes sense to define another purpose id
without accounts as well already.
I believe many simple wallets will find multiple subwallets too
burdening for the user experience, or not worth the
On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote:
On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
Hopefully it would be clarified as only a MUST NOT do so silently...
I have funds split across two wallets and it WONT LET ME SPEND THEM
sounds like a terrible user experience. :)
These sorts of proposals are all just ways of saying block chains kind of
suck and we should go back to using trusted third parties.
No.
Different approaches have different trade-offs, and thus different areas of
applicability.
Proof-of-work's inherent disadvantage is that it takes some time
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
On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wtog...@gmail.com wrote:
If you are
a rare user who needs Bitcoin-Qt on an incompatible system you can at least
build it from source.
Tails users usually can't really build it from source— talks is a live
boot mostly stateless linux
On 4/22/2014 9:03 PM, Matt Whitlock wrote:
On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote:
A network where transaction submitters consider their (final)
transactions to be unchangeable the moment they are transmitted, and
where the network's goal is to confirm only transactions all
On 4/23/2014 2:23 PM, Tier Nolan wrote:
An interesting experiment would be a transaction proof of
publication chain.
What if a transaction could simply point back to an earlier transaction,
forming a chain? Not a separately mined blockchain, just a way to
establish an official publication
74 matches
Mail list logo
