<unnamed>

Public Key

npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7h

Profile Code

nprofile1qqsgdaptedm2gvwp9z6edsm8zjh88fpv4ey8q65725faw9syx3rltmqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsc84cr0

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:33:19 UTC

- reply

📅 Original date posted:2015-05-08
📝 Original message:On 05/08/2015 01:13 AM, Tom Harding wrote:
> On 5/7/2015 7:09 PM, Jeff Garzik wrote:
>> G proposed 20MB blocks, AFAIK - 140 tps
>> A proposed 100MB blocks - 700 tps
>> For ref,
>> Paypal is around 115 tps
>> VISA is around 2000 tps (perhaps 4000 tps peak)
>>
For reference, I'm not "proposing" 100 MB blocks right now. I was
simply suggesting that if Bitcoin is to *ultimately* achieve the goal of
being a globally useful payment rails, 7tps is embarrassingly small.
Even with off-chain transactions. It should be a no-brainer that block
size has to go up.
My goal was to bring some long-term perspective into the discussion. I
don't know if 100 MB blocks will *actually* be necessary for Bitcoin in
20 years, but it's feasible that it will be. It's an open, global
payments system. Therefore, we shouldn't be arguing about whether 1 MB
blocks is sufficient--it's very clearly not. And admitting this as a
valid point is also an admission that not everyone in the world will be
able to run a full node in 20 years.
I don't think there's a solution that can accommodate all future
scenarios, nor that we can even find a solution right now that avoids
more hard forks in the future. But the goal of "everyone should be
able to download and verify the world's global transactions on a
smartphone" is a non-starter and should not drive decisions.

2023-06-07 15:33:19 UTC

- reply

📅 Original date posted:2015-05-08
📝 Original message:This isn't about "everyone's coffee". This is about an absolute minimum
amount of participation by people who wish to use the network. If our
goal is really for bitcoin to really be a global, open transaction
network that makes money fluid, then 7tps is already a failure. If even
5% of the world (350M people) was using the network for 1 tx per month
(perhaps to open payment channels, or shift money between side chains),
we'll be above 100 tps. And that doesn't include all the
non-individuals (organizations) that want to use it.
The goals of "a global transaction network" and "everyone must be able
to run a full node with their $200 dell laptop" are not compatible. We
need to accept that a global transaction system cannot be
fully/constantly audited by everyone and their mother. The important
feature of the network is that it is open and anyone *can* get the
history and verify it. But not everyone is required to. Trying to
promote a system where the history can be forever handled by a low-end
PC is already falling out of reach, even with our miniscule 7 tps.
Clinging to that goal needlessly limits the capability for the network
to scale to be a useful global payments system
On 05/07/2015 03:54 PM, Jeff Garzik wrote:
> On Thu, May 7, 2015 at 3:31 PM, Alan Reiner <etotheipi at gmail.com
> <mailto:etotheipi at gmail.com>> wrote:
>
>
> (2) Leveraging fee pressure at 1MB to solve the problem is
> actually really a bad idea. It's really bad while Bitcoin is
> still growing, and relying on fee pressure at 1 MB severely
> impacts attractiveness and adoption potential of Bitcoin (due to
> high fees and unreliability). But more importantly, it ignores
> the fact that for a 7 tps is pathetic for a global transaction
> system. It is a couple orders of magnitude too low for any
> meaningful commercial activity to occur. If we continue with a
> cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will
> fail to be useful for the vast majority of the world (which
> probably leads to failure). We shouldn't be talking about fee
> pressure until we hit 700 tps, which is probably still too low.
>
> [...]
>
> 1) Agree that 7 tps is too low
>
> 2) Where do you want to go? Should bitcoin scale up to handle all the
> world's coffees?
>
> This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day --
> just for a single feed. If you include relaying to multiple nodes,
> plus serving 500 million SPV clients en grosse, who has the capacity
> to run such a node? By the time we get to fee pressure, in your
> scenario, our network node count is tiny and highly centralized.
>
> 3) In RE "fee pressure" -- Do you see the moral hazard to a
> software-run system? It is an intentional, human decision to flood
> the market with supply, thereby altering the economics, forcing fees
> to remain low in the hopes of achieving adoption. I'm pro-bitcoin and
> obviously want to see bitcoin adoption - but I don't want to sacrifice
> every decentralized principle and become a central banker in order to
> get there.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/aa6f7b9a/attachment.html>

2023-06-07 15:33:17 UTC

- reply

📅 Original date posted:2015-05-07
📝 Original message:This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this. I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:
(1) Blocks are essentially nearing "full" now. And by "full" he means
that the reliability of the network (from the average user perspective)
is about to be impacted in a very negative way (I believe it was due to
the inconsistent time between blocks). I think Gavin said that his
simulations showed 400 kB - 600 kB worth of transactions per 10 min
(approx 3-4 tps) is where things start to behave poorly for certain
classes of transactions. In other words, we're very close to the
effective limit in terms of maintaining the current "standard of
living", and with a year needed to raise the block time this actually is
urgent.
(2) Leveraging fee pressure at 1MB to solve the problem is actually
really a bad idea. It's really bad while Bitcoin is still growing, and
relying on fee pressure at 1 MB severely impacts attractiveness and
adoption potential of Bitcoin (due to high fees and unreliability). But
more importantly, it ignores the fact that for a 7 tps is pathetic for a
global transaction system. It is a couple orders of magnitude too low
for any meaningful commercial activity to occur. If we continue with a
cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to
be useful for the vast majority of the world (which probably leads to
failure). We shouldn't be talking about fee pressure until we hit 700
tps, which is probably still too low.
You can argue that side chains and payment channels could alleviate
this. But how far off are they? We're going to hit effective 1MB
limits long before we can leverage those in a meaningful way. Even if
everyone used them, getting a billion people onto the system just can't
happen even at 1 transaction per year per person to get into a payment
channel or move money between side chains.
We get asked all the time by corporate clients about scalability. A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they expect it handle. We always assure them that 7 tps
is not the final answer.
Satoshi didn't believe 1 MB blocks were the correct answer. I
personally think this is critical to Bitcoin's long term future. And
I'm not sure what else Gavin could've done to push this along in a
meaninful way.
-Alan
On 05/07/2015 02:06 PM, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that
> people must find and alternative right now. Quite a lot here do
> not believe there is any urgency, nor that there is an immanent
> problem that has to be solved before the sky falls in.
>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all
> over again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> 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 that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/8d08315a/attachment.html>

2023-06-07 15:30:15 UTC

- reply

📅 Original date posted:2015-02-12
📝 Original message:I'll add fuel to the fire here, and express that I believe that
replace-by-fee is good in the long-term. Peter is not breaking the
zero-conf, it was already broken, and not admitting it creates a false
sense of security. I don't want to see systems that are built on the
assumption that zero-conf tx are safe solely because it has always
appeared safe. You can argue about rational miner behaviors all day,
but in a decentralized system you have no idea what miners consider
rational, or speculate about their incentives.
If there's one thing I learned playing poker (many years ago), was that
always assuming your opponent is rational can lose you a lot of money.
You made play that, in hindsight, was terrible given what he actually
had. But you assumed no sane or rational person in his position would
make such a play so you discounted it in your decision-making process.
You're "right" that his actions were terrible and irrational, but he
still won your money because you discounted his ability to make such a
"bad" play. Here, you are speculating that an "opponent" uses the same
values/motivations/rationality as yourself, and then building systems
that depend on that being true. Even if it "should" be true doesn't
mean that it is true and will remain that way. And you will get burned
by it eventually.
The Bitcoin network achieves something that we didnt' think was possible
10 years ago: a totally trustless, decentralized ledger. The cost? It
takes time for the decentralized network to reach consensus that
transactions "happened". That is quite literally the trade-off that we
make: you can centralize things by putting a bank in the middle and
getting instant confirmation, or you decentralize and let the network
reach consensus over time without the central authority. If you want
instant confirmations, you're going to need to add centralization
because Bitcoin never offered it. I support efforts to dispel any such
myths as soon as possible and encourage building robust solutions
(payment channels, insured zero-conf services, etc.).
-Alan
On 02/12/2015 07:37 PM, Allen Piscitello wrote:
> You cannot close Pandora's box. Whether or not this type of patch should exist is irrelevant. It
does, and there are incentives to use it by miners. These are the
bounds we have to deal with and the world we must adapt to.
>
> On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier
<justusranvier at riseup.net <mailto:justusranvier at riseup.net>> wrote:
>
> On 02/12/2015 05:24 PM, Oleg Andreev wrote:
>
> >> I think that is a misdirection on your part. The point of
> >> replace-by-fee is to make 0-confirms reliably unreliable.
> >> Currently people can "get away" with 0-confirms but it's only
> >> because most people arent actively double spending, and when they
> >> do it is for higher value targets. Double spend attacks are
> >> happening a lot more frequently than is being admitted here,
> >> according to Peter from work with various clients.
> >>
> >> Like single address reuse, people have gotten used to something
> >> which is bad. Generally accepting 0-conf is also a bad idea(tm)
> >> and instant confirmation solutions should be sought elsewhere.
> >> There are already interesting solutions and concepts:
> >> greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment
> >> channels for example. Rather than supporting and promoting risky
> >> 0-confirms, we need to spend time on better alternative solutions
> >> that will work for everyone and not during the honeymoon phase
> >> where attackers are fewer.
>
> > Here's value-free assessment of the issue here:
>
> > 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer
> > instant payments solution if possible. 3. As a social artifact,
> > today zeroconf txs happen to work for some people in some
> > situations. 4. Replace-by-fee will break #3 and probably hasten
> > development of #2.
>
> > The discussion boils down to whether we should make #2 happen
> > sooner by breaking remnants of #3 sooner.
>
> > I personally would rather not break anything, but work as fast as
> > possible on #2 so no matter when and how #3 becomes utterly broken,
> > we have a better solution. This implies that I also don't want to
> > waste time debating with Peter Todd and others. I want to be ready
> > with a working tool when zeroconf completely fails (with that patch
> > or for some other reasons).
>
> > TL;DR: those who are against the patch are better off building a
> > decentralized clearing network rather than wasting time on debates.
> > When we have such network, we might all want this patch to be used
> > for all the reasons Peter has already outlined.
>
> You've left out of the discussion that many (or all) proposed
> solutions for 2 either reduce privacy, or security, or both.
>
> That fact should not be ignored or swept under the rug.
>
> There's also no mention of the degree to which child-pays-for-parent
> achieves the stated aims of the original proposal (clearing mempool of
> stuck transactions, increasing payee assurance of conformation)
> without introducing incentives to double spend or forcing people into
> privacy/security sacrifices.
>
>
>
>
------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot
Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and
more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
<mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media,
is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/f851bd85/attachment.html>

2023-06-07 15:29:02 UTC

- reply

📅 Original date posted:2015-01-23
📝 Original message:The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise
non-intrusive, doesn't change any TxOut scripts, doesn't change any
tx/block parsing (besides verification), it works with all existing
coins in the network, and existing software doesn't have to use it if
they don't want to upgrade their signers. The proposal simply provides
a way to optionally sign the input values with the TxOut scripts. In
other words a signature right now says "I sign this transaction using
these inputs, whatever value they are." With this SIGHASH type, the
signature says "I sign this transaction assuming that input 0 is X BTC,
input 1 is Y BTC,....". If the online computer providing the data to be
signed lies about the value of any input, the resulting signature will
be invalid.
Unfortunately, it seems that there was no soft-fork way to achieve this
benefit, at least not one that had favorable properties. Most of the
soft-fork variations of it required the coins being spent to have been
originated in a special way. In other words, it would only work if the
coins had entered the wallet with some special, modified TxOut script.
So it wouldn't work with existing coins, and would require senders to
update their software to reshape the way they send transactions to be
compatible with our goals.
I *strongly* encourage this to be considered for inclusion at some
point. Not only does it simplify HW as Marek suggested, it increases
the options for online-offline communication channels, which is also a
win for security. Right now, QR codes don't work because of the
possibility of having to transfer megabytes over the channel, and no way
to for the signer to control that size. With this change, it's possible
for the signer to control the size of each chunk of data to guarantee it
fits in, say, a QR code (even if it means breaking it up into a couple
smaller transactions).
-Alan
On 01/23/2015 09:51 AM, slush wrote:
> Hi,
>
> is any progress or even discussion in this area?
>
> https://bitcointalk.org/index.php?topic=181734.0
>
> I don't insist on any specific solution, but this is becoming a real
> issue as hardware wallets are more widespread. I'm sitting next to
> TREZOR for 40 minutes already, because it streams and validate some
> complex transaction. By using proposed solution, such signature would
> be a matter of few seconds.
>
> That's also not just about time/resource/hw cost optimization. I'm
> talking about possibility of huge simplification of the firmware
> (=security FTW), because 50% of actual codebase is solving this
> particular downside of Bitcoin protocol.
>
> So, there's real world problem. On which solution can we as a
> community find a wide agreement?
>
> Best,
> Marek
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/46e022bd/attachment.html>

2023-06-07 15:28:36 UTC

- reply

📅 Original date posted:2015-01-19
📝 Original message:I'm a bit confused. It's been a long time since I looked at protobuf
(and will have to dig into it soon), but I seem to recall it doesn't
have any of the determinism properties you guys just said. It is
intended to allow you to skip details of the on-the-wire representations
and just send a bunch of named fields between systems. I thought there
was no guarantee that two identical protobuf structures will get
serialized identically...?
On 01/19/2015 02:57 PM, Richard Brady wrote:
> Thanks guys, great answers.
>
> The design choice certainly makes a lot more sense now regardless of
> whether one agrees with it or not.
>
> Regards,
> Richard
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/c6c82c2c/attachment.html>

2023-06-07 15:26:05 UTC

- reply

📅 Original date posted:2014-10-01
📝 Original message:On 10/01/2014 04:58 PM, Gavin Andresen wrote:
> If the first transaction is P2SH, then the miner won't know there is
> an advantage to holding it until it is too late (the scriptPubKey is
> an opaque hash until the second transaction is final and
> relayed/broadcast).
If you're doing some kind of proof-of-burn scheme, wouldn't using P2SH
defeat the purpose of it?

2023-06-07 15:25:52 UTC

- reply

📅 Original date posted:2014-09-23
📝 Original message:This topic has been touched on briefly here before, but I wanted to
solidify it and propose it as a BIP if there is wider support for it.
Also, the topic is difficult to discuss without lots of pictures -- so
that's what I've done (mainly to describe it to my team, but also as
general documentation). It's in presentation form:
https://s3.amazonaws.com/bitcoinarmory-media/MultisigWalletNoCollide.pdf
The proposal is that for an M-of-N multisig wallet based on BIP32, there
should be N internal chains and N external chains. Each party is
assigned a chain based on the lexicographic ordering of their wallet's
root public key in the multisig. This guarantees that no parties are
generating and distributing the same addresses, and also provides a
certain level of built-in book-keeping. Coins being received on chain
2*x were created by participant x (receiving), and coins received on
2*x+1 are change outputs created by participant x (outgoing). Thus,
it's easy from simply looking at the wallet structure who was
responsible for which transactions.
Alternatively, we could change it to suggest that each "device" is
assigned a pair of chains. For a 2-of-3 there may 3 participants plus a
CFO with a "watch-only" version of the multisig wallet. Then you might
use four pairs of chains. I'm just not sure how they would be assigned.
If this has been proposed before, then consider this my contribution to
documentation.
-Alan
P.S. -- "No-Collision Mode" is not a great name. Happy to take
suggestions for changing it.

2023-06-07 15:24:37 UTC

- reply

📅 Original date posted:2014-07-30
📝 Original message:Hi Everyone,
The Armory team is pleased to announce the official release of our
decentralized multi-signature interface, called "Lockboxes". It is a
"true" multi-signature transaction interface:
* Decentralized multi-sig (no third-party servers or signers needed)
* Any multi-sig from 1-of-2 up to 7-of-7
* Any or all of the signing devices can be *offline*
* All private keys can be generated and managed independently
* Works with existing Armory wallets
* Simultaneous funding ("simulfunding") features for escrow and
contracts (basically CoinJoin)
* All wrapped up in a nice graphical user interface!
Armory 0.92 includes a GUI for creating, funding and spending from
multi-signature lockboxes, anything from 1-of-2 up to 7-of-7. All
private keys can be generated independently and never have to be
co-located. Most importantly, any number of the signing keys can be
created and managed on offline computers! Also, all transaction and
signature data is communicated directly between parties/devices using
ASCII-armored blocks of text, so no third-party servers/services are
needed (though, in the future, we hope to provide an optional service to
help synchronize the data between parties).
The release also includes the ability to do simultaneous funding
("simulfunding") which is basically CoinJoin through a GUI, but intended
to be used for contracts and escrow. Each party creates a "promissory
note" (which is basically just a list of UTXOs and a change address),
and those can be merged into a single transaction to be signed by all
funders. Either all contributions are made simutaneously, or none of
them are. There is no other outcome. This means that no trust is
required between the simulfunders. It is a basic contract enforced by
the bitcoin network itself.
Simulfunding would normally be used in conjuction with multi-signature
lockboxes -- two parties that don't trust each other together create a
lockbox, and then simultaneously fund it (and subsequently spend it)
according to some agreement. However, it can actually be used to
simulfund any address. To promote this feature, Armory Technologies Inc
is offering to match up to 20 BTC in donations to the EFF, FSF, College
Crypto Network, Chamber of Digital Commerce, and the Bitcoin Foundation
(and hopefully wikipedia, as a late addition to the list). We posted
a list of ATI "promissory notes" for matching donations on our
website: https://bitcoinarmory.com/donation-match-list/
We're very excited about this release, which has been in testing for
over three months, and we've been using for management of company funds
between officers for the last two months. We have not seen anything
else that comes close to matching the flexibility and security afforded
by it (and without being exceptionally inconvenient!). See our
tutorials, and especially the FAQ at the end:
https://bitcoinarmory.com/about/using-lockboxes
https://bitcoinarmory.com/about/using-lockboxes/#faq
We hope that people will try it out and provide feedback. Maybe even
match some donations! We've already matched 3 BTC so far and it was
announced less than 24 hours ago.
Cheers,
-Alan
------
Press Release:
http://finance.yahoo.com/news/armory-releases-first-decentralized-multi-233500704.html
------
Changelog:
*VERSION 0.92**
**Released July 29, 2014**
*
- *Multi-Signature Lockboxes!*
Full-featured interface for creating multi-signature addresses,
putting money into them, and collecting signatures to spend them.
See our tutorials at:
https://bitcoinarmory.com/about/using-lockboxes/
- *Simulfunding for Addresses and Lockboxes*
Use the "Multi-Sig" menu to do prepare simulfunding to any
arbitrary address. Or click on the "Simul" checkbox in the
lockbox manager if you are simulfunding a lockbox. As a promotion
for this feature we are matching up to 20 BTC worth donations
to organizations that support Bitcoin, digital security, online
freedoms, and open-source software. See our donation list (with
instructions): https://bitcoinarmory.com/about/donation-match-list
- *Improved Mac/OSX Stability*
We merged a couple Qt4 patches that dramatically improved
compatibility on OSX 10.7 and newer. Should work with the
upcoming release of OSX 10.10.
- *Armory Daemon/API Upgrades (Beta)*
The Armory API has been upgraded substantially since version 0.91.
This version has tons of new functionality matching bitcoind,
as well as unique functionality including lockbox operations.
Plan to have complete functionality implemented and tested by
version 0.93.
- *Upgraded Transaction History Export to CSV*
Added running balance reporting for individual and all wallets.
Also fixed a bug where internal transfers within wallets were
not being reported properly.
- *Root PUBLIC Key Export*
You can now export just the root public key data that allows
you to reconstruct your watching-only wallet. It is five lines
that are easily printed or copied by hand. Could be used to
provide someone a chain of addresses for multiple payments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140730/d0ee6702/attachment.html>

2023-06-07 15:23:34 UTC

- reply

📅 Original date posted:2014-07-04
📝 Original message:On 07/04/2014 07:15 AM, Andy Parkins wrote:
> On Friday 04 July 2014 06:53:47 Alan Reiner wrote:
>
>> ROMix works by taking N sequential hashes and storing the results into a
>> single N*32 byte lookup table. So if N is 1,000,000, you are going to
>> compute 1,000,000 and store the results into 32,000,000 sequential bytes
>> of RAM. Then you are going to do 1,000,000 lookup operations on that
>> table, using the hash of the previous lookup result, to determine the
>> location of next lookup (within that 32,000,000 bytes). Assuming a
>> strong hash function, this means its impossible to know in advance what
>> needs to be available in RAM to lookup, and it's easiest if you simply
>> hold all 32,000,000 bytes in RAM.
> My idea wasn't to make hashing memory hungry; it was to make it IO-hungry. It
> wouldn't be too hard to make an ASIC with 32MB of RAM. Especially if it
> gained you a 1000x advantage over the other miners. It seems that sort of
> solution is exactly the one that Mike Hearn was warning against in his blog.
I think you misundersood.... using ROMix-like algorithm, each hash
requires a different 32 MB of the blockchain. Uniformly distributed
throughout the blockchain, and no way to predict which 32 MB until you
have actually executed it. If the difficulty is high enough, your
miner is likely to end up going through the entire X GB blockchain while
searching for a good hash, but other nodes will only need to do 32 MB
worth of disk accesses to verify your answer (and it will be unknown
which 32 MB until they do the 1,000,000 hash+lookup operations on their
X GB blockchain).
I think that strikes a good compromise of needing access to 100% of the
blockchain, without requiring reading 20 GB to verify a block.
(Replace N=1,000,000, 32 MB and 20 GB with the appropriately calibrated
numbers in the future)

2023-06-07 15:23:33 UTC

- reply

📅 Original date posted:2014-07-04
📝 Original message:Just a thought on this -- I'm not saying this is a good idea or a bad
idea, because I have spent about zero time thinking about it, but
something did come to mind as I read this. Reading 20 GB of data for
every hash might be a bit excessive. And as the blockchain grows, it
will become infeasible to continue. However, what comes to mind is the
ROMix algorithm defined by Colin Percival, which was the pre-cursor to
scrypt. Which is actually what Armory uses for key stretching because
it's far simpler than scrypt itself while maintaining the memory-hard
properties (the downside is that it's much less flexible in allowing the
user to trade-off compute time vs memory usage).
ROMix works by taking N sequential hashes and storing the results into a
single N*32 byte lookup table. So if N is 1,000,000, you are going to
compute 1,000,000 and store the results into 32,000,000 sequential bytes
of RAM. Then you are going to do 1,000,000 lookup operations on that
table, using the hash of the previous lookup result, to determine the
location of next lookup (within that 32,000,000 bytes). Assuming a
strong hash function, this means its impossible to know in advance what
needs to be available in RAM to lookup, and it's easiest if you simply
hold all 32,000,000 bytes in RAM.
Something similar could be applied to your idea. We use the hash of a
prevBlockHash||nonce as the starting point for 1,000,000 lookup
operations. The output of the previous lookup is used to determine
which block and tx (perhaps which chunk of 32 bytes within that tx) is
used for the next lookup operation. This means that in order to do the
hashing, you need the entire blockchain available to you, even though
you'll only be using a small fraction of it for each "hash". This might
achieve what you're describing without actually requiring the full 20 GB
of reading on ever hash.
-Alan
On 07/04/2014 06:27 AM, Andy Parkins wrote:
> Hello,
>
> I had a thought after reading Mike Hearn's blog about it being impossible to
> have an ASIC-proof proof of work algorithm.
>
> Perhaps I'm being dim, but I thought I'd mention my thought anyway.
>
> It strikes me that he's right that it's impossible for any algorithm to exist
> that can't be implemented in an ASIC. However, that's only because it's
> trying to pick an algorithm that is CPU bound. You could protect against ASCI
> mining (or rather, make it irrelevant that it was being used) by making the
> algorithm IO-bound rather than CPU-bound.
>
> For example, what if the proof-of-work hash for a block were no longer just
> "hash of block", which contains the hash of the parent block, but instead were
> hash of
>
> [NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]
>
> [ALL_PREVIOUS_BLOCKS] is now 20GB (from memory) and growing. By prefixing and
> suffixing the new block, you have to feed every byte of the blockchain through
> the hashing engine (the prefix prevents you caching the intermediate result).
> Whatever bus you're using to feed your high speed hashing engine, it will
> always be faster than the bus -- hence you're now IO-bound, not CPU-bound, and
> any hashing engine will, effectively, be the same.
>
> I'm making the assumption that SHA-256 is not cacheable from the middle
> outwards, so the whole block-chain _has_ to be transferred for every hash.
>
> Apologies in advance if this is a stupid idea.
>
>
>
> Andy

2023-06-07 15:20:46 UTC

- reply

📅 Original date posted:2014-05-02
📝 Original message:I've been a strong supporter of the 1e-6 unit switch since the beginning
and ready to do whatever I can with Armory to help ease that
transition. I'm happy to prioritize a release that updates the Armory
interface to make "bits" the default unit, when the time is right. I
think it makes sense to get as many apps and services to upgrade nearly
simultaneously.
My plan is to have a popup on the first load of the new version that
briefly introduces the change, and mentions that they can go back to the
old way in the settings, but make them work to do it. For the transient
period (6 months?) all input boxes will auto-update nearby labels with
the converted-to-BTC value as they type, so that they don't have to do
any math in their head. Similarly, all displayed BTC values will show
both. But the 1e-6 unit will always be default or first unless they
explicitly change it in the interface.
On 5/2/2014 8:54 PM, Ben Davenport wrote:
> I fully support this (it's what I suggested over a year ago), but what
> it comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting
> together, agreeing what they're going to use, and doing a little joint
> customer education campaign around it. If there's community momentum
> around "bits", great.
>
> My only addition is that I think we should all stop trying to attach
> SI prefixes to the currency unit. Name me another world currency that
> uses SI prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted
> standard at least in the US is <currency-symbol><amount><modifier>,
> i.e. $63k or $3M. That may not be accepted form everywhere, but in any
> case it's an informal format, not a formal one. The important point is
> there should be one base unit that is not modified with SI prefixes.
> And I think the arguments are strong for that unit being = 100 satoshi.
>
> Ben
>
>
>
>
> On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>> wrote:
>
> <vendor hat: on>
>
> Related:
> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform
> available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140502/44cb1298/attachment.html>

2023-06-07 15:20:21 UTC

- reply

📅 Original date posted:2014-04-26
📝 Original message:On 04/26/2014 04:33 PM, Mike Hearn wrote:
>
> Let's assume we use one shared branch for everyone. Then two
> cosigners could need a new receiving address at the same time, and
> get the next unused address on that branch.
>
> This is the part I struggle to understand. There is no shared branch
> because each user/cosigner has their own unique seed and thus unique
> key hierarchy, right? What you described above could be an issue if
> all co-signers shared the same seed but then the scheme wouldn't work.
>
Consider two people with phones, using 2-of-2, using private seeds k1
and k2. Every address generated by either party is:
2-of-2(K1/a'/b/c, K2/a'/b/c)
So for any a, b and c you end up with a 2-of-2 address. The
seeds/branches will not be used for single-sig receiving... it's always
a multisig 2-of-2. In fact it behaves much like a regular wallet, you
give an a, b, and c value, and you get an address -- it's just that this
wallet always gives you a P2SH multisig address.
The problem is that if you follow BIP32 in the the most obvious way,
both devices will generate receiving addresses along the last index,
i.e. K/a'/b/0, K/a'/b/1, K/a'/b/2,... If I am at one store and my
wife at another, we might both give out 2-of-2(K1/a'/b/382, K2/a'/b/382)
at the same time not realizing the other one has distributed that
address. There's not a good way to coordinate the devices well enough
to avoid it. But we don't have to.
The solution is to use two separate branches -- both phones will
follow/watch both branches, but each only only distributes payment
addresses from one such branch.
The original proposal here suggested adding a level to the tree using
the "cosigner index" as a branch point for doing this... I recommended
simply having 2*N values for "b", so that each participant has a
receiving line and change line, that won't conflict with other devices.
However, all devices will still watch all 2*N branches to know the total
balance of the wallet, and will use UTXOs from those branches when
constructing spending transactions/proposals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140426/72bca647/attachment.html>

2023-06-07 15:20:18 UTC

- reply

📅 Original date posted:2014-04-26
📝 Original message:I will just chime in that I've been working on a similar spec for Armory
to implement P2SH multisig and I came up with basically an identical
scheme. I think you covered most of what is needed. The one thing I
did differently was try to match the BIP 32 structure, by keeping the
original 3 levels (wallet, chain, addresses), and use 2*N chains to
handle the N different parties generating receiving and change
addresses. It's not necessary, but it follows more closely the
three-level scheme that BIP 32 originally envisioned. I also concluded
that the chain indices are ordered by lexicographical sorting of root
public keys, but resorting each individual address. There are use cases
where it will be necessary for parties to know how to combine public
keys into a multi-sig address without knowing the root keys.
Also, for the purposes of one-off types of escrow multi-sig, we have
included a "wallet locator" field in the transaction that must be passed
around. This "wallet locator" is stored with each key (perhaps at the
time public keys are collected and merged), and passed around with
transactions to be signed. This allows lightweight devices like
hardware wallets, to recognize their own keys. It would encoded in a
VAR_STR, and doesn't have to be meaningful to the other participants --
each device would look at all signing slots in a transaction (either
singlesig or each key in a multisig) and would generate a public key
along each path, and see if the result matches. If so, it can sign it.
If not, it must be someone else's.
I bring this up, because this multisig wallet structure you're talking
about has a very simple "wallet locator" scheme -- all parties will use
the same locator for a given receiving address. But that field should
remain part of the data structure for each key, to accommodate all types
of multisig, not just linked/parallel tree schemes.
-Alan
On 04/25/2014 06:27 PM, Manuel Araoz wrote:
> Hi, I'm part of the team building copay
> <https://github.com/bitpay/copay>, a multisignature P2SH HD
> wallet. We've been following the discussion regarding standardizing
> the structure for branches both on this list and on github (1
> <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>, 2
> <https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki>, 3
> <https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki>, 4
> <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>, 5
> <https://github.com/bitcoin/bips/pull/52>). Soon, we realized the
> assumptions in the discussions were not true for a multisig hd wallet,
> so we wanted to share our current approach to that, to get feedback
> and see if we can arrive to a new standard (and possibly a new BIP)
>
> These are our assumptions:
> - N parties want to share an m-of-n wallet.
> - Each party must generate their master private keys independently.
> - Use multisig P2SH for all addresses.
> - Use BIP32 to derive public keys, then create a multisig script, and
> use the P2SH address for that.
> - The address generation process should not require communicating
> with other parties. (Thus, all parties must be able to generate all
> public keys)
> - Transaction creation + signing requires communication between
> parties, of course.
>
> -------------------------------------------------
>
> Following BIP43, we're be using:
> m / purpose' / *
> where /purpose/ is the hardened derivation scheme based on the new BIP
> number.
> We then define the following levels:
> m / purpose' / cosigner_index / change / address_index
> Each level has a special meaning detailed below:
>
> /cosigner_index/ <http://en.wikipedia.org/wiki/Co-signing>: the index
> of the party creating this address. The indices can be determined
> independently by lexicographically sorting the master public keys of
> each cosigner.
>
> /change/: 0 for change, 1 for receive address.
>
> /address_index/: Addresses are numbered from index 0 in sequentially
> increasing manner. We're currently syncing the max used index for each
> branch between all parties when they connect, but we're open to
> considering removing the index sync and doing the more elegant
> used-address discovery via a gap limit, as discussed in BIP44
> <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit>.
> We feel 20 might be too low though.
>
> *Wallet high-level description:*
> Each party generates their own extended master keypair and shares the
> extended purpose' public key with the others, which is stored
> encrypted. Each party can generate any of the other's derived public
> keys, but only his own private keys.
>
> *General address generation procedure:*
> When generating an address, each party can independently generate the
> N needed public keys. They do this by deriving the public key in each
> of the different trees, but using the same path. They can then
> generate the multisig script and the corresponding p2sh address. In
> this way, each path corresponds to an address, but the public keys for
> that address come from different trees.
>
> *Receive address case:*
> Each cosigner generates addresses only on his own branch. One of the n
> cosigners wants to receive a payment, and the others are offline. He
> knows the last used index in his own branch, because only he generates
> addresses there. Thus, he can generate the public keys for all of the
> others using the next index, and calculate the needed script for the
> address.
>
> /Example: /Cosigner #2 wants to receive a payment to the shared
> wallet. His last used index on his own branch is 4. Then, the path for
> the next receive address is m/$purpose/2/1/5. He uses this same path
> in all of the cosigners trees to generate a public key for each one,
> and from that he gets the new p2sh address.
>
> *Change address case:*
> Again, each cosigner generates addresses only on his own branch. One
> of the n cosigners wants to create an outgoing payment, for which
> he'll need a change address. He generates a new address using the same
> procedure as above, but using a separate index to track the used
> change addresses.
> /
> Example: /Cosigner #5 wants to send a payment from the shared wallet,
> for which he'll need a change address. His last used change index on
> his own branch is 11. Then, the path for the next change address is
> m/$purpose/5/0/12. He uses this same path in all of the cosigners
> trees to generate a public key for each one, and from that he gets the
> new p2sh address.
>
>
> *Transaction creation and signing:*
> When creating a transaction, first one of the parties creates a
> Transaction Proposal. This is a transaction that spends some output
> stored in any of the p2sh multisig addresses (corresponding to any of
> the copayers' branches). This proposal is sent to the other parties,
> who decide if they want to sign. If they approve the proposal, they
> can generate their needed private key for that specific address (using
> the same path that generated the public key in that address, but
> deriving the private key instead), and sign it. Once the proposal
> reaches m signatures, any cosigner can broadcast it to the network,
> becoming final. The specifics of how this proposal is structured, and
> the protocol to accept or reject it, belong to another BIP, in my
> opinion.
>
> *Final comments:*
> - We're currently lexicographically sorting the public keys for each
> address separately. We've read Mike Belshe's comments about sorting
> the master public keys and then using the same order for all derived
> addresses, but we couldn't think of any benefits of doing that (I
> mean, the benefits of knowing whose public key is which).
> - We originally thought we would need a non-hardened version of
> purpose for the path, because we needed every party to be able to
> generate all the public keys of the others. With the proposed path, is
> it true that the cosigners will be able to generate them, by knowing
> the extended purpose public key for each copayer? (m/purpose')
> - The reason for using separate branches for each cosigner is we don't
> want two of them generating the same address and receiving
> simultaneous payments to it. The ideal case is that each address
> receives at most one payment, requested by the corresponding cosigner.
>
>
> Thoughts?
> Manuel
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/c7d5c529/attachment.html>

2023-06-07 15:18:55 UTC

- reply

📅 Original date posted:2014-04-20
📝 Original message:I've been a staunch supporter of "microbitcoin" and would like to do
anything I can to make sure that we jump directly to it if we're going
to promote changing the default units. And I'm happy to integrate it
into Armory as a default (with appropriate explanations and
settings/options). I'm not so convinced about the "bits" name though --
I do like it, but I do also think that word is too overloaded. Though,
I think we could get away with it.
(Sadly, I still use "microbes" occasionally (as in *microb*itcoin) when
I'm talking to coworkers, because it slips off the tongue and is
actually a good combination of brevity and self-explanatory -- it just
doesn't instill the right visuals...)
We started integrating alternative units into Armory. But, of course,
there were a few more loose ends than I expected, which will require
some work. We want to put it in but not necessarily change the default
right away. I'd /prefer/ we get some commitments from some other wallet
developers, so we can make a unified push for it. I'm happy to lead
that and make it default as long as I'm not the only one in the world
doing it.
-Alan
On 04/20/2014 11:05 AM, Tamas Blummer wrote:
> Here is an earlier reference to bits:
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html
> <https://www.mail-archive.com/[email protected]/msg04248.html>
>
> I forgot that Alan Reiner was also supporting a unit equals to bits :
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html
> <https://www.mail-archive.com/[email protected]/msg04264.html>
>
> and here the earlier going back to March 2013 and a poll at that time
> pushing for XBT being 1 bit
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html
> <https://www.mail-archive.com/[email protected]/msg04256.html>
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 20.04.2014, at 16:53, Pieter Wuille <pieter.wuille at gmail.com
> <mailto:pieter.wuille at gmail.com>> wrote:
>
>> I told him specifically to bring it here (on a pull request for
>> Bitcoin Core), as there is no point in making such convention changes
>> to just one client.
>>
>> I wasn't aware of any discussion about the "bits" proposal here before.
>>
>> On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer <tamas at bitsofproof.com
>> <mailto:tamas at bitsofproof.com>> wrote:
>>> People on this list are mostly engineers who have no problem dealing
>>> with
>>> magnitudes and have rather limited empathy for people who have a problem
>>> with them.
>>> They also tend to think, that because they invented money 2.0 they
>>> would not
>>> need to care of finance's or people's current customs.
>>>
>>> The importance of their decisions in these questions will fade as people
>>> already use wallets other than the core.
>>>
>>> Bring this particular discussion elsewhere, to the wallet developer.
>>>
>>> BTW the topic was discussed here several times, you have my support
>>> and Jeff
>>> Garzik's.
>>>
>>> Regards,
>>>
>>> Tamas Blummer
>>> http://bitsofproof.com
>>>
>>> On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com> wrote:
>>>
>>> The average person is not going to be confident that the prefix they
>>> are using is the correct one,
>>>
>>>
>>> The use of any 'prefix' is one of choice and entirely unnecessary,
>>> and there
>>> are already established 'divisions' in u/mBTC for those that feel
>>> they need
>>> to use such things.
>>>
>>> people WILL send 1000x more or less than
>>> intended if we go down this road,
>>>
>>>
>>> Exceptionally unlikely - I deal every day with currencies with 0, 2
>>> and 3
>>> dp's in amount ranging from 'under 1 whole unit' to tens of
>>> thousands - Not
>>> once in 20 years has anyone ever 'sent' more or less than intended - oh,
>>> they've 'intended' to underpay just fine, but never *unintended*.
>>>
>>> I propose that users are offered a preference to denominate the
>>> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
>>> equals one million bits (bits) and one bit equals 100 satoshis.
>>>
>>>
>>> I propose that for people unable to understand what a bitcoin is,
>>> they can
>>> just use satoshi's and drop this entire proposal.
>>>
>>> Rob
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/542338d8/attachment.html>

2023-06-07 15:16:42 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:Armory does exactly this: it defines the "Fragment ID" as the first few
bytes of the hash of the root pubKey + M-parameter, converted to
base58. Then it explains to the user "All fragments with the same
fragment ID are compatible" (which only works if you use deterministic
coefficients). Each fragment is then labeled with "[FragID]-#1",
"[FragID]-#2", etc. It became quite useful for organizing the fragments
and documenting how I was distributing them, especially if I had printed
or saved the same fragment twice by accident.
On 03/29/2014 02:16 PM, Tamas Blummer wrote:
> I also think that we can add usability features if the underlying
> secret remains well protected.
> I do not think there is any reason to assume that the knowledge of the
> degree of the polynomial, would aid an attacker.
>
> Similarly a fingerprint of the secret if it is unrelated to the hash
> used in the polinomyal should leak no useful information,
>
> The length of such fingerpring (say 4 bytes) and the degree (1 byte)
> does not seem a big overhead for me.
>
> Remember that the biggest obstacle of Bitcoin is usability not security.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 29.03.2014, at 18:52, Alan Reiner <etotheipi at gmail.com
> <mailto:etotheipi at gmail.com>> wrote:
>
>> On 03/29/2014 01:19 PM, Matt Whitlock wrote:
>>> I intentionally omitted the parameter M (minimum subset size) from
>>> the shares because including it would give an adversary a vital
>>> piece of information. Likewise, including any kind of information
>>> that would allow a determination of whether the secret has been
>>> correctly reconstituted would give an adversary too much
>>> information. Failing silently when given incorrect shares or an
>>> insufficient number of shares is intentional.
>>
>> I do not believe this is a good tradeoff. It's basically obfuscation of
>> something that is already considered secure at the expense of
>> usability. It's much more important to me that the user understands
>> what is in their hands (or their family members after they get hit by a
>> bus), than to obfuscate the parameters of the secret sharing to provide
>> a tiny disadvantage to an adversary who gets ahold of one.
>>
>> The fact that it fails silently is really all downside, not a benefit.
>> If I have enough fragments, I can reconstruct the seed and see that it
>> produces addresses with money. If not, I know I need more fragments.
>> I'm much more concerned about my family having all the info they need to
>> recover the money, than an attacker knowing that he needs two more
>> fragments instead of which are well-secured anyway.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> <mailto:Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/8e874f60/attachment.html>

2023-06-07 15:16:41 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On 03/29/2014 02:00 PM, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote:
>> On 03/29/2014 01:19 PM, Matt Whitlock wrote:
>>> I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
>> I do not believe this is a good tradeoff. It's basically obfuscation of
>> something that is already considered secure at the expense of
>> usability. It's much more important to me that the user understands
>> what is in their hands (or their family members after they get hit by a
>> bus), than to obfuscate the parameters of the secret sharing to provide
>> a tiny disadvantage to an adversary who gets ahold of one.
>>
>> The fact that it fails silently is really all downside, not a benefit.
>> If I have enough fragments, I can reconstruct the seed and see that it
>> produces addresses with money. If not, I know I need more fragments.
>> I'm much more concerned about my family having all the info they need to
>> recover the money, than an attacker knowing that he needs two more
>> fragments instead of which are well-secured anyway.
> For what it's worth, ssss also omits from the shares any information about the threshold. It will happily return a garbage secret if too few shares are combined. (And actually, it will happily return a garbage secret if too *many* shares are combined, too. My implementation does not have that problem.)
Regardless of how SSSS does it, I believe that obfuscating that
information is bad news from a usability perspective. Undoubtedly,
users will make lots of backups of lots of wallets and think they
remember the M-parameter but don't. They will accidentally mix in some
3-of-5 fragments with their 2-of-4 not realizing they are incompatible,
or not able to distinguish them. Or they'll distribute too many
thinking the threshold is higher and end up insecure, or possibly not
have enough fragments to restore their wallet thinking the M-value was
lower than it actually was.
I just don't see the value in adding such complexity for the benefit of
obfuscating information an attacker might be able to figure out anyway
(most backups will be 2-of-N or 3-of-N) and can't act on anyway (because
he doesn't know where the other frags are and they are actually in
safe-deposit boxes)

2023-06-07 15:16:40 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On 03/29/2014 01:19 PM, Matt Whitlock wrote:
> I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
I do not believe this is a good tradeoff. It's basically obfuscation of
something that is already considered secure at the expense of
usability. It's much more important to me that the user understands
what is in their hands (or their family members after they get hit by a
bus), than to obfuscate the parameters of the secret sharing to provide
a tiny disadvantage to an adversary who gets ahold of one.
The fact that it fails silently is really all downside, not a benefit.
If I have enough fragments, I can reconstruct the seed and see that it
produces addresses with money. If not, I know I need more fragments.
I'm much more concerned about my family having all the info they need to
recover the money, than an attacker knowing that he needs two more
fragments instead of which are well-secured anyway.

2023-06-07 15:16:40 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:Armory has had "Fragmented Backups" for over a year, now. Advanced
users love it. Though, I would say it's kind of difficult to
standardize the way I did it since I was able to implement all the
finite field math with recursion, list comprehensions and python
arbitrary-big-integers in about 100 lines. I'm not sure how "portable"
it is to other languages. There's obviously better ways to do it, but I
didn't need a better way, because I don't need to support fragmentation
above M=8 and this was 100% sufficient for it. And I was the only one
doing it, so there was no one to be compatible with.
I won't lie, there's a lot of work that goes into making an interface
that makes this feature "usable." The user needs clear ways to identify
which fragments are associated with which wallet, and which fragments
are compatible with each other. They need a way to save some fragments
to file, print them, or simply write them down. They need a way to
re-enter fragment, reject duplicates, identify errors, etc. Without it,
the math fails silently, and you end up restoring a different wallet.
And they need a way to test that it all works. Armory did all this,
but it was no trivial task. Including an interface that will test up to
50 subsets of make sure the math produces the same values every time
(which still is not sufficient for some users, who won't be satisified
til they see they're wallet actually restored from fragments.
Also I put the secret in the highest-order coefficient of the
polynomial, and made sure that the other coefficients were
deterministic. This meant that if print out an M-of-N wallet, I can
later print out an M-of-(N+1) wallet and the first N fragments will be
the same. I'm not sure how many users would trust this, but we felt it
was important in case a user needs to export some fragments, even if
they don't increase N.
You might consider loading Armory in offline mode, create a wallet, and
then do a fragmented backup to see how we did it. I am extremely
satisfied with the interface, but it's most definitely an "advanced"
tool. But so is Armory ... which made it a good fit. But it might not
be for everyone.
-Alan
On 03/29/2014 11:44 AM, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
>> https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
> Thanks. This is great, although it makes some critical references to an ACM paper for which no URL is provided, and thus I cannot implement it.
>
> A distributed ECDSA notwithstanding, we still need a way to decompose a BIP32 master seed into shares. I am envisioning a scenario in which I might meet my sudden and untimely demise, and I wish to allow my beneficiaries to reconstruct my wallet's master seed after my death. I would like to distribute seed shares to each of my beneficiaries and some close friends, such that some subset of the shares must be joined together to reconstitute my master seed. Shamir's Secret Sharing Scheme is perfect for this use case. I am presently working on extending my draft BIP so that it also applies to BIP32 master seeds of various sizes.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:16:13 UTC

- reply

📅 Original date posted:2014-03-26
📝 Original message:This might be tangential, but the comment about "refund" chains reminded
me. Armory will be implementing multi-sig/linked wallets where a each
device has a parallel HDW branch and produces P2SH addresses. For those
types of wallets, I plan to allocate two chains /per signing
authority/. If you have a shared 2-of-2 wallet split between your phone
and your spouse's phone, your phone would distribute addresses on P2SH
chain 0 and generate change addresses on P2SH chain 1. Your spouse's
phone would use chains 2 and 3.
So if you and your spouse switch to a new app that supports M-of-N
linked wallets, it should search for coin history along the first 2*N
chains.
-Alan
On 03/26/2014 07:37 PM, Andreas Schildbach wrote:
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, Mike Hearn wrote:
>> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
>> our BIP32 wallet structures would be compatible - and I discovered that
>> only I was planning to use the default structure.
>>
>> Because I'm hopeful that we can get a lot of interoperability between
>> wallets with regards to importing 12-words paper wallets, we
>> brainstormed to find a structure acceptable to everyone and ended up with:
>>
>> /m/cointype/reserved'/account'/change/n
>>
>> The extra levels require some explanation:
>>
>> * cointype: This is zero for Bitcoin. This is here to support two
>> things, one is supporting alt coins based off the same root seed.
>> Right now nobody seemed very bothered about alt coins but sometimes
>> feature requests do come in for this. Arguably there is no need and
>> alt coins could just use the same keys as Bitcoin, but it may help
>> avoid confusion if they don't.
>>
>> More usefully, cointype can distinguish between keys intended for
>> things like multisig outputs, e.g. for watchdog services. This means
>> if your wallet does not know about the extra protocol layers
>> involved in this, it can still import the "raw" money and it will
>> just ignore/not see the keys used in more complex transactions.
>>
>> * reserved is for "other stuff". I actually don't recall why we ended
>> up with this. It may have been intended to split out multisig
>> outputs etc from cointype. Marek, Thomas?
>>
>> * account is for keeping essentially wallets-within-a-wallet to avoid
>> mixing of coins. If you want that.
>>
>> * change is 0 for receiving addresses, 1 for change addresses.
>>
>> * n is the actual key index
>>
>> For bitcoinj we're targeting a deliberately limited feature set for hdw
>> v1 so I would just set the first three values all to zero and that is a
>> perfectly fine way to be compatible.
>>
>> The goal here is that the same seed can be written down once, and meet
>> all the users needs, whilst still allowing some drift between what
>> wallets support.
>>
>> Pieter made the I think valid point that you can't really encode how
>> keys are meant to be used into just an HDW hierarchy and normally you'd
>> need some metadata as well. However, I feel interop between wallets is
>> more important than arriving at the most perfect possible arrangement,
>> which feels a little like bikeshedding, so I'm happy to just go with the
>> flow on this one.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140326/35055a7c/attachment.html>

2023-06-07 15:16:05 UTC

- reply

📅 Original date posted:2014-03-25
📝 Original message:I would echo the need for some kind of moderation.
I believe Peter Todd is an extremely intelligent individual, who has a
lot to offer the Bitcoin community. He has a firm grasp of a lot of
really deep Bitcoin concepts and his *technical* insight is generally
positive. Technically. But the way he communicates on this list is
*extremely* corrosive and breeds hostility. It makes it a scary place
to discuss things, with frequent, public ridicule of everything posted.
I agree that I would rather have a friendly environment to discuss
technicals, even if it means losing additional technical insight.
People who would explicitly insult other contributors intelligence and
character on a public list should be subject to some kind of negative
reinforcement. Maybe there's solutions other than outright banning.
-Alan
On 03/25/2014 01:37 PM, Jeff Garzik wrote:
> On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd <pete at petertodd.org> wrote:
>> For someone with 'Chief Scientist' as their job title, I'm surprised you
>> think so little of hard evidence and so much of idol worshipping.
> Peter, take this unprofessional, personal crap off-list.
>
> Mike's anecdote of hostility is not an isolated one. Just today, a
> bitcore developer commented on "Peter Todd's ..apocalyptic vision
> and... negative view on bitcoin" which turned off some other
> developers from participating more interactively.
>
> As I commented on IRC, open source projects are no strangers to people
> who simultaneously (a) make useful contributions and (b) turn
> potential contributors away with an abrasive or hostile attitude
> toward others. It's an unsolved problem in OSS, that I saw for 15+
> years in the Linux kernel community.
>
> For this list, as Mike suggested on IRC, introducing an openly stated
> moderation policy may be the one route.
>

2023-06-07 15:15:37 UTC

- reply

📅 Original date posted:2014-03-13
📝 Original message:On 03/13/2014 01:51 PM, Mike Hearn wrote:
>
> Well it looks like the consensus is to do it, instead of talking
> about it. I'm going to make sure we get uBTC into the next Armory
> release.
>
>
> Hmm - be careful with the word "consensus" here. A bunch of people on
> a mailing list does not make consensus ;)
>
> If you survey other wallets, you'll find most already switched to
> mBTC, that it took some effort to do so (look at the size of the
> patches for instance) and that probably, nobody is super-keen to
> change again so soon. So uBTC would make you different to most of the
> other wallets and services in wide usage.
>
> If Armory wants to do that, that's no problem, maybe it will be a
> competitive advantage - just saying, don't quote this thread as
> indicating some kind of community consensus.
>
> Wallets and services that are using mBTC (that I know of)
>
> blockchain.info <http://blockchain.info>
> MultiBit
> Bitcoin Wallet (Android)
> Hive
> Bitcoinity
> KnC Wallet (defaults to BTC but can be switched to mBTC in settings,
> uBTC not an option)
> Mullvad
> btcstore.eu <http://btcstore.eu>
>
> Doing a google search for [bitcoin "mBTC"] and [bitcoin "uBTC"], the
> former has a bunch of sites and services with prices in mBTC. The
> latter only has faucets, as far as I can tell, which sort of makes sense.
I actually was not aware that so many had already switched to mBTC. I
guess it shows how much I use other wallets.
You misunderstood my "consensus" comment. I was simply stating the
"consensus" of debating on the mailing list endlessly is not as
effective as doing it. Thus I was just going to do it and see who
follows. But that also assumed there was not a critical mass who'd
already switched -- I must admit I'm not so confident anymore...
I am/so strongly opposed //to mBTC /compared to uBTC, I was ready to
take a small leap of faith (with associated risks), to help push the
"consensus". Of course it would still remain configurable, but the
default will make a big difference.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/d0586965/attachment.html>

2023-06-07 15:15:37 UTC

- reply

📅 Original date posted:2014-03-13
📝 Original message:On 03/13/2014 01:24 PM, Mike Hearn wrote:
>
> 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.
>
>
> Unfortunately I think some people already started using XBT to mean
> the same as BTC (another ship that sailed: somehow Bhutan will have to
> live with it). So if some software started to redefine it to mean
> something else, that seems like a recipe for accidentally sending far
> too much or too little money by mistake.
>
There is also the benefit that if someone screws up BTC and uBTC, it's
likely to fail. Most people don't have 1e6 times as much money in their
wallet as they attempted to send in a single transaction. Similarly,
sending one-millionth of what you meant to is likely invalid or below
the dust limit.
Well it looks like the consensus is to do it, instead of talking about
it. I'm going to make sure we get uBTC into the next Armory release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/be24b2d1/attachment.html>

2023-06-07 15:15:35 UTC

- reply

📅 Original date posted:2014-03-13
📝 Original message:On 03/13/2014 10:32 AM, Jeff Garzik wrote:
> On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn <mike at plan99.net> wrote:
>> BitPay should use mBTC as well. Unless you can point to any major wallets,
>> exchanges or price watching sites that use uBTC by default?
>>
>> I think it is highly optimistic to assume we'll need another 1000x shift any
>> time soon. By now Bitcoin isn't obscure anymore. Lots of people have heard
> Such hand-wavy, data-free logic is precisely why community
> coordination is preferred to random apps making random decisions in
> this manner.
>
> mBTC is problematic because you do not need 1000x shift in value to
> produce annoyances for major accounting packages that are hard-limited
> to two decimal places. Further, spreadsheets hide information if
> formatting is configured naively -- that is, if formatting is
> configured for bitcoin the way it is configured for other currencies.
>
> Fundamentally, more than two decimal places tends to violate the
> Principle Of Least Astonishment with many humans, and as a result,
> popular software systems have been written with that assumption.
>
I whole-heartedly agree with Jeff. micro-BTC was the way to go to end
user confusion and make things easier for software systems which are
designed to handle money (i.e. two decimal places). I also echo the
sentiment about people being able to handle large numbers well.
We've been working with Marty Zigman who's creating a Bitcoin plugin for
NetSuite accounting platform, and he was already forced to switch
micro-BTC long ago for exactly the reasons described above. I think the
system will track up to 3 decimal places without causing all sorts of
heartache and automatic rounding.
Of course, as Mike said, this ship may have already sailed, but if
there's any way to revisit this, I'm there. We're just about to do
another Armory release and could support this very easily.

2023-06-07 15:15:08 UTC

- reply

📅 Original date posted:2014-03-12
📝 Original message:I might as well throw in a word about Armory. After our next release in
a couple weeks, we will be going full-speed at new wallets and BIP32
integration. Just like Jean-Pierre mentioned, we'll be using parallel
trees to generate P2SH addresses after sorting the keys
lexicographically. We plan to introduce the concept of a wallet
"bundle" (that name is far from concrete... I'd love a better word).
All wallets in a bundle are protected by the same backup, and stored in
the same file. The default behavior will be use new branches in the
same BIP32 tree when a user creates a new "wallet", though we will allow
multiple bundles in advanced and expert usermode (which is needed to
have watching-only wallets from a different seed created from an offline
computer).
However, we do plan to allow separate parties to create
multisig-intended wallets with public parts that can be exported and
combined with other users. We feel this is critical, as it allows for
linked wallets in which there was never a single-point of failure from
key-generation to signing. This is especially important for contexts
where employees may be handling a company's Bitcoins wallets.
On this topic, I have gotten a lot of inquiries into BIP 38 and 39. I
was not clear whether those BIPs were worth prioritizing ... i.e. is
there a general consensus from a variety of wallet developers that they
should be supported? Rather, I'm happy to start prioritizing them if
others do too, but I haven't spent much time trying to understand them
to even know if they're mature, yet.
-Alan
On 03/11/2014 08:29 PM, Jean-Pierre Rupp wrote:
> Hello people,
>
> We are working on some of this stuff. We had some very early draft on
> how we envisioned multisig happening. It is all implemented in Haskoin
> available as multiple repositories in Github. I am happy to see this
> gathering momentum.
>
> Our multisig system uses BIP-0032 HD wallets, and there will soon be
> BIP-0039 support for keys compatibility.
>
> Our wallet uses synced trees rooted at the extended pubkeys of the
> participants. Currently we are sorting public keys in the scripts to
> avoid ambiguity.
>
> Download haskoin-wallet:
>
> cabal install haskoin-wallet
>
> Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to
> bring transactions into the wallet. You must initialize first with a
> seed and create an account. It supports both regular and multisig accounts.
>
> Perhaps this can lead to interesting discussions on key exchange, and
> the appropriate handling of wallet metadata. I?d love to work on a
> proper standard that could lead us to compatible implementations.
>
> This document explains how we do it now:
>
> http://haskoin.com/~xeno/hd-multisig-wallet.html
>
> Cheers!
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140311/ed33704b/attachment.html>

2023-06-07 15:15:03 UTC

- reply

📅 Original date posted:2014-03-10
📝 Original message:As far as I'm concerned, the way forward is to scrap BIP 10 and build up
something new that is flexible and extensible. Also, my understanding
is that there may be room in the payment protocol for this stuff though
I'm not sure if it is really adapted well to all the steps: exchanging
public keys, creating multi-sig/P2SH addresses, proposing multi-sig
spends, bundling meta-data needed for lite/offline nodes, aggregating
signatures, and any other details.
When I start multisig integration into Armory (very soon!) I'll write a
list of requirements for the new format/process and post it here for a
wider discussion. Certainly, if the payment protocol can already handle
all this, that would be awesome.
-Alan
On 03/10/2014 08:04 PM, kjj wrote:
> I was trying to use bip10 for multisig and coinjoin, but there was a
> problem with it. I'll have to look back at my notes, but I thought I
> sent you a message about it. And then real life swallowed my bitcoin
> time...
>
> I think the bottom line was that it would be useful in the generic
> case with just one minor change. If there is interest, and it sounds
> like there just may be, I can dust off my notes and see where I left
> it. Probably should do it soon before someone implements it in PB or XML.
>
> Alan Reiner wrote:
>> Then of course I tried to do this with BIP 10
>> <https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki> when
>> Armory implemented offline-transactions two years ago. I got some
>> positive feedback, but no one wanted to help improve it, etc. I
>> guess nobody else was doing it and/or cared at the time. So I
>> continue to use BIP 10 even though it's pretty crappy. I wanted it
>> to be useful for multisig, too, but it has some deficiencies there
>> (it was done when Armory was extremely young and OP_EVAL was still on
>> the table).
>>
>> However, with all this activity, we should start thinking about that
>> and discussing it. Otherwise, I'll just do my own thing again and
>> probably end up with something that fits my own needs, but not anyone
>> else's. Really though, multisig shouldn't require all the same app
>> to work.
>>
>> -Alan
>>
>>
>> On 03/10/2014 01:49 PM, Gavin Andresen wrote:
>>> In my experience, best process for standardizing something is:
>>>
>>> 1) Somebody has a great idea
>>> 2) They implement it
>>> 3) Everybody agrees, "Great idea!" and they copy it.
>>> 4) Idea gets refined by the people copying it.
>>> 5) It gets standardized.
>>>
>>> Mutisig wallets are at step 2 right now. BIP is step 5, in my humble
>>> opinion...
>>>
>>>
>>>
>>>
>>> On Mon, Mar 10, 2014 at 1:39 PM, Drak <drak at zikula.org
>>> <mailto:drak at zikula.org>> wrote:
>>>
>>> I was wondering if there would be merit in a kind of BIP for a
>>> payment protocol using multisig?
>>>
>>> Currently, setting up a multisig is quite a feat. Users have to
>>> exchange public keys, work out how to get the public keys from
>>> their addresses. If one of the parties are not savvy enough, an
>>> malicious party could easily be setup that was 2 of 3 instead of
>>> 2 of 2 where the malicious party generates the multisig
>>> address+script and thus be able to run off with funds anyway.
>>>
>>> It's also terribly complex to generate and keep track of.
>>> There's been a nice attempt at creating an browser interface at
>>> coinb.in/multisig <http://coinb.in/multisig> but it still lacks
>>> the kind of ease with created by the payment protocol. If there
>>> was a BIP then it would go a long way to aiding future usability
>>> of multisig wallet implementations.
>>>
>>> What are your thoughts?
>>>
>>> Drak
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases
>>> and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Gavin Andresen
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/0f32ee9e/attachment.html>

2023-06-07 15:15:02 UTC

- reply

📅 Original date posted:2014-03-10
📝 Original message:Then of course I tried to do this with BIP 10
<https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki> when
Armory implemented offline-transactions two years ago. I got some
positive feedback, but no one wanted to help improve it, etc. I guess
nobody else was doing it and/or cared at the time. So I continue to use
BIP 10 even though it's pretty crappy. I wanted it to be useful for
multisig, too, but it has some deficiencies there (it was done when
Armory was extremely young and OP_EVAL was still on the table).
However, with all this activity, we should start thinking about that and
discussing it. Otherwise, I'll just do my own thing again and probably
end up with something that fits my own needs, but not anyone else's.
Really though, multisig shouldn't require all the same app to work.
-Alan
On 03/10/2014 01:49 PM, Gavin Andresen wrote:
> In my experience, best process for standardizing something is:
>
> 1) Somebody has a great idea
> 2) They implement it
> 3) Everybody agrees, "Great idea!" and they copy it.
> 4) Idea gets refined by the people copying it.
> 5) It gets standardized.
>
> Mutisig wallets are at step 2 right now. BIP is step 5, in my humble
> opinion...
>
>
>
>
> On Mon, Mar 10, 2014 at 1:39 PM, Drak <drak at zikula.org
> <mailto:drak at zikula.org>> wrote:
>
> I was wondering if there would be merit in a kind of BIP for a
> payment protocol using multisig?
>
> Currently, setting up a multisig is quite a feat. Users have to
> exchange public keys, work out how to get the public keys from
> their addresses. If one of the parties are not savvy enough, an
> malicious party could easily be setup that was 2 of 3 instead of 2
> of 2 where the malicious party generates the multisig
> address+script and thus be able to run off with funds anyway.
>
> It's also terribly complex to generate and keep track of. There's
> been a nice attempt at creating an browser interface at
> coinb.in/multisig <http://coinb.in/multisig> but it still lacks
> the kind of ease with created by the payment protocol. If there
> was a BIP then it would go a long way to aiding future usability
> of multisig wallet implementations.
>
> What are your thoughts?
>
> Drak
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases
> and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/2e157654/attachment.html>

2023-06-07 15:14:37 UTC

- reply

📅 Original date posted:2014-03-08
📝 Original message:On 03/08/2014 01:55 AM, Edmund Edgar wrote:
> On 4 March 2014 14:07, Odinn Cyberguerrilla
> <odinn.cyberguerrilla at riseup.net
> <mailto:odinn.cyberguerrilla at riseup.net>> wrote:
>
> Nothing is safe.
>
>
> This is true. To rephrase, imagine I gave you an ECC public key
> <ed_pub>, you gave me back a public key <odinn_pub> of your own
> devising, then I paid some money to the address resulting from
> add_pubkeys(<ed_pub>,<odinn_pub>) [1]. Can anyone either:
>
> a) Think of a way that Odinn could make an <odinn_pub> such that they
> could spend the resulting money without having <ed_priv>.
> b) Opine, somewhat knowledgeably, that this probably wouldn't be an
> easy thing to do, and they wouldn't be alarmed to see people running
> software that did this kind of thing.
>
> [1] https://github.com/vbuterin/pybitcointools/blob/master/pybitcointools/main.py#L173
Consider that I see your public key <a_pub> before I create and send you
my public key <b_pub>.
I create a new keypair, <c_pub> with <c_priv> which I know (it can be
any arbitrary key pair). But I don't give you <c_pub>, I give you
<b_pub> = <c_pub> minus <a_pub> (which I can do because I've seen
<a_pub> before doing this).
Sure, I don't know the private key for <b_pub>, but it doesn't matter...
because what
<b_pub> + <a_pub> = <c_pub> (mine)
You have no way to detect this condition, because you don't know what
c_pub/c_priv I created, so you can only detect this after it's too late
(after I abuse the private key)
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140308/7cfbe3a0/attachment.html>

2023-06-07 15:13:22 UTC

- reply

📅 Original date posted:2014-02-12
📝 Original message:Agreed. I'm not suggesting that malleability shouldn't be fixed or isn't a
problem. I would love to be able to leverage chained TX for Bitcoin
contracts. But that in its current state it doesn't have to be complicated
to deal with it.
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.
Sent from my overpriced smartphone
On Feb 12, 2014 11:38 AM, "Allen Piscitello" <allen.piscitello at gmail.com>
wrote:
> While that solution does work for many use cases, it does make it much
> harder to do anything needing chained transactions. Granted, this is the
> short term solution for current implementations, but having a transaction
> identifier that does not change does open up other use cases.
>
> For example, Alice wants to send coins to a multisignature address with
> Bob, such that both parties are required to spend the coins. Alice also
> requires for Bob to send coins to this address as well before they will
> proceed. Alice cannot guarantee that Bob will cooperate (and vice versa),
> so before she broadcasts the transaction to send to A+B, she sends Bob a
> transaction that spends her incoming transaction back to herself, but has a
> time lock of far into the future. Bob signs this, returns it to Alice, and
> she broadcasts her funding transaction. At this point, Bob disappears,
> loses his key, or just decides to spite Alice and her coins are locked.
> Since she has a refund transaction, she can broadcast it in a month and
> get her coins back. Except her funding transaction has been modified such
> that the txhash is different, so her refund is now invalid. She would need
> Bob to issue a new refund as soon as her funding transaction hits the
> blockchain if it is modified, which defeats the point of the trustless
> refund transaction.
>
> Longer term it would be more ideal have a canonical identifier for the
> transaction before it even gets to the chain to support these use cases,
> even if wallets are able to properly identify the status of it's
> transactions. Obviously this is a difficult problem to solve and cannot be
> implemented without breaking changes, but it would be a nice goal to be
> able to completely remove malleability. There are other important use
> cases where having a unique identifier just for internal accounting is
> insufficient.
>
> -Allen
>
>
> On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner <etotheipi at gmail.com> wrote:
>
>> I think the solution is simply to encourage Bitcoin software developers
>> to design their software to use this static ID, instead of the full
>> transaction hash. If MtGox had talked those IDs instead of the TX ID,
>> their software would've correctly identified the mutated transactions and
>> there would be no problem.
>>
>> Armory is slightly different, since it doesn't deal with the same stuff
>> as exchanges do. But it didn't have any problems with malleability because
>> it doesn't track anything by ID, it only pays attention to whether inputs
>> and outputs are related to your wallets. It's not necessarily hard to do
>> it this way, people just have to be aware of it.
>>
>> -Alan
>>
>> Sent from my overpriced smartphone
>> On Feb 12, 2014 10:15 AM, "Rune Kjær Svendsen" <runesvend at gmail.com>
>> wrote:
>>
>>> Instead of trying to remove the possibility of transaction
>>> malleability, would it make sense to define a new, "canonical
>>> transaction hash/ID" (cTxID), which would be a hash of the part of the
>>> transaction data which we know is not malleable, and have clients use
>>> this cTxID internally, thus making the traditional transaction hash
>>> irrelevant for a client to function correctly?
>>>
>>> We already have a non-malleable transaction hash: the hash that is
>>> signed, ie. the transaction with each scriptSig replaced by the
>>> scriptPubKey it redeems. This could be the cTxID.
>>>
>>> Or is this simply a too fundamental change to the way bitcoin-qt (and
>>> all other clients) work in order to be feasible?
>>>
>>> As far as I can see, it completely solves the issue of not having a
>>> canonical ID for a transaction, but it also increases the
>>> computational requirements for a node. For one, as far as I can see,
>>> it requires the node to index all transactions, because in order to
>>> calculate a cTxID, it would be necessary to fetch all transactions
>>> referred to by the transaction in question, in order to pull in the
>>> scriptPubKeys that are redeemed.
>>>
>>>
>>> On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete at petertodd.org> wrote:
>>> > On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
>>> >> Hello all,
>>> >>
>>> >> it was something I planned to do since a long time, but with the
>>> >> recent related issues popping up, I finally got around to writing a
>>> >> BIP about how we can get rid of transaction malleability over time.
>>> >>
>>> >> The proposed document is here: https://gist.github.com/sipa/8907691
>>> >>
>>> >> I expect most rules to not be controversial. Maybe rules 1 and 3, as
>>> >> they require modifications to wallet software (Bitcoin Core 0.9 and
>>> >> BitcoinJ already implement it, though) and potentially invalidate some
>>> >> script functionality. However, these new rules remain optional and
>>> >> controlled by an nVersion increase.
>>> >>
>>> >> Comments please!
>>> >
>>> > You should probably add making CHECKMULTISIG require the dummy value to
>>> > be exactly equal to OP_FALSE; verifying that in the transaction itself
>>> is
>>> > laborious. A more subtle example is we may want both CHECKSIG and
>>> > CHECKMULTISIG to fail the transaction if the signature is invalid but
>>> > not exactly equal to OP_FALSE; some transaction forms are significantly
>>> > more compact if you can have failed signatures, but that's a source of
>>> > malleability. (are there counter examples people can think of?)
>>> >
>>> >
>>> > But as I said on IRC, I'm a bit hesitant to bake in assumptions about
>>> > malleability when we have no solid idea if ECC signatures are or are
>>> not
>>> > malleable on a fundemental level; if "whack-a-mole" anti-malleability
>>> is
>>> > all we've got it could be ugly if a break is found. Similarly, we may
>>> > find we missed something, or some needed change makes the malleability
>>> > rules difficult to work with for some new script type that is required.
>>> >
>>> > I'd rather see a new CHECKSIG mode for the case where malleability
>>> > absolutely must be eliminated - certain multi-party protocols - and fix
>>> > wallet software instead. (the malleability problems people see are
>>> > closely related to inability to handle double-spends and reorgs) But I
>>> > can easily see that being an impossible goal engineering wise...
>>> >
>>> > --
>>> > 'peter'[:-1]@petertodd.org
>>> > 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Managing the Performance of Cloud-Based Applications
>>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> > Read the Whitepaper.
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>> > _______________________________________________
>>> > Bitcoin-development mailing list
>>> > Bitcoin-development at lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Android apps run on BlackBerry 10
>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>> Get your Android app in front of a whole new audience. Start now.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience. Start now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/aab9621c/attachment.html>

2023-06-07 15:13:21 UTC

- reply

📅 Original date posted:2014-02-12
📝 Original message:I think the solution is simply to encourage Bitcoin software developers to
design their software to use this static ID, instead of the full
transaction hash. If MtGox had talked those IDs instead of the TX ID,
their software would've correctly identified the mutated transactions and
there would be no problem.
Armory is slightly different, since it doesn't deal with the same stuff as
exchanges do. But it didn't have any problems with malleability because it
doesn't track anything by ID, it only pays attention to whether inputs and
outputs are related to your wallets. It's not necessarily hard to do it
this way, people just have to be aware of it.
-Alan
Sent from my overpriced smartphone
On Feb 12, 2014 10:15 AM, "Rune Kjær Svendsen" <runesvend at gmail.com> wrote:
> Instead of trying to remove the possibility of transaction
> malleability, would it make sense to define a new, "canonical
> transaction hash/ID" (cTxID), which would be a hash of the part of the
> transaction data which we know is not malleable, and have clients use
> this cTxID internally, thus making the traditional transaction hash
> irrelevant for a client to function correctly?
>
> We already have a non-malleable transaction hash: the hash that is
> signed, ie. the transaction with each scriptSig replaced by the
> scriptPubKey it redeems. This could be the cTxID.
>
> Or is this simply a too fundamental change to the way bitcoin-qt (and
> all other clients) work in order to be feasible?
>
> As far as I can see, it completely solves the issue of not having a
> canonical ID for a transaction, but it also increases the
> computational requirements for a node. For one, as far as I can see,
> it requires the node to index all transactions, because in order to
> calculate a cTxID, it would be necessary to fetch all transactions
> referred to by the transaction in question, in order to pull in the
> scriptPubKeys that are redeemed.
>
>
> On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete at petertodd.org> wrote:
> > On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
> >> Hello all,
> >>
> >> it was something I planned to do since a long time, but with the
> >> recent related issues popping up, I finally got around to writing a
> >> BIP about how we can get rid of transaction malleability over time.
> >>
> >> The proposed document is here: https://gist.github.com/sipa/8907691
> >>
> >> I expect most rules to not be controversial. Maybe rules 1 and 3, as
> >> they require modifications to wallet software (Bitcoin Core 0.9 and
> >> BitcoinJ already implement it, though) and potentially invalidate some
> >> script functionality. However, these new rules remain optional and
> >> controlled by an nVersion increase.
> >>
> >> Comments please!
> >
> > You should probably add making CHECKMULTISIG require the dummy value to
> > be exactly equal to OP_FALSE; verifying that in the transaction itself is
> > laborious. A more subtle example is we may want both CHECKSIG and
> > CHECKMULTISIG to fail the transaction if the signature is invalid but
> > not exactly equal to OP_FALSE; some transaction forms are significantly
> > more compact if you can have failed signatures, but that's a source of
> > malleability. (are there counter examples people can think of?)
> >
> >
> > But as I said on IRC, I'm a bit hesitant to bake in assumptions about
> > malleability when we have no solid idea if ECC signatures are or are not
> > malleable on a fundemental level; if "whack-a-mole" anti-malleability is
> > all we've got it could be ugly if a break is found. Similarly, we may
> > find we missed something, or some needed change makes the malleability
> > rules difficult to work with for some new script type that is required.
> >
> > I'd rather see a new CHECKSIG mode for the case where malleability
> > absolutely must be eliminated - certain multi-party protocols - and fix
> > wallet software instead. (the malleability problems people see are
> > closely related to inability to handle double-spends and reorgs) But I
> > can easily see that being an impossible goal engineering wise...
> >
> > --
> > 'peter'[:-1]@petertodd.org
> > 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
> >
> >
> ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/5c046193/attachment.html>

2023-06-07 15:11:54 UTC

- reply

📅 Original date posted:2014-01-13
📝 Original message:On 01/13/2014 03:14 PM, Peter Todd wrote:
> On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
>> How is this different from the proposal I have made?
>>
>> You distribute the root public key (but not chaincode!) of a BIP32
>> branch. You can put your root key on a business card if you want. Then
>> when someone wants to pay you, you simply give them the multiplier and
>> root key (they already have the root key, but should verify). The
>> multiplier does not reveal the chaincode, thus keeping it private, but
>> it does allow them to confirm that the final address they are paying is
>> derived from that root key they know belongs to you ("Please pay address
>> X; oh btw, X=rootKey*mult").
>>
>> You can /choose/ to reveal that a given payment address is linked to
>> your root key without any compromise of privacy. Or you can choose to
>> ignore it and just give them a bare address the old way and still
>> maintain privacy. What advantages does "stealth addresses" have over
>> this scheme? You could extend it using some kind of deterministic
>> sub-branching and/or ECDH to create multiple payment addresses without
>> querying the payee.
>
> Basically stealth addresses *are* your scheme, using the blockchain as a
> low or even no overhead communication channel for the payor to give the
> payee that multiplier without bidirectional communication.
>
> In the business card example I can't easily take your business card and
> just send you some money without that transaction being linked to public
> information. (your business card)
It's not public. When I say "please pay me" I also say "use this
multiplier". The multiplier isn't published, and it's not publicly
discoverable without my wallet (or access to my email). The address
remains private between you and me. As you said, it could be
discoverable if the email is discoverable, but I'm not seeing how how
critical that really is.
There's a lot of complexity around this constraint (possibly involving
new/secondary private keys, extra outputs, relying on change outputs,
and/or using 3rd parties to help look for transactions). I'm not
convinced that what is being gained is really worth that extra complexity.
By contrast, what I proposed, that does require sending sending the
payer a multiplier once, is easy to implement in any BIP 32 wallet,
doesn't require any special address formats, and achieves 98% of the
same benefits without any special computation. I guess I'm just not
convinced that it's really necessary for people to be able to send
others payments without contacting them (and/or hiding the evidence a
payment was made even if they communications were discovered).
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140113/d7ebb30c/attachment.html>

2023-06-07 15:11:52 UTC

- reply

📅 Original date posted:2014-01-13
📝 Original message:How is this different from the proposal I have made?
You distribute the root public key (but not chaincode!) of a BIP32
branch. You can put your root key on a business card if you want. Then
when someone wants to pay you, you simply give them the multiplier and
root key (they already have the root key, but should verify). The
multiplier does not reveal the chaincode, thus keeping it private, but
it does allow them to confirm that the final address they are paying is
derived from that root key they know belongs to you ("Please pay address
X; oh btw, X=rootKey*mult").
You can /choose/ to reveal that a given payment address is linked to
your root key without any compromise of privacy. Or you can choose to
ignore it and just give them a bare address the old way and still
maintain privacy. What advantages does "stealth addresses" have over
this scheme? You could extend it using some kind of deterministic
sub-branching and/or ECDH to create multiple payment addresses without
querying the payee.
I had planned to implement this system and push for people to accept it
because I don't see any downsides to it. It can easily be integrated
into a WoT (with signed root keys), or CA system piggybacking on SSL.
-Alan
On 01/13/2014 02:44 PM, Drak wrote:
> On 13 January 2014 19:40, Roy Badami <roy at gnomon.org.uk
> <mailto:roy at gnomon.org.uk>> wrote:
>
> At the moment, I can give them a business card with a Bitcoin address.
> Being able to give out a business card with a stealth address would be
> a major advance.
>
>
> My thoughts exactly.
>
> Drak
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140113/85d58fe9/attachment.html>

2023-06-07 15:11:49 UTC

- reply

📅 Original date posted:2014-01-18
📝 Original message:*Avoiding ECDH calcs on every blockchain transaction (and avoiding the
prefix thing):*
Can we skip the whole ECDSA/ECDH thing, and use the second key pair for
encryption instead? Then we don't need any ephemeral keys. We use the
much simpler scheme like I mentioned before (just root keys and
multpliers), but instead of requesting a multiplier from the person
receiving the money, the payer can create their own multiplier and
encrypt it into an OP_RETURN msg (using the secondary public key of the
receiver). When they do this, they append a deterministic identifier to
it, so that the receiver can immediately identify it upon decryption.
Basically, the receiver simply attempts decryption of every OP_RETURN
message, and if the identifier is there, they immediately know that the
tx is theirs, and that the other bytes of the decrypted message is the
multiplier used.
Of course, using something like ECIES and forcing the receiver to
attempt decryption of every OP_RETURN tx may not be any faster than the
ECDH we've already talked about here. But with this, we are not tied to
any particular crypto. Isn't there a much faster asymmetric scheme that
we can use? I've heard people talk about ed25519, though I'm not sure
it can be used for encryption. I'd bet money there is an asymmetric
_/encryption/_//algorithm that would be fast enough to not burden the
receiver.
Here's how I envision it:
--Alice gives out her business card that has public key X (BIP32 root),
and public key Y (fastCrypto)
--Bob generates a random 32-byte nonce, and EC-multiplies Alice's public
key by it. He prepares a transaction sending coins to that address (Z)
--Bob also computes a deterministic identifier, perhaps hash(pubKeyX ||
addrZ)[8:]. Bob appends the those 8 bytes to the multiplier, and
encrypts all of it with Alice's fastCrypto key, Y. He puts that
message in the OP_RETURN output.
--Alice's wallet will attempt decryption of every OP_RETURN message.
First she computes hash(pubKeyX, addrZ)[8:], and then decrypts the
message with the fastCrypto private key. If the tx is actually hers,
the last 8 bytes will match the identifier, and she knows to use the
other 32 bytes as a multiplier. If it doesn't, it's irrelevant to her
and she moves on.
[**Should probably use 24-byte values for the multipliers (or hashes of
24-byte values), so that adding 8 bytes makes the whole message an even
32 bytes which is better for encryption]
Doesn't this have the exact same properties as the original proposal
(including compatibility with CoinJoin)? But it all depends on having
fast asymmetric encryption.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140117/ef9e2937/attachment.html>

2023-06-07 15:09:39 UTC

- reply

📅 Original date posted:2013-11-14
📝 Original message:I really like the XBT idea. It makes a lot of sense to match the ISO
currency symbol (though the ISO guys will have to adjust the way they've
defined the "XBT"). And I do agree that going right to uBTC and
skipping mBTC makes sense, too.
I'd prefer them not be called "micro bitcoins." I really want to call
them "microbes" ... but I'm not sure that has the right flavor for money
transfer :) "Please give me 872 microbes". Perhaps we just call them
"bits." Or even "micros" or "microbits". As I write this, I realize
there's probably 872 threads on the forums about this already...
But we would want to promote a consistent term, to avoid further
confusion when people use different names for the new unit. It's not
guaranteed to be successful, but if we pick a good name, and build it
into the interface on the first release pushing the new unit, we have a
chance to make the transition even easier.
On 11/14/2013 05:31 PM, Mark Friedenbach wrote:
> Whoops, this was meant for the list:
>
> Drawing on analogues from national currencies, it's also possible to
> alleviate the confusion by switching currency symbols, e.g. to XBT or
> NBC (New Bitcoin).
>
> 1 XBC == 1 uBTC
>
> On 11/14/13 2:03 PM, Jeff Garzik wrote:
> > Go straight to uBTC. Humans and existing computer systems handle
> > numbers to the left of the decimals just fine (HK Dollars, Yen).
> > The opposite is untrue (QuickBooks really does not like 3+ decimal
> > places).
>
> > - Jeff
>
> > On Nov 14, 2013 4:40 PM, "Mark Friedenbach" <mark at monetize.io
> > <mailto:mark at monetize.io>> wrote:
>
> > 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 from human
> > scale everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't
> > think very many people on this list would consider bitcoin
> > overvalued in the long term perspective.
>
> > Better to go through a confusing renumbering only once.
>
> > Mark
>
>
------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
>
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131114/c8bca901/attachment.html>

2023-06-07 15:09:32 UTC

- reply

📅 Original date posted:2013-11-14
📝 Original message: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 needs to
be taken into consideration when it comes to user perception (which is
one of the reasons we would make such a change in the first place).
"Holy crap these fees are huge! I thought Bitcoin didn't have fees!"
On 11/14/2013 04:55 PM, Allen Piscitello wrote:
> I also would prefer to go straight to uBTC as the "standard wallet unit". It works out
perfectly with Satoshi's being the decimal units. Something that costs
$10USD would be 25000uBTC. This isn't a problem for a place like South
Korea, where 10USD is about 10,000 Won, so we aren't even off on a scale
of usable currencies in major economies.
>
> The downsides are obviously confusion (causing mistakes resulting in
lost coins), and possibly from a psychological perspective on price
(uBTC are worthless!). On the other hand, it also might help people
feel like they are getting in on the ground floor still (I own 100,000
uBTC!), and reduce the perception the Bitcoins are not divisible (I have
heard several people worry that 21 million is not enough units).
>
> Alan's ideas for compatibility with multiple fields will also be
helpful to solving the confusion issue.
>
>
>
> On Thu, Nov 14, 2013 at 3:15 PM, Mark Friedenbach <mark at monetize.io
<mailto:mark at monetize.io>> wrote:
>
> 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 from human scale
> everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very
> many people on this list would consider bitcoin overvalued in the long
> term perspective.
>
> Better to go through a confusing renumbering only once.
>
> Mark
>
> On 11/14/13 12:01 PM, Alan Reiner wrote:
> > ... I'm also of the opinion that it's freakin' hard to change the
> > base unit in such an established system. There is no easy way to
> > do this that doesn't cause more heartache than it's worth...
>
>
------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native
Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP
server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and
Native!
>
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
<mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
>
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131114/862ccf75/attachment.html>

2023-06-07 15:09:31 UTC

- reply

📅 Original date posted:2013-11-14
📝 Original message:I highly recommend that if we make any move towards this, that the
software show verification in both/all units.
For instance, there should be 3 input fields, one for "BTC", one for
"mBTC" one for "uBTC". As the user enters a value in one of the fields,
it would automatically update the other fields with the converted value
as they type. This makes it really difficult to get it wrong... if
you're typing "10" into the BTC field, thinking it's mBTC, you'll see
10,000 mBTC showing up in the other box as you type. Similarly, it
should display all units on all verification windows. Users may also
use it for sanity checking conversion between units.
Personally, I'm of the opinion that this change is important in the long
run: the current price makes Bitcoin *intimidating* to new users. But
I'm also of the opinion that it's freakin' hard to change the base unit
in such an established system. There is no easy way to do this that
doesn't cause more heartache than it's worth. But it's possible if you
make it idiot-proof enough, and roll it out in the least inconvenient way.
-Alan
On 11/14/2013 06:45 AM, Melvin Carvalho wrote:
> Rationale
> =======
>
> Given the recent rise in value there seems to be anecdotal evidence
> that 1 bitcoin being so high is putting off a lot of normal buyers,
> because they feel that putting down $400+ and only getting "1 coin",
> or having to buy in multiples of 1 whole coin, is too much.. only
> after it being explained that they can buy fractional amounts to they
> regain interest, apparently happening increasingly.
>
>
> Straw Poll
> ========
>
> 6 months ago there was a straw poll on this
>
> https://bitcointalk.org/index.php?topic=220322.0
>
> Roughly 2/3 of respondents favoured switching
>
> A further 20% said to switch after it hits 1000
>
> Satoshi's comments:
> ================
>
> Eventually at most only 21 million coins for 6.8 billion people in the
> world if it really gets huge.
>
> But don't worry, there are another 6 decimal places that aren't shown,
> for a total of 8 decimal places internally. It shows 1.00 but
> internally it's 1.00000000. If there's massive deflation in the
> future, the software could show more decimal places.
>
> If it gets tiresome working with small numbers, we could change where
> the display shows the decimal point. Same amount of money, just
> different convention for where the ","'s and "."'s go. e.g. moving
> the decimal place 3 places would mean if you had 1.00000 before, now
> it shows it as 1,000.00.
>
> https://bitcointalk.org/index.php?topic=44.msg267#msg267
>
>
> Would now be a good time to start thinking about changing the default
> display in the software. Perhaps initially it could be a dropdown
> display option, then at some point mbtc becomes the default?
>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131114/bfef8905/attachment.html>

2023-06-07 15:03:37 UTC

- reply

📅 Original date posted:2013-06-26
📝 Original message:Although I'd still prefer my original request, I get much of what I want
from your guys' recommendation. It complicates the wallet design,
because it requires tracking and associating a matrix of addresses for
each wallet, instead of a single linear list. But if this is what it's
going to take then I will go along.
Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external" chain
used for distributing addresses, and j=1 is the "internal" chain for
sending change. The CONOPs (concept of operations) for the extended
wallet would be like Jeremy described:
- Chains with j>=2 would be independent address chains carved out for
individuals relationships
- Add wallet code to individually associate each j-value with a
particular identity
- Update the wallet code to pool all the addresses in all j-chains when
calculating the balance of the wallet and/or creating transactions
- When choosing to generically "Receive Bitcoins", will pick the next
address from the j=0 chain
- Will have to add extra function to "Receive Bitcoins" button to allow
creation of new contacts/identities.
- Change will always go to the next address in j=1, no matter which
chains are used to provide inputs.
- Add code to figure out lookaheads for each alternate chain. Not just
each chain, but looking ahead a couple chains, too. Luckily, the
lookahead doesn't have to be very big for chains j>=1
- Add an interface to display and choose the different chains in your
wallet, and export the pubkey&chaincode in some soon-to-be-standardized
format.
- Add code and interface to receive and track alternate j-chains from
other clients/users, and maintain those. Should we try associating
incoming and outgoing chains? What happens if they do it wrong? Meh...
Just as one final swipe at this idea, you can see that I gotta do quite
a bit of work to support the multi-chain idea, and adds a little extra
burden on the user to maintain the organization of the wallet. This
would all be totally unnecessary with a simple alternate encoding.
Granted, I think the multi-chain idea is good, and one that I will
probably implement anyway, but it seems like overkill in terms of
developer complexity, and interface complexity to achieve something much
simpler. Developers of much simpler/lightweight clients would probably
find this prohibitive.
On another note: I thought we weren't encouraging automatic payments
without requesting from the other party...? It makes me uneasy, but it
sounds like group thought has converged on that being acceptable. I
bring it up, because there are situations where it makes sense, but it
sounds unsafe for general users. Alice will give Bob his own chain for
sending Alice money, then a year later Bob will send money automatically
to Alice not realizing that the wallet was lost, retired or
compromised. It's not that Bob can't ask for a new address, it's that
if the interface says "Send Money to Alice", that looks legit enough
that Bob may not feel it necessary to check with Alice first. That's
more of an interface issue though. We can add a warning to "check with
the recipient that they still have access to wallet 3cQ398x", etc. But
I just know someone is going to lose money anyway...
-Alan
On 06/20/2013 03:32 AM, Mike Hearn wrote:
> Agree with Jeremy and once the payment protocol work is further along
> I'd like to see us define an extension that lets you send payment
> requests containing public keys+chain codes, so further payments can
> be made push-style with no recipient interaction (e.g. for repeated
> billing). How apps choose to arrange their chains internally seems
> like an area for experimentation. I definitely want to implement HD
> wallets in bitcoinj to allow this and if that means not using the same
> tree structure as in the BIP then so be it.
>
>
> On Thu, Jun 20, 2013 at 5:54 AM, Jeremy Spilman <jeremy at taplink.co
> <mailto:jeremy at taplink.co>> wrote:
>
> > BIP 32 already specifies how to use the first three tree levels:
> M/i/j/k,
> > i~wallet, j~Internal/External, k~address. The first level is
> actually
> > type-1 derived, and thus we cannot create an arbitrary number of
> them
> > without pre-computing them from the offline wallet. So it's not
> "free" to
> > create new wallets unless we redefine how the levels work.
>
> Initially I was thinking that you would share the public key and
> chain code
> from [m/i'/0] so that you can receive payments at [m/i'/0/k], for
> a unique
> value of 'i' for each receive chain.
>
> For the case of generating new receive chains from a *watch-only*
> wallet, as
> you say, the options are to either keep a cache of
> PubKey/ChainCode for
> unused [m/i'] or simply increment 'j' past 1 for an existing
> [m/i'/j] -- the
> concept of 'internal/'external' and change addresses at Depth=2
> don't make
> sense for handing out receive chains to lots of people anyway, and
> certainly
> BIP32 doesn't *require* 0 <= j <= 1. So I think incrementing 'j'
> is the way
> to go here...
>
> The "default" layout of BIP32 does NOT mean that implementations
> should not
> check for transactions with j > 1. That would be a useless
> constraint and
> obviously self-limiting. It might be helpful to add to the
> 'Compatibility'
> section some minimum expectations about how a wallet should be
> 'probed' when
> imported. If you don't feel completely free to monotonically
> increment 'j'
> to your hearts content to achieve major usability benefits, then I
> say BIP32
> could use some clarifying.
>
> BTW - the spec calls for addition not multiplication now, so we
> should call
> it the 'Addend' not the 'Multiplier' :-)
>
> > Do these extra wallet chains behave as different wallets, or
> sub-wallets?
>
> They could, but they certainly don't need to! A single-wallet
> implementation treats this merely as an address-generation
> algorithm, and
> does not expose any hierarchy to the user interface. The user just
> "magically" gets the ability to send multiple payments to their
> contacts
> without immediately sacrificing their privacy
> (http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/).
> Everything
> goes into the same ledger, balance, coin pool, etc. Most of the
> code base is
> unaware BIP32 is even in use.
>
> While it is *possible* to support separate ledgers, balances, etc.
> it is
> certainly not required, and you get all the benefits either way.
>
> I think, since your proposal generates and receives payments into
> BIP32-style addresses, we both need similar underlying wallet
> code. The only
> difference is that you are passing the Kpar for [m/i'/0/k] and the
> *result*
> of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and
> cpar, and
> leaving 'k' out of it, letting the receive choose 'k'.
>
> > For instance, maybe there's a benefit to using the same parent
> pubkey
> > across multiple services, as a form of identity. If I don't
> want that, I
> > use your method. If I do want that, I use my method.
>
> I think it's a interesting idea using static public keys as a
> means for
> persistent identity and hence security from MitM. If you want a shared
> public key across multiple services we could just combine both
> ideas and get
> all the benefits, by making the data structure { ParentPubKey, Addend,
> ChainCode }:
>
> ParentPubKey: Public key of m/i' -- 33 bytes
> Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
> ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
>
> All that remains secret is the ChainCode from [m/i'] -- and of
> course the
> private keys. The ParentPubKey is a common value across multiple
> services,
> corresponding to user's identity rooted in [m/i']. Each service
> gets their
> own 'j'. ParentPubKey + Addend gives you the PubKey of [m/i'/j].
> With the
> ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
> increasing 'k'. Again, from the user perspective all transactions
> under
> [m/i'] can be presented in a single ledger, or not.
>
> Anyway, fundamentally my feedback is if you are designing for
> persistent
> long-term relationships, you could build in a mechanism for generating
> address chains so you don't need any further communication after
> the initial
> exchange, and it need not complicate the wallet.
>
> Thanks,
> --Jeremy
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130626/ab610b9b/attachment.html>

2023-06-07 15:03:36 UTC

- reply

📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 05:58 PM, Jeremy Spilman wrote:
> Hi Alan,
>
>> “BIP 32 does not prescribe a way to use multiple chains like you described
>> with the convenient type-2 derivation (though we could create a variant
>> that does)”
> What do you think is missing from BIP32 for this? A wallet creates a
> child-node using the public / type-2 CDF, hands out the PubKey/ChainCode,
> and then generally expects transactions to come in starting at /0 and
> incrementing monotonically.
>
You are suggesting that creating new wallet chains are the only
operation needed to achieve the functionality I'm requesting. I
disagree. I am okay with using different wallets for different parties
*/if the user wants to/*. But there are orthogonal use-cases to having
a single wallet serve as a single identity that can be used across
multiple transactions or services. And doing so is much simpler
conceptually for the user, and simpler in implementation for the app
developer.
BIP 32 already specifies how to use the first three tree levels:
M/i/j/k, i~wallet, j~Internal/External, k~address. The first level is
actually type-1 derived, and thus we cannot create an arbitrary number
of them without pre-computing them from the offline wallet. So it's not
"free" to create new wallets unless we redefine how the levels work.
Even if we assume the simplest case where the first level is actually
type-2 derived and it costs nothing to create separate wallets for each
contact/party:
-- Do these extra wallet chains behave as different wallets, or
sub-wallets?
-- Should their balances be bundled into a single wallet or displayed
separately?
-- When a user tries to spend, does he have to specify which wallet(s)
he's spending from?
-- Should the app developer be required to implement a multiple-wallet
interface, and handle cross-wallet spending just to achieve this simple
mechanism? Sure, they could instead implement a tiered wallet hierarchy
with primary wallets and sub-wallets... wait this just got complicated.
All that complexity just to support this identity mechanism that can be
included purely as an alternative address encoding with a single
wallet. With my request, the user can't have one wallet and distribute
most of his addresses the normal/anonymous way, but certain apps would
choose to use the alternate encoding as a form of identity. If the user
feels the need to create a separate wallet for certain operations to
separate his identities, that is his option if the software supports
multiple wallets. But it's not the only way.
To achieve what I'm suggesting is useful and trivial to implement even
in the simplest wallet applications.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/350ab33e/attachment.html>

2023-06-07 15:03:35 UTC

- reply

📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 03:29 PM, Jeremy Spilman wrote:
> If you have two parties who want to form a persistent relationship, by
> exchanging and verifying public keys beforehand, then I think the
> canonical way to do this with BIP32 is for the parties to exchange
> PubKey and *ChainCode*.
>
> I don't understand the use case for handing out individual
> multipliers, if what you desire is a persistent relationship. If each
> party dedicates a child-wallet for receiving coins, and saves a
> PubKey/ChainCode for sending coins, the two parties can transaction
> securely forever without ever exchanging any more information, and
> without any address reuse.
>
> I think ideally, the default behavior is that wallets always dedicate
> a new child node {PubKey, ChainCode} to each party they transact with.
> At the presentation layer, you have a "contact" and each contact has a
> transaction history. You can send coins to a contact at any time, and
> internally the wallet picks the next address in their sequence. Any
> funds received on pubkeys from contact's sequence are attributed to
> that contact. The wallet can organize the contacts, and roll-up the
> transaction history into 'ledgers' and 'balances' however they want --
> it could be based on the underlying BIP32 hierarchy or perhaps not.
> The cost of watching large a number of pubkeys, even if you 'look
> ahead' 100 pubkeys for each contact, is relatively small versus the
> benefits.
>
>
What you just described is complimentary to what I am proposing. There
is nothing stopping you from doing it that way, except that it may be
inconvenient in some circumstances. BIP 32 does not prescribe a way to
use multiple chains like you described with the convenient type-2
derivation (though we could create a variant that does). And all
separate chains with their 100-address look-aheads may be fine for your
desktop or mobile device, but maybe not a HW signing device with 128 kB
of memory.
So, some use cases might prefer having a different parent public key
[and chaincode] per contact, some may prefer to synchronize across many
contacts. For instance, maybe there's a benefit to using the same
parent pubkey across multiple services, as a form of identity. If I
don't want that, I use your method. If I do want that, I use my
method. Given its simplicity, I don't know why both can't be options.
Actually, it doesn't have to be specific to the payment protocol, it can
just be alternative address encoding that some apps would use if they
have a need for it.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/bc4628e8/attachment.html>

2023-06-07 15:03:33 UTC

- reply

📅 Original date posted:2013-06-20
📝 Original message:On 06/20/2013 05:10 AM, Jeremy Spilman wrote:
>> which could involve proving something to a third party that has not seen
>> the communication between payer and payee.
> OK - I think I follow now. So a third-party who does not see any of the
> communication between the payer and payee only knows the HASH160. Let's say
> the payee denies receipt of the funds....
>
> It's easy to prove what public key it was sent to (it's the preimage), but
> you can't prove the parent of that public key. You can provide any number of
> ParentPubKey * Multiplier that could have been used, so the 3rd party is
> unconvinced by a "matching" ParentPubKey * Multiplier.
>
> However, if you calculated the destination using: PubKeyParent *
> HMAC(Multiplier,PubKeyParent) as Timo said, now if you give the 3rd party a
> PubKeyParent and Multiplier (or Addend) that produces the destination
> address, you've proven the payment is in fact spendable by PubKeyParent, and
> they can't deny receipt. Very cool.
>
> Sorry for "echoing" this back, it took me a little while to work it out, so
> I thought I'd write it down. Hope I got it right...
>
> If you give {PubKey, ChainCode} you do get this feature. If you give
> {ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} you're back to
> having plausible deniability.
>
> If BIP32's CKD'((Kpar, cpar), i) was actually HMAC(HMAC(cpar, i), Kpar) you
> could give HMAC(cpar, i) instead of Addend, and then you would get this
> feature; a way to 'skip down' a level in the wallet hierarchy, keep the
> 'chain of custody' so to speak back to the ParentPubKey intact, without
> having to disclose the ChainCode. Meh...
>
>
I agree, if we used Timo's suggestion, that seems to clean up the
remaining uncertainties with this recommendation. I'm not convinced
those uncertainties matter in this situation, where there is no question
about the parent public key. That is the part of the process that was
already verified, per my previous examples. But certainly, for this to
be more versatile it would need that.
If I modify my request to match Timo's recommendation, then it loses the
benefit of being a simple, non-disruptive extension of BIP 32. I'm not
fond of deviating from BIP 32, as it kind of defeats one of the benefits
of BIP 32: standardization. And I'm not inclined to make an
Armory-specific wallet variant.
But I can't tell if the benefits are lost on you, or you just don't
think they are worth it (or I'm overstating them). I'm strongly opposed
to bring extra wallets/chains into this equation /*just*/ to get a
benefit that can be had with a simple alternative encoding. This isn't
a question of which is better, it's a matter of recognizing that both
forms have usefulness and should both be supported.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130620/a9b89205/attachment.html>

2023-06-07 15:03:32 UTC

- reply

📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 02:36 PM, Adam Back wrote:
> This maybe simpler and trivially compatible with existing type2 public
> keys
> (ones that are multiples of a parent public key): send an ECDSA
> signature of
> the multiplier, and as we know you can compute ("recover") the parent
> public
> key from an the ECDSA signature made using it.
>
> Adam
>
> On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
>> [q-th root with unknown no discrete log artefact]
>>
>> If it was a concern I guess you could require a proof of knowledge of
>> discrete log. ie as well as public key parent, multiplier the
>> address must
>> include ECDSA sig or Schnorr proof of knowledge (which both demonstrate
>> knowledge of the discrete log of Q to base G.)
It's a cool trick but requiring a signature on each multiplier defeats
one of the purposes of a deterministic wallet. I don't want to have to
explicitly export a whole bunch of signatures from my offline system
just to exercise this address option. The "observer wallet" should be
able to do anything it needs to on its own, without help from the
offline wallet.
Unless you mean that there is a one-time signature from the offline
computer that works for all addresses, that can be exported with the
observer wallet...? If all you want to do is prove that /someone/ owns
that private key, you could send {Sign(MagicString), Multiplier}. So
it becomes one signature operation *per wallet*, but creating new
wallets would require going back to the offline computer for that
one-time signature. That's better than the alternative, but it's still
extra bloat for the wallet apps.
Either way, I'm not convinced that these are a problem for the specified
use cases I outlined. In cases where you have a persistent business
relationship, they need to verify the parent public key exchange
anyway. After that, the software doesn't technically require the
transmission of the PubKey, it only needs the Name/ID of the party and
the multiplier and it will fetch the PubKey from its data store. Or it
is transmitted and the payer verifies it's correct. Computing an
alternate {PubKey', Mult'} that produces the same address and then using
it in a MitM attack doesn't work here if the two parties pre-verified
the public keys.
In the case that a business is checking whether the cashout address of a
customer is the same as the last time: if the first payout was not
replaced by an attacker, then the business already has the correct
public key in their DB and a replacement of further payout requests will
fail validation. If the first payout was replaced... well that could've
been done anyway (with or without this alternate form), and the customer
wouldn't have received their money and the whole process would be
flagged and terminated before further transactions.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/55223863/attachment.html>

2023-06-07 15:03:30 UTC

- reply

📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 10:25 AM, Timo Hanke wrote:
> Since you mention to use this in conjunction with the payment protocol,
> note the following subtlety. Suppose the payer has to paid this address
> called "destination":
>> Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
>> checksum)
> Also suppose the payee has spent the output, i.e. the pubkey
> corresponding to "destination", which is PubKeyParent * Multiplier[i],
> is publicly known. Then anybody can (in retrospect) create arbitrary
> many pairs {PublicKeyParent, Multiplier} (in particular different
> PublicKeyParent) that lead to the same "destination".
>
> Depending on what you have in mind that the transaction should "prove"
> regarding its actual receiver or regarding the receiver's PubKeyParent,
> this could be an unwanted feature (or it could be just fine). If it is
> unwanted then I suggest replacing
> PubKeyParent * Multiplier[i] by
> PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
> which eliminates from the destination all ambiguity about PubKeyParent.
>
> This modification would not be directly compatible with BIP32 anymore
> (unfortunately), but seems to be better suited for use in conjunction
> with a payment protocol.
>
> Timo
It's an interesting observation, but it looks like the most-obvious
attack vector is discrete log problem: spoofing a relationship between
a target public key and one that you control. For instance, if you see
{PubA, Mult} produces PubB and you have PubC already in your control
that you want to "prove" [maliciously] is related to PubB, then you have
to find the multiplier, M that solves: M*PubC = PubB. That's a
discrete logarithm problem.
I'm not as familiar as you are, with the available operations on
elliptic curves, but it sounds like you can produce essentially-random
pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
the private key associated with those public keys. It's an interesting
point, and there may be a reason to be concerned about it. Though, I
don't see it yet.
-Alan

2023-06-07 15:03:29 UTC

- reply

📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 08:19 AM, Melvin Carvalho wrote:
>
> Generally in favour of hierarchical deterministic wallets.
>
> Will this new style of address make it into the block chain? I'd be
> less keen on that.
>
> I'm finding BIP0032 quite hard to read right now, but perhaps that's
> because I'm less familiar with the material than some. However,
> there's little things like it never actually defines a deterministic
> wallet in the Abstract. But, I'll keep trying to understand and see
> if I can use the test vectors.
>
>
>
This has nothing to do with the blockchain. This is simply an alternate
way to encode an address, in the event that you want to prove that this
address is linked to another address. The same thing ends up in the
blockchain, either way.
Either:
(1) I give you a Hash160 address which shows up in the blockchain
or
(2) I give you {PubKey, Mult}, then you compute PubKey*Mult then hash it
to get the same Hash160 I would've given you in (1)
I can always give you version #1, and that's what everyone does right
now. Version #2 is essentially the same, but used if you want to give
the other party extra information (such as the root public key, so that
the next time you send a version#2 address they can see they are from
the same root public key).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/1038df24/attachment.html>

2023-06-07 15:03:27 UTC

- reply

📅 Original date posted:2013-06-18
📝 Original message:_*Goal*_: An alternative address format made possible by BIP 32, which
allows one to specify a "Wallet ID" and "One-time payment" code, instead
of the standard one-use Base58-Hash160 addresses. This allows parties
with a persistent relationship to be able to prove that payment
addresses they provide each other are linked to a particular wallet,
reducing exposure to MitM attacks without the need for SSL or a web of
trust, and without compromising the privacy of either party. For
instance, this could be used between businesses that frequently do
business, by exchanging and verifying public keys beforehand, or could
be used by an exchange to identify if a customer withdrawal address is
related to their last deposit address, and if not enforce extra
authentication measures.
_*Background*__:_
I haven't been following the payment protocol discussions/development
much, so I apologize if this has already been addressed. I'm calling
it "wallet-linkable" addresses, which would be an optional second form
for sending someone your address. With BIP 32, the address is computed
by the payee (the person sending the address to receive money):
Standard Address ~ Base58(0x00 || hash160(PubKeyParent *
Multiplier[i]) || checksum)
What I'd like to do is have the option, when specifying an address
through the payment protocol, to send *just* the {PublicKeyParent,
Multiplier[i]} and let the receiver of that address compute the address
on their own. This is no significant burden on the receiver, but it
does provide the useful property that they can recognize when addresses
specified in this way come from the same wallet -- because the
PubKeyParent will be the same. Remember, this is _optional_ for the
person providing the address.
One nice, accidental feature of BIP 32 is that the Multiplier[i] used
above does not actually reveal the "chaincode" (I think Pieter started
calling it the "tweak"). It is derived from the chaincode but doesn't
reveal it. Therefore, the payer sees the parent public key, but that's
not useful to derive any of the other addresses unless they also have
the chaincode. But they can verify that the PublicKeyParent is
identical between transactions, and thus is accessible only to that
wallet. It allows them validate a specific address provided by the
payee, but not generate or identify any other addresses.
*_Use Cases:_*
(1) So, just like with PGP/GPG, when two parties decide they will start
a relationship, they can start by exchanging the public keys of their
wallet and verify them in a reliable manner. After that, when one party
requests a payment address from the other, they can optionally send
{PubKey, Multiplier}, and the payer's software will identify the owner
of that address, or let you select who you think the address belongs to
and it will verify it. If the payee's system is compromised and address
is replaced, the address received by the payer won't validate. This
doesn't help if the side sending the money is compromised.
(2) When a customer first provides a deposit to an exchange, it will
send money from an address in their wallet and the software will provide
the exchange the {PubKey,Mult}. When the customer later provides a
withdrawal address, the site can automatically trust the address as long
it is provided in the alternate form and the public keys match. If they
don't, it might be the same customer just requesting a withdrawal to a
different wallet, which is fine, but they'll have to go through an extra
verification step to do so.
_*Downsides:*_
Multi-sig/P2SH - The only way this works with P2SH, violates one of the
goals of P2SH slightly, but may not matter much if it's all done under
the hood by the software. Instead of providing a 20-byte hash of a
script, you provide all the public keys and multipliers for the
individual addresses. The payer's software automatically verifies all
addresses and creates the P2SH script itself (after a divine decree that
public keys will always be sorted lexicographically in the multi-sig
script). The blockchain still benefits from the "compression" of moving
the bulky scripts to the TxIn, but it does require revealing more
information than is necessary for the payer to pay the payee. But it
may not /really/ be a problem, given the benefits. It might just be
slightly longer strings to exchange during initialization and for each
transaction.
I have various reasons I'd like to use this, and it'd be nice to have
some community backing, so I don't have to twist anyone's arm to trust
me that it's legit.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130617/d52177a4/attachment.html>

2023-06-07 15:03:08 UTC

- reply

📅 Original date posted:2013-06-10
📝 Original message:One major problem I see with this, no matter how well-thought-out it is,
it's unlikely that those with money will participate. Those with the
most stake, likely have their private keys behind super-secure
accessibility barriers, and are not likely to go through the effort just
to sign votes. Not only that, but it would require them to reveal their
public key, which while isn't technically so terrible, large amounts of
money intended to be kept in storage for 10+ years will prefer to avoid
any exposure at all, in the oft-chance that QCs come around a lot
earlier than we expected. Sure, the actual risk should be pretty much
non-existent, but some of the most paranoid folks are probably the same
ones who have a lot of funds and want 100.00% of the security that is
possible. They will see this as wildly inconvenient.
I think this a great thought experiment, and I'd like to see where this
idea goes, in terms of designing ways for a decentralized community to
find consensus for important decisions, but I don't think that any idea
that requires users to dig up their private keys is going to be feasible
(or possibly reconstruct them from pieces and/or get multiple
signatures). Especially if the system requires some kind of persistent
voting.
-Alan
On 06/10/2013 12:46 PM, Mark Friedenbach wrote:
>
> 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. Within Freicoin, we
> have looked at is as a possibility for determining how to distribute
> the demurrage, a proposal we are calling 'Republicoin' due to the fact
> that with proxy voting we expect a system to emerge similar to the
> government budgeting in parliamentary republics. Distributed,
> non-coersive government by protocol, if you will.
>
> So anyway, even if you get shot down, please continue to pursue this
> proposal. It very likely has uses that you haven't thought of yet.
>
> Cheers,
> Mark
>
> On 6/9/13 9:09 PM, John Dillon wrote:
> > It has been suggested that we leave the decision of what the
> blocksize to be
> > entirely up to miners. However this leaves a parameter that affects
> every
> > Bitcoin participant in the control of a small minority. Of course we
> can not
> > force miners to increase the blocksize if they choose to decrease
> it, because
> > the contents of the blocks they make are their decision and their
> decision
> > only. However proposals to leave the maximum size unlimited to allow
> miners to
> > force us to accept arbitrarily large blocks even if the will of the
> majority of
> > Bitcoin participants is that they wish to remain able to validate the
> > blockchain.
>
> > What we need is a way to balance this asymetrical power relationship.
>
> > Proof-of-stake voting gives us a way of achieving that balance.
> Essentially for
> > a miner to prove that the majority will of the poeple is to accept a
> larger
> > blocksize they must prove that the majority has in fact voted for that
> > increase. The upper limit on the blocksize is then determined by the
> median of
> > all votes, where each txout in the UTXO set is one vote, weighted by
> txout
> > value. A txout without a corresponding vote is considered to be a
> vote for the
> > status quo. To allow the voting process to continue even if coins
> are "lost"
> > votes, including default votes, are weighted inversely according to
> their age
> > in years after 1 year. IE a vote with weight 1BTC that is 1.5 years
> old will be
> > recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1
> day old
> > and 6 months old UTXO are treated equivalently. The 1 year minimum
> is simply to
> > make voting required no more than once per year. (of course, a real
> > implementation should do all of these figures by block height, IE
> after 52,560
> > blocks instead of after 1 year)
>
> > A vote will consist of a txout with a scriptPubKey of the following
> form:
>
> > OP_RETURN magic vote_id txid vout vote scriptSig
>
> > Where scriptSig is a valid signature for a transaction with nLockTime
> > 500,000,000-1 spending txid:vout to scriptPubKey:
>
> > OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL
>
> > vote_id is the ID of the specific vote being made, and magic is
> included to
> > allow UTXO proof implementations a as yet unspecified way of
> identifying votes
> > and including the weighted median as part of the UTXO tree sums. (it
> also
> > allows SPV clients to verify the vote if the UTXO set is a Patricia
> tree of
> > scriptPubKeys) vote is just the numerical vote itself. The vote must
> compute
> > the median, rather than the mean, so as to not allow someone to skew
> the vote
> > by simply setting their value extremely high. Someone who still
> remembers their
> > statistics classes should chime in on the right way to compute a
> median in a
> > merkle-sum-tree.
>
> > The slightly unusual construction of votes makes implementation by
> wallet
> > software as simple as possible within existing code-paths. Votes
> could still be
> > constructed even in wallets lacking specific voting capability
> provided the
> > wallet software does have the ability to set nLockTime.
>
> > Of course in the future the voting mechanism can be used for
> additional votes
> > with an additional vote_id. For instance the Bitcoin community could
> vote to
> > increase the inflation subsidy, another example of a situation where
> the wishes
> > of miners may conflict with the wishes of the broader community.
>
> > Users may of course actually create these specially encoded txouts
> themselves
> > and get them into the blockchain. However doing so is not needed as
> a given
> > vote is only required to actually be in the chain by a miner wishing to
> > increase the blocksize. Thus we should extend the P2P protocol with
> a mechanism
> > by which votes can be broadcast independently of transactions. To
> prevent DoS
> > attacks only votes with known vote_id's will be accepted, and only for
> > txid:vout's already in the blockchain, and a record of txouts for
> whom votes
> > have already broadcast will be kept. (this record need not be
> authoritative as
> > its purpose is only to prevent DoS attacks) Miners wishing to
> increase the
> > blocksize can record these votes and include them in the blocks they
> mine as
> > required. To reduce the cost of including votes in blocks 5% of
> every block
> > should be assigned to voting only. (this can be implemented by a
> soft-fork)
>
> > For any given block actual limit in effect is then the rolling
> median of the
> > blocks in the last year. At the beginning of every year the value
> considered to
> > be the status quo resets to the mean of the limit at the beginning
> and end of
> > the interval. (again, by "year" we really mean 52,560 blocks) The
> rolling
> > median and periodic reset process ensures that the limit changes
> gradually and
> > is not influenced by temporary events such as hacks to large
> exchanges or
> > malicious wallet software. The rolling median also ensures that for
> a miner
> > the act of including a vote is never wasted due to the txout later
> being spent.
>
> > Implementing the voting system can happen prior to an actual
> hard-fork allowing
> > for an increase and can be an important part of determining if the
> hard-fork is
> > required at all.
>
> > Coercion and vote buying is of course possible in this system. A
> miner could
> > say that they will only accept transactions accompanied by a vote
> for a given
> > limit. However in a decentralized system completely preventing vote
> buying is
> > of course impossble, and the design of Bitcoin itself has a fundemental
> > assumption that a majority of miners will behave in a specific kind
> of "honest"
> > way.
>
> > A voting process ensures that any increase to the blocksize genuinely
> > represents the desires of the Bitcoin community, and the process
> described
> > above ensures that any changes happen at a rate that gives all
> participants
> > time to react. The process also gives a mechanism for the community
> to vote to
> > decrease the limit if it turns out that the new one was in fact too
> high. (note
> > how the way the status quo is set ensures the default action is for
> the limit
> > to gradually decrease even if everyone stops voting)
>
> > As many of you know I have been quite vocal that the 1MB limit
> should stay. But
> > I would be happy to support the outcome of a vote done properly,
> whatever that
> > outcome may be.
>
> >
> ------------------------------------------------------------------------------
> > How ServiceNow helps IT people transform IT departments:
> > 1. A cloud service to automate IT design, transition and operations
> > 2. Dashboards that offer high-level views of enterprise services
> > 3. A single system of record for all IT processes
> > http://p.sf.net/sfu/servicenow-d2d-j
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > .
>
>
>
>
>
>
------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130610/6c87044b/attachment.html>

2023-06-07 15:02:00 UTC

- reply

📅 Original date posted:2013-05-15
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You can do this right now, with Armory. If you switch Armory to Expert
usermode, you can combine coin-control with unsigned transactions to do
exactly this. It's because Armory doesn't "lock" coins used in previous
unsigned transactions, until they're actually broadcast and confirmed to
be "out in the wild". This was done for simplicity to avoid people
getting arbitrarily-locked coins, even though it means you end up
accidentally double-spending if you try to create two different unsigned
transactions from the same wallet without sign&broadcasting the first one.
So here's what you do:
(1) Switch to "Expert" usermode in Armory
(2) Open any wallet (you don't need a watch-only wallet, full wallet is
fine)
(3) In the "Send Bitcoins" window, click coin-control
(4) Create a transaction using one sufficiently large input
(5) Click "Create Unsigned Transaction" and save it
(6) Repeat 3-5 with the same coin, but sending to yourself, specify a
larger fee
(7) Go into "Offline Transactions" and "Sign and Broadcast Transactions"
(8) Load tx1, sign & broadcast
(9) Load tx2, sign & broadcast
This only works if your Bitcoin-Qt/bitcoind client has the
replace-by-fee patch, since Armory uses Bitcoin-Qt/bitcoind as a gateway
to the network. Otherwise, the second tx will be DOA. But you don't
have to mess with Armory other than switching it to Expert mode to get
to the coin-control feature.
- -Alan
P.S. -- If you try this, Armory is likely to not show the second tx as
having ever happened (Bitcoin-Qt will send it back to us and we ignore
it because we already have a tx). But if your Bitcoin node has the
modification, it /will/ reach the network
On 05/15/2013 08:19 AM, Peter Todd wrote:
> On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote:
>> So I'm offering 2BTC for anyone who comes up with a nice and easy to use
>> command line tool that lets you automagically create one version of the
>> transaction sending the coins to the desired recipient, and another
>> version sending all the coins back to you, both with the same
>> transaction inputs. In addition to creating the two versions, you need
>> to find a way to broadcast them both simultaneously to different nodes
>> on the network. One clever approach might be to use blockchain.info's
>> raw transaction POST API, and your local Bitcoin node.
>
> Oh, and while we're at it, a good starting point for your work would be
> Gavin's spendfrom utility in the contrib/spendfrom directory in the
> Bitcoin-QT respository.
>
> Also please do keep in mind that it's much better for the community if
> an attack is demonstrated first, followed by releasing the code some
> time later.
>
>
>
>
------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRk441AAoJEBHe6b77WWmFZNQP/02t6cQkhih/CcA1oSCM72np
KMRW0Z+piHShORxLyhMX3cIpi3ICJ2lJ/Pm6GfDn74oSHq8wipIFoV88xhy810bL
MnJtbPH900v8PHh/ji2nWMig9NibeUa1zV9/tp31rYjUT3mmMoC4yQlyxKII8GWK
iignkAHV/UL5kQGmhmr1RKN127cthSMeIzAYWXfIWVObPNm85pvizVZdgqzSK73h
vwdfeFOelNbVn8ZCNT19OsxWfAKZSaBMywAX95wQBs0BtY2ZgDRmeXa6MdQKpXGW
KP3O2zjjJC2CKc4+L6elMfsoL1doEsk35w/GuI4HZK4MLAI8BChi6ZPnAYjdRvir
eHeszyxkKDCEaJ9JPLA/AszqkYHIB+56wTtrpVb1duyTwuqgVT5dcpMPIH8bDqjq
k3I8C9zCSeQ6JgyvOd8grKJchRtq0SOWYt2bB3ytePzwOs+W+6mRenb/WtMt2dQg
ntDTEIG7pCsWHenipeTBzvJNqeSsAAoIXnkGY20iDxCB+uFkTzisoCQqpOIglArm
vD+Cl2nv3OKU3NTVTUt2VinoFskezI7xvsxHD8xs2V/hrlpPbPRAo+l7ER6aTazj
wrONfmllHSE2XCM7wb/bX3gBNmsM3zUIgSBmNSH/SQeTy8PvwvlkZ/RRYmtVSmHL
rUTp7x4U63JiIDO1jj+T
=JiPo
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130515/9f78f5e6/attachment.html>

2023-06-07 11:47:01 UTC

- reply

📅 Original date posted:2013-04-17
📝 Original message:One of the big topics of recent past on IRC is "malleability" of
transactions: to what extent can someone /else /change your signed
transaction without affecting its validity? In the past I used to
consider this just annoying, but not so malicious. But in terms of HFT,
it sounds like malicious behavior is possible:
To recap the procedure:
(1) Alice creates a transaction, Tx1, for 10 BTC to a 2-of-2-{Alice,
Bob} address. It has a locktime of 30 days in the future.
(2) Before signing the transaction, she gets Bob to sign a transaction,
Tx2, from 2-of-2-{Alice, Bob} back to herself. That transaction
references the Tx1 by hash.
(3) Any time in the next 30 days, Alice can sign an alternate Tx2
transactions reducing the amount returned to self and increasing amount
to Bob, as a method of paying Bob more. Bob doesn't need to broadcast
anything except for the last one, 29 days later.
It was originally conceived that Bob couldn't do anything malicious,
because Alice gets Bob to sign Tx2-spending-Tx1 before she gives him
Tx1. The problem is that Bob can follow her process, then
broadcast/mine Tx1' (Tx1-prime), which has a different number of 0x00
pad bytes in the signatures, or "flips the sign" of one of the s-values
in the signature, thus changing the hash of Tx1.
By doing this, Bob has now created a transaction, Tx1', that Tx2 no
longer returns to Alice. It's not flat-out theft, because Tx1 still
sends to a 2-of-2 address requiring both of their signatures. But Bob
didn't risk anything to do this, besides his reputation/trust. He now
has Alice's money locked and can hold it for ransom, since she needs his
signature to do move it. He could offer his signature for half of it.
Of course, these types of HFT contracts will usually be between parties
that have some mutual respect/history. Thus, they are not usually
zero-trust. But we should find a way to try to close that, if
possible. For instance, if the malleability was reduced to one bit, you
could just have Bob sign two different transactions before Alice
broadcasts Tx1. The two tx would be from either variant. But I know
there's too many bits of malleability in the transaction serialization
for that to work. Is there any way to avoid this?
-Alan
On 04/17/2013 05:48 AM, Mike Hearn wrote:
> When this system was first being discussed, Gavin was concerned that
> miner incentives were to ignore replacements because it meant extra
> work and the replacement might have equal or lower fees than before
> (or indeed, no fees). He proposed two solutions: one is to
> progressively raise the fee on each replacement. The other is to
> specify lock time in terms of blocks and then step it backwards once
> for each replacement, thus ensuring that by replacing the transaction
> you get to claim any attached fee earlier.
>
> It should be apparent that both solutions can be implemented by
> whichever application is running the contract - the core Bitcoin
> network and software is agnostic either way.
>
> Now, Gavin and I disagreed on whether this would actually be
> necessary. As I already pointed out, both solutions seriously reduce
> the utility of HFT because they limit how often you can update the
> contract. Instead of an online game billing you per second, maybe it
> can only do it per minute or per 10 minutes with the lock time
> solution because otherwise you run out of blocks, and with
> ever-increasing fees perhaps the contract becomes too expensive to
> justify after a while.
>
> So it'd be nice if this ended up not being necessary. Experience
> indicates that rational miners typically don't pursue a short-termist
> profit-at-any-cost agenda - free transactions have always been
> included in blocks, miners include transactions even though you could
> avoid a lot of complexity by just not including any at all, etc. Some
> miners like BTC Guild have actually sacrificed significant amounts of
> money for the good of the system. You can see this in terms of
> rational self interest - miners earn Bitcoins thus it's in their
> interest for Bitcoins to be as useful as possible, as that is what
> gives them value. Or you can see it in terms of ideologically-driven
> altruism. Or both.
>
> If I were to implement an application that used tx replacement, I
> would probably start with replacements that don't change the fees and
> don't count down the lock time field. We can then observe whether
> miners bother changing their software to behave differently, or
> whether the inherent utility of the application is enough to convince
> them to play by the default rules. Ideally at least one application
> made possible by this feature is a "killer app" - something so useful
> / unique / compelling that people want to obtain Bitcoin just to use
> it. If someone can find such an app, then rational miners should want
> tx replacement to work as reliably as possible because it boosts the
> value of their earnings.
>
> There are some other misc details - reactivation requires that we bump
> the protocol version and start relaying non-final transactions to new
> nodes again. Those nodes should relay replacements but not let them
> enter wallets unless/until the wallet software itself can handle them
> better, for instance, by communicating via APIs anticipated
> confirmation times. This is something for individual wallet APIs to
> handle on their own, and just ignoring non-final transactions is a
> perfectly workable approach for Bitcoin-Qt.
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130417/2d60998b/attachment.html>

2023-06-07 10:46:03 UTC

- reply

📅 Original date posted:2012-12-04
📝 Original message:This discussion sounds to be veering slightly off track. I think we should
be focusing on how we will ease the transition for new users to get on the
network and use it. Talking about the necessity and costs of running full
nodes in the future is important, but irrelevant here: unless we don't
want users who aren't willing to run full nodes, we need to accommodate
users who want to simply "use" the network, not necessarily "support" it. *I'm
making an assumption here that we want new users whether they use a full
node or not*. Greg's point looks like it's veering towards "we don't want
to grow the network unless we're going to get more full nodes out of it."
I'm of the opinion, like Mike Hearn, that the number of full nodes needed
for a healthy network is *not* O(N) in the number of users of the network.
I expect it to be something more like O(sqrt(N))... or perhaps there's
even an upper limit above which the network gets no benefit, even if all 7
billion humans were using it. (the bottleneck would be size of blocks and
CPU processing power at that point, not a shortage of full nodes). Would
we rather have a system that is "full-node-or-nothing" and drive away users
that won't support the network, or accommodate those users with various
gradations of participation?
I believe my proposal for an address-based meta-chain (or something like
it) is *exactly* what is needed in the long run. It could almost obsolete
this entire discussion. However, as Greg pointed out there is a long,
treacherous path between the theory I presented, and a working&robust
implementation that can serve as the backbone for future SPV nodes. I have
every intention to help pioneer that when Armory has other major features
completed (such as multi-sig), but it's not something that we can even
consider in the near- or medium-term as a solution to rely on. I'd be
surprised if any such solution existed in the next 6-12 months.
I think it is very much in everyone's interest here to encourage new users
to start "using" Bitcoin, even if they don't "support" it. As long as
there is a convenient channel for interested users to get more information
about the system, the benefits of spending the effort to run a full node,
and the features available in more-advanced clients that they might benefit
from, then I'm not personally concerned about a shortage of full nodes, and
we should carry forward with the idea of promoting SPV nodes for the
really-new users.
-Alan
On Tue, Dec 4, 2012 at 4:41 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn <mike at plan99.net> wrote:
> >> It sounds to me that you're insisting that you're asking people who
> >> oppose degrading our recommendations to commit to a costly rushed
> >> development timeline. I think this is a false choice.
> >
> > Hardly. I don't have any particular timeline in mind. But I disagree
> > we have "forever". New ideas have a certain time window to take off
> > and become credible.
>
> Marketing initiatives have limited windows. This matters, perhaps,
> when you're some VC pumping cash into a startup with the hopes of
> being the next stockmarket pump and dump darling. Outside of that
> people use whatever they use because it works for them.
>
> And by the numbers Linux desktops are more common than they've ever
> been— and certainly Linux kernel _systems_ half the people I know have
> one in their pocket and its hard to go more than a few hours without
> touching one. To some extent the "Year of the Linux desktop" is a bit
> like the "Year of being able to turn lead into gold" ... we can turn
> lead into gold now, but the particle accelerators, atomic power, and
> atomic weapons enabled by the same technology are far more interesting
> due to the particle realities of this. So we didn't get the ubiquitous
> Linux desktop: We got the ubiquitious Linux server, the ubiquitous
> Linux-kernel smart phone, the ubiquitous Linux television, media
> player, HVAC controller, etc. instead.
>
> Desktops— well, that didn't meet people's hopes though I think not for
> the lack of marketing on the part of Linux, but because Apple stepped
> up and produced middle ground products that attracted a larger
> audience. Especially as MSFT dropped the ball. They did some things
> better, had a running start, and had a non open source software
> business model which made reaping rewards easier.
>
> But I don't see how any of this has anything to do with Bitcoin...
> Except for the point that if Bitcoin doesn't become the money system
> everyone uses and instead becomes the money system infrastructure all
> the systems people use depend on— just as Linux has with the desktop,
> where it might not be on the desktop but its in router firmware, cloud
> servers, and just about everything else— I wouldn't consider that much
> of a loss.
>
> > time window, eventually people just give up and move on. Does anyone
> > take desktop Linux seriously anymore? No. "The year of desktop Linux"
> > is a joke. People took it seriously in 2001 but despite great progress
> > since, the excitement and attention has gone. There were steady
> > improvements over the last 10 years but nobody is creating desktop
> > Linux startups anymore
>
> Bitcoin already missed its first— and perhaps only— fad window in any
> case. Today people say "Bitcoin? Thats still around? I thought it got
> hacked". ... thanks to compromised centralized services.
>
> > It's unclear we need to have every man and his dog run a full node.
>
> Every man and his dog? Perhaps not. But as many as can— probably so.
>
> If we depend on the organic need for full nodes to overcome cost and
> effort to run one there will always be major incentives to let someone
> else do that, and the system would have its equilibrium right on the
> brink of insecurity. Perhaps worse, since insecurity is most obvious
> retrospectively. Security doesn't make for a good market force.
>
> > Tor is a successful P2P network where the number of users vastly
> > outstrips the number of nodes, and exit nodes in particular are a
> > scarce resource run by people who know what they're doing and commit
> > to it.
>
> Tor is a distributed but controlled, by a small number of directory
> authority operators, system.
>
> It is a good system. But it has a trust model which is categorically
> weaker than the one in Bitcoin. If you want something where a
> majority of a dozen signing keys— hopefully in the hands of trusted
> parties— can decide the state of the system you can produce someting
> far superior to Bitcoin— something that gives near instant
> non-reversable transactions, something that gives good client security
> without the complexity of a SPV node, etc.
>
> But that isn't Bitcoin.
>
> > Even with no incentives, they were able to obtain
> > the resources they need.
>
> And yet every tor user— if the have the bandwidth available can be a
> full internal relay and the software nags them to do it (and also nags
> them to act as invisible bridges for blocking avoidance), and every
> user is technically able to run an exit (though they don't bludgeon
> users to do that, because of the legal/political/technical issues
> involved). To do any of this doesn't require a user to switch to
> different software, and the tor project has previously opposed client
> only software.
>
> > So why should Bitcoin be different?
>
> It's less different than you make it out to be— but it _is_ different.
> Bitcoin is a distributed currency. The value of bitcoin comes from
> the soundness of its properties and from the persistence of its
> security. If the integrity of the distributed ledger is disrupted the
> damage produced, both in funds stolen and in undermining the
> confidence of the system, can be irreversible. Because Bitcoin's value
> comes from confidence in Bitcoin and not from the specific
> functionality of Bitcoins (they're random numbers that sit on your
> disk) even if the ledger isn't actually compromised but people
> reasonably believe it could be compromised that undermines the value.
> Tor, on the other hand, is a functioning system whos value depends on
> its current usefulness, and not the past or future security.
>
> Compare in your mind— Say everyone just found out that at block
> 420,000 Bitcoin would stop enforcing signature correctness or block
> subsidy values (and this wasn't going to be fixed), and you also found
> out that one year from now Tor would hand over their sites, source
> code repositories, and directory authority keys to Iran (and you have
> no suspicion that they already had done so). How fast would you stop
> using Tor vs how fast would to sell whatever coins you could?
>
> > We can easily send a clear and consistent "this is important, please
> > help" message without complicated auto-upgrade/downgrade schemes that
> > risk annoying users.
>
> I don't think we really can send such a message. Thanks just the same
> as asking for donations, not completely unsuccessful but not easy to
> make successful either. You're arguing for people running distinct
> software which has no capability to be a full node, and changing what
> they're doing in order to support the network. This maximizes the
> cost, because in addition to the real cost the user must take a
> switching cost too, and deemphasizes investing in keeping the full
> node software as usable because 'oh just run a lite node if the full
> is too slow'.
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121204/93f291de/attachment.html>

2023-06-07 10:45:47 UTC

- reply

📅 Original date posted:2012-12-04
📝 Original message:My personal opinion is that the ideal first client has three features:
(1) Starts up and is usable within a couple minutes (even 10 min the first
time would be okay, to sync block headers)
(2) Supports Windows, Linux and OSX
(3) Uses deterministic wallets that can produce a permanent backup
(preferably paper)
Encryption is a major upside, too, but people new enough to Bitcoin that
they need such a simple client, can survive without encryption (thye're not
going to be holding a ton of coins) -- as long as they are made aware that
they do not currently have encryption, and the associated risks (and other
options).
I think it's extremely important that users have a clear way to backup
their coins to offline media or paper, in such a way that they don't ever
need to worry about it again. Not only does it give users protection
against hard-drive loss, it means that they may find it again in the far
future when they haven't used Bitcoin in 2 years, and it reminds them that
they still have coins (and they don't have to type in 1000 private keys to
get their coins)
For that reason, I think Multibit is an excellent choice. I haven't spent
much time with it, but I do understand it to satisfy (1) and (2) clearly,
and (3) may be happening in the near future (along with encryption). But I
do wonder if it has enough staffing behind it to be the center of attention
(no offense to jim618, but if this becomes the "de-facto" client for new
users, we should make sure there's a lot of people available to support it
-- what if a major security bug is found? how long would it take the
current team to identify, fix and test that bug?)
-Alan
On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn <mike at plan99.net> wrote:
> At the moment if you visit bitcoin.org then you're recommended to
> download the full client. I think we all agree that at some point we
> need to start presenting users with something more like this:
>
>
> To get started, download wallet apps A or B.
>
> If you'd like to contribute your computing resources to the Bitcoin
> network and have a fast computer with an unfiltered internet
> connection, download:
>
> - for desktop machines, Bitcoin-Qt
> - for servers, bitcoind
>
>
>
> Obviously not that exact wording.
>
> I personally feel it's a bit early for this, but it's true that users
> are being turned away by the fact that they're pointed to Bitcoin-Qt
> by default, so having some kind of roadmap or plan for changing that
> would be good.
>
> I think MultiBit is maturing into a client that I'd feel comfortable
> recommending to end users who take the fast-start path, though it
> still has a few serious lacks (encrypted wallets aren't released yet,
> bloom filters will help performance a lot, needs to catch up with some
> newer features). But there doesn't have to be a one true client.
>
> The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
> not convinced this is the best use of time, but if somebody steps up
> to do it, that could also work. MultiBit has some unique features that
> are quite useful like integrating charting and exchange rate feeds.
>
> What does everyone think on this?
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121204/f76a7294/attachment.html>

2023-06-07 10:44:52 UTC

- reply

📅 Original date posted:2012-12-03
📝 Original message:These are all valid points. I hadn't really thought much about this point
until you all just brought it up. The reason I so quickly spout off that
phrase, is that I endlessly get requests from Armory users to implement
more anonymity-based features. When I say there are bigger priorities,
they suggest that "anonymity" is a core benefit of Bitcoin and I should be
supporting it. I'm not against anonymity, and I most certainly favor
privacy, but my goal was to produce a versatile client, not one focused on
any one aspect -- there are plenty of people who use it for other reasons
than anonymity.
However, I do like Greg's comment about "attacks" against a
blind-dust-inclusion algorithm, and suggestion to maintain a clustering of
already-linked addresses. That's not terribly difficult to do with the
transaction history in hand, and it could increase how often the logic
triggers. I suppose these hardcore SD players probably have a lot of
one-satoshi outputs that could use vacuuming...
On Mon, Dec 3, 2012 at 11:18 AM, Stephen Pair <stephen at bitpay.com> wrote:
> On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn <mike at 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 find out what I earned last month, then
>> that trade was neither anonymous nor private. In this case I want
>> privacy but anonymity isn't useful. Mixing up anonymity with privacy
>> is not only a public relations problem, but can lead to confusion from
>> users when they, eg, try and buy Bitcoins from an exchange and are
>> asked to provide ID proofs.
>
>
> I would like to second this point...privacy is essential because the
> market demands it. If Bitcoin doesn't do it well (and I would argue that
> it doesn't today), then eventually a competitor to Bitcoin will do it
> better and that would be the beginning of the end for Bitcoin. Debates
> about whether it was or wasn't a core feature are pointless.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121203/cc823863/attachment.html>

2023-06-07 10:44:42 UTC

- reply

📅 Original date posted:2012-12-03
📝 Original message:On 12/03/2012 10:02 AM, Gregory Maxwell wrote:
> (1) Make client software aggressive about sweeping up dust inputs:
> "Any time a transaction is created that has change keep adding in
> extra inputs— smallest to largest— until an additional one would
> increase the cost of the transaction by 0.0001 BTC or more" — the only
> major complication is doing this without concurrently harming privacy
> which is why it's not done yet in the reference client.
FYI, Armory uses exactly this logic to try to clean up dust outputs in
the user's transactions. However, there's enough conditions on it, that
I don't know how often it triggers. Recommendations are welcome for how
to improve it.
Right now, if the transaction has less than 5 inputs, there exists dust
UTXOs from addresses already included in the transaction, and those
UTXOs are sufficiently small in priority, then the Armory will add them
to the input side and increase the change accordingly. Looking it just
made me realize I lost the last condition of making sure the tx already
has a change output -- don't want to turn a free tx into a fee-needed tx
just to do this. (reorganized the code
<https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine.py#L5279>
recently, and must have fell through the cracks).
Perhaps it could be improved by cleaning up dust from *any* address by
default (not just ones already included in the tx), with the option for
the user to disable that behavior. After all, anonymity was never a
core feature of the network -- I think it makes sense that the logic
would reduce anonymity by default in exchange for a cleaner network,
with a clear option to "opt-out" of that logic if user cares. I think
most users don't actually care...
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121203/d0a9abab/attachment.html>

2023-06-07 10:21:39 UTC

- reply

📅 Original date posted:2012-07-09
📝 Original message:On 07/09/2012 10:36 PM, Stefan Thomas wrote:
>> It looks like that because feature matrices aren't especially helpful
>> for newbies to make a decision, especially when the "features" in
>> question were often things like how they handled the block chain or
>> which protocol standards they support, ie, things only of interest to
>> developers.
> A well-designed feature matrix can quite useful and user-friendly.
>
> http://www.apple.com/ipod/compare-ipod-models/
>
> Prose is better to get a sense of the philosophy and basic idea of a
> client. If it was between having only a feature matrix or only prose,
> I'd probably go for the prose as well.
>
> What a feature matrix is good at though is it allows you to very quickly
> find the specific feature or general criteria you're looking for without
> reading through all of the text. So it might be a useful addition maybe
> not on Bitcoin.org, but certainly on the wiki.
>
If we're keeping the clients page, I would really like to see the
feature matrix linked from that page. It shouldn't be on that main
clients page (for the reasons already stated), but Stefan makes a point
that /it is really useful for many users./ Add "Compare features of the
various different clients here: <link>" and users who will benefit will
most definitely click on it. I think that's win-win.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120709/5376969f/attachment.html>

2023-06-07 10:21:16 UTC

- reply

📅 Original date posted:2012-07-09
📝 Original message:I generally agree with Greg. I don't see anything he's said or done as
anti-alt-client.
As an alt-client developer, I'm happy to see my client on the main page,
but I'm also happy if that "clients" page is simply an acknowledgement that
there's more to the Bitcoin world than just the Bitcoin-Qt client, and a
link of where to find more information (i.e. the wiki). I would still *
prefer* to have the page the way it is, because I think alt clients should
be more accessible and word will spread better where it is now -- but I
also recognize the inherent difficulty of gaining any kind of consensus of
how it should be organized, what goes on the list, etc, and no matter how
you do it, someone will complain about it being unfair or not right.
We either have to have a "czar" who is trusted to make responsible
decisions, and complaints of being unfair or recommendations for
improvements can go through that person, but ultimately it is that person
who makes the call. Or we just move it to another page that is less
strictly controlled and where these things matter less. Trying to gain
consensus among an amalgamation of developers all with competing priorities
and "products" is a terrible way to try to agree on stuff.
-Alan
On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> > JS randomisation is bad. People shouldn't need JS to view a webpage.
>
> JS randomization doesn't imply needing JS to view the page. It implies
> needing JS to see it in random order. You could also combine it with
> the server-side randomization if you care about non-js being non
> random, though I don't think it matters.
>
> As others have pointed out I don't generally think the randomization
> is good in principle, but if its done it should at least achieve its
> goals.
>
> > Only you have a problem with this page. I don't see why Bitcoin-Qt needs
> to be first either when it dominates the front page. It is perfectly fine
> as it is.
>
> I'll let other people speak for themselves, but I did consult others
> before reverting your last batch of changes.
>
> More generally, we have pull requests in order to get some peer review
> of changes. Everyone should use them except for changes which are
> urgent or trivially safe. (Presumably everyone with access knows how
> to tell if their changes are likely to be risky or controversial)
>
> > You are not a developer of any alternative clients, and this is a
> webpage for Bitcoin clients. I have made a change to remove a source of
> disputes, and make the process more fair and equal. Your suggestion to
> remove the clients page is your bias towards thinking that there should be
> only one Bitcoin client that everyone uses (the one which you contribute
> towards).
>
> I'm strongly supportive diversity in the Bitcoin network, and some alt
> client developers can speak to the positive prodding I've given them
> towards becoming more complete software. If I've said anything that
> suggests otherwise I'd love to be pointed to it in order to clarify my
> position.
>
> Unfortunately none of the primary alternatives are yet complete, the
> network would be non-function if it consisted entirely of multibit or
> electrum nodes (and as you've noted armory uses a local reference
> client as its 'server'). The distinction between multiple kinds of
> clients in terms of security and network health are subtle and can be
> difficult to explain even to technical users and so until something
> changes there the reference client needs to be the option we lead
> with. People should us it unless their use-case doesn't match. When it
> does they'll know it and they'll be looking. We don't need to make one
> of those recommendations a primary option.
>
> I like the proposals of moving this stuff to the Wiki as the wiki
> already contains tons of questionable (and sometimes contradictory)
> advice and so there is less expectation that placement there implies
> any vetting.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120709/664e705e/attachment.html>

2023-06-07 10:18:11 UTC

- reply

📅 Original date posted:2012-06-19
📝 Original message: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 must replay the entire history of insertions and
deletions in the correct order to get the tree structure and correct
root. Along those lines, using something like a red-black tree, while
theoretically well-known, could be subject to implementation errors.
One implementation of a red-black tree may do the rebalancing
differently, and still work for it's intended purpose in the majority of
applications where it doesn't matter. One app developer updates their
RB tree code which updated the RB-tree optimizations/rebalancing, and
now a significant portion of the network can't agree on the correct
root. Not only would that be disruptive, it would be a disaster to
track down.
If we were to use a raw trie structure, then we'd have all the above
issues solved: a trie has the same configuration no matter how elements
are inserted or deleted, and accesses to elements in the tree are
constant time -- O(1). There is no such thing as an unbalanced trie.
But overall space-efficiency is an issue.
A PATRICIA tree/trie would be ideal, in my mind, as it also has a
completely deterministic structure, and is an order-of-magnitude more
space-efficient. Insert, delete and query times are still O(1).
However, it is not a trivial implementation. I have occasionally looked
for implementations, but not found any that were satisfactory.
So, I don't have a good all-around solution, within my own stated
constraints. But perhaps I'm being too demanding of this solution.
-Alan
On 06/19/2012 12:46 PM, Andrew Miller wrote:
>> Peter Todd wrote:
>> My solution was to simply state that vertexes that happened to cause the
>> tree to be unbalanced would be discarded, and set the depth of inbalance
>> such that this would be extremely unlikely to happen by accident. I'd
>> rather see someone come up with something better though.
> Here is a simpler solution. (most of this message repeats the content
> of my reply to the forum)
>
> Suppose we were talking about a binary search tree, rather than a
> Merkle tree. It's important to balance a binary search tree, so that
> the worst-case maximum length from the root to a leaf is bounded by
> O(log N). AVL trees were the original algorithm to do this, Red-Black
> trees are also popular, and there are many similar methods. All
> involve storing some form of 'balancing metadata' at each node. In a
> RedBlack tree, this is a single bit (red or black). Every operation on
> these trees, including search, inserting, deleting, and rebalancing,
> requires a worst-case effort of O(log N).
>
> Any (acyclic) recursive data structure can be Merkle-ized, simply by
> adding a hash of the child node alongside each link/pointer. This way,
> you can verify the data for each node very naturally, as you traverse
> the structure.
>
> In fact, as long as a lite-client knows the O(1) root hash, the rest
> of the storage burden can be delegated to an untrusted helper server.
> Suppose a lite-client wants to insert and rebalance its tree. This
> requires accessing at most O(log N) nodes. The client can request only
> the data relevant to these nodes, and it knows the hash for each chunk
> of data in advance of accessing it. After computing the updated root
> hash, the client can even discard the data it processed.
>
> This technique has been well discussed in the academic literature,
> e.g. [1,2], although since I am not aware of any existing
> implementation, I made my own, intended as an explanatory aid:
> https://github.com/amiller/redblackmerkle/blob/master/redblack.py
>
>
> [1] Certificate Revocation and Update
> Naor and Nissim. 1998
> http://static.usenix.org/publications/library/proceedings/sec98/full_papers/nissim/nissim.pdf
>
> [2] A General Model for Authenticated Data Structures
> Martel, Nuckolls, Devanbu, Michael Gertz, Kwong, Stubblebine. 2004
> http://truthsayer.cs.ucdavis.edu/algorithmica.pdf
>
> --
> Andrew Miller
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 10:09:55 UTC

- reply

📅 Original date posted:2012-05-25
📝 Original message:I like the concept except that it only works if every node connected to the
miner enforces the rule (if it works). Once any one of the nodes forwards
the block, other nodes see it coming from a node that can pass the
challenge.
I don't think any solution based on node queries will succeed, especially
if it requires spontaneous super-majority-of-nodes acceptance. I think
it's gotta be based on the block itself and each nodes' own info.
If you could spontaneously get all miners to agree not to build off of
anti-social blocks (however that is defined) , it would have a chance of
making a difference, but individual miners would have an advantage
building off the antisocial block because they only need to produce one to
create the longest chain (and collect reward) while the miners following
the rules need two blocks.
--Sent from my overpriced smartphone
On May 25, 2012 3:48 AM, "Christian Decker" <decker.christian at gmail.com>
wrote:
> How about a simple proof of work test? This one though does not ask for
> CPU work but asks the miner for a random old transaction. If the miner
> really stores the entire blockchain he will not have any problem answering
> to that getdata request, whereas a botnet would have to ask someone else
> for it, which could be detected if the response time deviates too much from
> what has been previously measured (compare it against getdata for the block
> they advertise). It's not perfect but it allows an estimate of whether it
> is a chainless miner.
>
> Regards,
> Chris
> --
> Christian Decker
>
>
>
> On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
>
>> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke at dashjr.org> wrote:
>> > Block times are not accurate enough for that.
>>
>> The times in your log are very accurate, assuming your system clock is
>> remotely accurate.
>>
>> --
>> Jeff Garzik
>> exMULTI, Inc.
>> jgarzik at exmulti.com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120525/856b88ab/attachment.html>

2023-06-07 10:07:46 UTC

- reply

📅 Original date posted:2012-05-03
📝 Original message:On 05/03/2012 01:46 AM, Wladimir wrote:
>
> Label is a label for the destination address, message is a freeform
> message describing the transaction.
>
> I don't think the message is currently stored in the Satoshi client.
> That feature is somewhere on our way-too-long issue and todo list.
>
> But I understand that you want to add transaction meta-data fields
> such as contact information, bought items, item prices?
>
>
I don't want to add fields to the URI-spec, I just want to add them /to
the client/. To me, it is ideal to have separate strings for labeling
/addresses/ vs labeling /transactions/ -- i.e. different strings would
show up in the address book (owner info) than what shows up in the
transaction history (purchase info). I say it's ideal because that
concept seems to fit perfectly with availability of "label=" and
"message=" fields in BIP 21, but it won't actually work if Bitcoin-Qt
won't/can't do it that way.
For now, it seems that I should count on all important information being
in the /label/ field, since users creating URLs would have to assume
anything in the /message/ field will not be saved. Though I imagine the
message data will be /displayed/ after the URI is clicked, just not saved.
To expand the concept slightly further, it might make sense in the
future for users to populate the /message/ and /label /fields with lots
of data, using newlines. The first line would be used as a summary and
displayed in the address book and ledger. The extra lines would all be
displayed when the user opens up a details window. All of it would be
automatically generated by the merchant, and the purchaser would end up
with detailed documentation on every purchase they've made for zero effort.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120503/32c2e58d/attachment.html>

2023-06-07 10:07:39 UTC

- reply

📅 Original date posted:2012-05-03
📝 Original message:I want to follow up on BIP 21 (URI scheme), which I have recently
implemented in Armory and I have become a huge fan of it. But I've got
a couple gripes:
*(1) *What is the status & plans for supporting "bitcoin:" URIs in the
Satoshi client? My understanding is that it currently creates URIs, but
does *not* register itself with the OS to handle such links. Is this
accurate? This seems like a very high-value feature, and I'd recommend
that we consider it a priority -- I can't think of any other upgrade
that can improve usability so dramatically on the desktop.
After implementing it all in Armory, I wrote up a walk-thru
<https://bitcointalk.org/index.php?topic=79010.msg879804#msg879804>
recounting how I did the OS-registration in Windows and gnome-based *nix
systems. Perhaps it can give the Bitcoin-Qt devs a jumpstart on getting
it implemented. (and then I can get feedback about doing for generic
Linux and Mac/OSX)
*(2) *I need to understand better what the intentions were behind
"label=" and "message=". The way I understand it is that Bitcoin-Qt
uses and stores only address-labels, and no other transactional info is
stored in the wallet. As such, the "message=" field would be displayed
to the user when a "bitcoin:" link is clicked, but that message wouldn't
be saved anywhere.
However, I think, especially if a new wallet format is in the works,
that both should be supported: "Address Labels" *and *"Transaction
Labels". The real difference is that merchants can include things
Order#, purchase information, etc, in the "message" field, and then put
only their business name in the "label" field. This means that when the
user is looking at their address book, they see just the owners of the
addresses. When they look at the transaction ledger/history, they see a
full list of everything they purchased, prices, contact info, etc. The
distinction is much more important for persistent addresses, but still
important.
This is exactly how I did it in Armory, but if Bitcoin-Qt won't do it
that way, I should be promoting all important information be jammed into
the "label" field.
*(3) *How are the other clients implementing this? Do you make any
distinction between "label" and "message"?
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120503/6ead9661/attachment.html>

2023-06-07 10:06:48 UTC

- reply

📅 Original date posted:2012-05-02
📝 Original message:I think it's perfectly reasonable to debate ordering. I personally don't
think Armory should be up front, because it's not intended for beginners.
How's that for honesty? I don't think anyone is trying to game the system
right now, I think we're trying to come up with a reasonable mechanism for
appealing to new users and get the community more connected. And make
sure everyone understands the system.
On the other hand, perhaps it's better to take the acceptable 80% solution,
and revise it over time...
Amir, I don't have access to the page. I've never been able to view it.
Changing my hosts file doesn't seem to do anything. Can you just forward
me the text? I'll send you an approval email.
On Wed, May 2, 2012 at 3:43 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> This discussion about ordering is absolutely retarded. Once the list fills
> up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt
> first and the others ordered however. That was nobody can try to game the
> system (it remains unexploitable).
>
> If there are no objections, then I am going to merge this branch. The
> forum thread is divulging into a mess all over the place, and this
> conversation can go on forever discussing the silly fine details:
>
> http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem:
> You suggest creating something new for your hackerspace, like a
> bikeshed. But now all anyone will discuss is its colour. No bikeshed
> will be built.
>
> Armory & MultiBit, are you OK with that description? I will check with
> ThomasV about Electrum.
>
>
> ________________________________
> From: Gary Rowe <g.rowe at froot.co.uk>
> To: "bitcoin-development at lists.sourceforge.net" <
> bitcoin-development at lists.sourceforge.net>
> Sent: Wednesday, May 2, 2012 8:34 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
>
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:
>
> This is like the most annoying thing about email. Often with group emails,
> we'll be having a conversation then someone will click reply instead of
> group reply and the convo will go on for a while. Eventually I'll realise
> the persons are missing and add them back in.
> >
> >On Yahoo mail (which I use for spam/mailing lists), to do reply all
> involves clicking a tab, scrolling down and clicking Reply All. Normally I
> instead go through the steps of reply, delete To, re-enter bitco... select
> drop down, click send.
> >
> >Anyone know how to make reply all the default in mutt? And how can I
> exclude it from re-including my own email when I do a group reply so I
> don't get the same email again.
> >
> >
> >
> >
> >----- Original Message -----
> >From: Jeff Garzik <jgarzik at exmulti.com>
> >To: grarpamp <grarpamp at gmail.com>
> >Cc: bitcoin-development at lists.sourceforge.net
> >Sent: Wednesday, May 2, 2012 7:29 PM
> >Subject: Re: [Bitcoin-development] new bitcoin.org clients page
> >
> >
> >On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
> >>> Try "Reply to All"
> >>
> >> That puts the sender in 'to' and list in 'cc',
> >> which dupes to the sender and eventually
> >> blows out the to and cc lines as everyone
> >> chimes in and doesn't trim. 'reply to' solves
> >> most of that. assuming the list sw can do it.
> >
> >"Reply-To" Munging Considered Harmful
> >http://www.unicom.com/pw/reply-to-harmful.html
> >
> >
> >
> >--
> >Jeff Garzik
> >exMULTI, Inc.
> >jgarzik at exmulti.com
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120502/08c0ebe1/attachment.html>

2023-06-07 10:06:37 UTC

- reply

📅 Original date posted:2012-05-02
📝 Original message:I'm not sure what "designed for occasional use" means. Many users of
other clients use them exclusively without touching other clients. Armory
is designed to be your only wallet (if bitcoind[d/-qt] is running in bkgd).
I'm sure the other clients are the same.
Instead, I think that line would be replaced by a blurb about the target
audience. "Designed for Advanced Users". "Designed for Quick Setup and
Instant usability".
Btw, Armory now has full installers for both Windows and Linux
(Ubuntu/Debian), with uninstallers and automatic URI registration
On Wed, May 2, 2012 at 3:34 PM, Gary Rowe <g.rowe at froot.co.uk> wrote:
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:
>
>> This is like the most annoying thing about email. Often with group
>> emails, we'll be having a conversation then someone will click reply
>> instead of group reply and the convo will go on for a while. Eventually
>> I'll realise the persons are missing and add them back in.
>>
>> On Yahoo mail (which I use for spam/mailing lists), to do reply all
>> involves clicking a tab, scrolling down and clicking Reply All. Normally I
>> instead go through the steps of reply, delete To, re-enter bitco... select
>> drop down, click send.
>>
>> Anyone know how to make reply all the default in mutt? And how can I
>> exclude it from re-including my own email when I do a group reply so I
>> don't get the same email again.
>>
>>
>>
>> ----- Original Message -----
>> From: Jeff Garzik <jgarzik at exmulti.com>
>> To: grarpamp <grarpamp at gmail.com>
>> Cc: bitcoin-development at lists.sourceforge.net
>> Sent: Wednesday, May 2, 2012 7:29 PM
>> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>>
>> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
>> >> Try "Reply to All"
>> >
>> > That puts the sender in 'to' and list in 'cc',
>> > which dupes to the sender and eventually
>> > blows out the to and cc lines as everyone
>> > chimes in and doesn't trim. 'reply to' solves
>> > most of that. assuming the list sw can do it.
>>
>> "Reply-To" Munging Considered Harmful
>> http://www.unicom.com/pw/reply-to-harmful.html
>>
>>
>>
>> --
>> Jeff Garzik
>> exMULTI, Inc.
>> jgarzik at exmulti.com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120502/af738a5b/attachment.html>

2023-06-07 02:56:14 UTC

- reply

📅 Original date posted:2012-01-16
📝 Original message:You guys are representing both extremes of the issue. In response to
Jeff and Luke-Jr, I don't see how this is /just any other poltical
issue/. It strikes at the heart of everything Bitcoin is about.
Barring Bitcoin-specific legislation, I don't see how any legislation
could be more relevant to Bitcoin and the community around it.
On the other hand, Bitcoin is still a non-entity, and shouldn't get in
the business of making statements. A central voice for Bitcoin gives
the impression that it is actually centralized, and one that has
opinions. Plus I wouldn't be surprised if some, heavily-invested
Bitcoin users were of the opinion that SOPA/PIPA/whatever could be a
huge profit for themselves: once SOPA kicks in and businesses around
the world start getting cut off for legit or illegitimate purposes, a
lot of them could potentially switch to Bitcoin to keep their business
going. That could be a huge boon for Bitcoin. You may not agree it's
worth the tradeoff, but people are selfish and may not actually
understand or even care about SOPA legislation itself.
I think it's /not inappropriate/ for something to be mentioned on the
website about Bitcoin's philosophy being threatened by SOPA, but I agree
Bitcoin should avoid making any bold political stands. Users could be
reminded that SOPA affects yet another thing they care about, but it
might be better to avoid it altogether. If any response is made, it
should be a very light one.
-Alan
On 01/16/2012 07:30 PM, Amir Taaki wrote:
> Bunk argument. This is an issue that affects bitcoin directly.
>
> Wikipedia has far more need to remain neutral and apolitical than bitcoin ever does- you've read Satoshi's politically charged whitepaper or seen the genesis block quote.
>
> http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action
>
> The Wikipedia community decided on a full and global blackout. Bitcoin should do the same in unison with the rest of the web- sites like Reddit, 4chan and Wikipedia.
>
> It's funny / almost comical how you consign this to being just another issue or case of moral alarm. Sad.
>
>
>
> ----- Original Message -----
> From: Jeff Garzik<jgarzik at exmulti.com>
> To: Amir Taaki<zgenjix at yahoo.com>
> Cc: "bitcoin-development at lists.sourceforge.net"<bitcoin-development at lists.sourceforge.net>
> Sent: Sunday, January 15, 2012 10:37 PM
> Subject: Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout
>
> On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki<zgenjix at yahoo.com> wrote:
>> How is this not the most important world issue right now?
>>
>> EVERYTHING is under threat. Go nuclear to show our nerd-rage.
>>
>> Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy.
>
> There are always issues that raise ire and moral outrage. I would
> rather that bitcoin.org stay apolitical -- our users will appreciate
> this in the long run.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120116/5083fc3c/attachment.html>

2023-06-07 02:38:58 UTC

- reply

📅 Original date posted:2011-11-12
🗒️ Summary of this message: A user suggests that the point of Bitcoin Improvement Proposals (BIPs) is to collaborate and come up with a good solution before implementation. BIPs should not be a place for armchair designs without corresponding implementation.
📝 Original message:Maybe I'm new to this, but this doesn't make any sense. I thought the
point of the BIP was to collaborate to come up with a good solution.
That's exactly what I want to do before I implement it in my software.
After all, they are "Bitcoin Improvement *Proposals*." It seems like
EXACTLY what a BIP is for... just no one needs/should use it until it
removes the "draft" marking.
As for the protocol on top of it, my BIP was not intended to address
that. It's only proposing how unsigned transactions can be serialized
and users can collect addresses. Whatever system you want to implement
on top of it to exchange the data is up to the developer. My only
motivation is that if the user clicks "Save this proposal to file", that
any client can use the resulting file, just the same way we serialize
any other blockdata that has a consistent representation.
-Alan
On 11/12/2011 11:58 AM, Mike Hearn wrote:
> Please don't create BIPs that don't have any actual implementation
> behind them. Design discussion is fine but the mailing list works for
> that.
>
> If I were going to implement escrow transactions in BitCoinJ it would
> not matter what was written here. I'd just implement the design I
> thought made sense. If that design was later adopted by others it can
> be documented and agreed upon in a BIP, just like a regular RFC.
>
> For what it's worth I would not attempt to send half-valid escrow
> transactions through the p2p network, not even using the overlay
> networks the protocol already supports. A correct escrow protocol
> requires the seller to challenge the dispute mediator with the public
> key to be sure they actually own it, and the simplest way to do that
> is to leverage the existing DNS/EV-SSL infrastructure with a "sign
> this nonce" HTTP request.
>
> BIPs should not be a place for people to come up with armchair
> designs, because a design with no corresponding implementation is
> likely to be full of problems. Let's revisit this once I can install
> some software on my laptop, my server, and a friends server, and do a
> 3-way mediated transaction between them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111112/e36715ff/attachment.html>

2023-06-07 02:35:32 UTC

- reply

📅 Original date posted:2011-10-25
🗒️ Summary of this message: The proposed OP_EVAL tool for multi-signature transactions is optional, and regular OP_CHECKMULTISIG can still be used. It is important to keep the subscripts/mappings in the wallet forever, and there should be an easy way to add such a script/mapping to the wallet.
📝 Original message:On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > You give the hash to whoever is paying you, and store the hash -->
> > script mapping when you do that (assuming you're not using a
> > deterministic wallet; if you are, you probably just increment a
> > counter in the wallet).
>
> If anyone finds that solution unsatisfying, consider— It's already the
> case that I could take one of your disclosed public keys and create an
> infinite series of secondary keys out of it for which only you could
> decode, and the only way for you to find them in the blockchain would
> be to have performed the same procedure and made a note of the
> addresses you're watching for.
>
>
(1) As I understand it, OP_EVAL is being proposed as an *optional* tool for
multi-signature transactions. It sounds like to me, that you can still use
the regular OP_CHECKMULTISIG if you are concerned about these things. If
you're dealing with too many parties with questionable reliability that they
will notify you of transacitons that include you, I don't see anything wrong
with declaring that you'd only prefer dealing with OP_CMS transactions and
not OP_EVAL (besides some grumbling from them that their way is "better").
Either way, they're screwing themselves, too, if they want to include you on
transactions and don't notify you as such (kind of defeats the purpose of
multi-sig txs).
(2) I think it's unnecessary to discuss cases where you somehow lose your
mappings but not your private keys. In order for OP_EVAL scripts to work,
the subscripts/mappings are *just as important* as your regular private
keys. They should be kept in your wallet forever just like your private
keys--and thus you lose none of them or all of them. The only real
difference is that they aren't sensitive like your private keys, so they
don't have to be encrypted.
(3) There should most definitely be a button on the main client that allows
you to "Add OP_EVAL script" or something along those lines (maybe something
with a less obscure name). We need to make it as easy as possible for
someone to add such a script/mapping to their wallet. Although, this
invites a breach of one of my core rules of user interfaces: if the
functionality is dependent on the user performing some regular maintenance
task, you better be prepared for all users to fail at doing it. Even
diligent users are going to forget/mess-up sometimes. If failure at
performing this task results in breaking the client or losing money, we
should avoid promoting that usage paradigm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111025/e630403f/attachment.html>