|
Also interested in a better social network. What more can you share about your goals with this project?
|
|
|
|
|
Looking for help with a Chrome extension o call a third-party API and add a few buttons to a couple kinds of pages if you're interested. PM me for details.
|
|
|
|
|
blockw.com
bitcoinburritos.com
bitcoinhotsauce.com
bitcoinspices.com
bitcoinpeppers.com
bitcoinhotsauces.com
3dprintbit.com
bitcoinsteaks.com
bitcoingrain.com
bitcoinsoybeans.com
bitcoinhogs.com
bitcointreasuries.com
bitcointractors.com
bitcoinshipper.com
bitcoincargo.com
bitcoinvehicle.com
bitcoingoldcoins.com
bitcoinzinc.com
bitcoinwheat.com
bitcoincme.com
bitcoinpavilion.com
bitcoincontainershipping.com
bitcoinimports.com
Bids accepted in thread or PM. Payment in BTC or LTC. Escrow preferred.
|
|
|
|
|
Hello all,
From the vault I'm offering the following premium domain.
bitcoinmother.com
Mother's day is imminent and this could be great for a business selling mom-focused Bitcoin stuff.
Accepting bids here or in PM.
I have other domains as well and look forward to doing an escrowed trade with you!
-weex
|
|
|
|
|
Nice thread idea. It would be interesting if you'd add other stats such as block # of activation, block # of enforcement with links to each and prices at each time vs. now.
|
|
|
|
people have no choice but to lock in their funds to one of these central hubs
If you want to do business with a specific merchant you need to have a connection to them but I don't see the lock-in effect here. Amazon could be served by a small number of high-value channels to other well-connected nodes. |
|
|
|
In a discussion of SegWit activation on LTC, one anti-comment was all about LN being the equivalent of fractional reserve banking.
My hope was that someone could explain that to me?
Not fractional reserve banking, I understand that. I just don't understand how LN somehow = FRB.
It's mostly FUD but if economic concentration is too great, there is a risk of loss which some may characterize rather imprecisely as FRB. The idea is if you had a channel open with the same entity as many others did, they could publish many transactions stealing funds and you would not be able to get your punishment transaction confirmed. To mitigate this channels can be kept small, the punishment time large or people can just close channels whenever they feel the risk of keeping them open outweighs the benefits. |
|
|
|
The addrindex patch to Bitcoin Core creates an index of transactions by address. This enables someone running the software to get confirmed transactions for any address. The addrindex patch currently requires an entire copy of the blockchain meaning total storage requirements are >120gb today. In order to provide the services of getting unspent outputs (and balances) for arbitrary addresses, a pruned node is sufficient. The goal of this job is to modify the addrindex patch to make it compatible with pruning. This task is done when… 1) A patch to addrindex makes it possible to turn on pruning (i.e. prune=2000) and addrindex=1 without error. 2) Searching for an address via rpc command "bitcoin-cli getunspent <address>" returns currently unspent outputs for <address> 3) Dump complete list of unspent outputs with address as json with command "bitcoin-cli getallunspent" allowing one parameter: minimum number of confirmations. Paying in BTC that will be escrowed via multisig (Rein). This would be used by Rein to remove the API dependency we have on blocktrail or blockr.io to get unspent outputs so we can automatically build payment transactions. Main thing it does is make addrindex possible to run with a much smaller storage footprint. Reply or PM me with bids.Edit: No longer necessary since pull request 9806 to Bitcoin Core is addressing this use case. |
|
|
|
|
Suggested user experience improvements for Rein:
- Explanation of bitcoin, somewhere.
- Making verification of escrow easy (say, generated URLs that the user can click and see if the addresses are funded).
- Desktop / e-mail notifications.
- Would love to have more direct access to user wallet createntials - digging in db's is not something the user should ever have to do.
- Built-in update system, maybe?
- Perhaps some sort of profile for users, so that others can see their previous jobs, portfolio links, etc?
Edit: These have been included and prioritized into the above Q2 roadmap
|
|
|
|
Development Roadmap Q2 2017Usability / UX (ordered by descending priority) Support manual payment amount. This allows for fiat-based pricing User lookup - get enrollment from server by SIN, master, or delegate key Mediator collect/presign payment Email notifications Show/hide delegate or payment keys/xprvs for import into other wallets Enrollment updates Previous jobs, portfolio links (with strong warning) on profile user profile page Explanation of Bitcoin, link to FAQ, help docs Mediator search I18n Translate web interface Mobile App Android app based on http://imgur.com/a/nDpXWClient-side encrypted mode Chrome extension Network efficiency Client helps share docs between servers Safety Links to discussion forums about trust/ratings issues Privacy Enable bids and later in order flow to be encrypted for decryption only by parties to transaction
|
|
|
|
That link does not produce a download. Would you happen to be have a recent update? I've been focused on Rein and had a performance issue that caused the script to fall behind under heavy transaction volume. Will see what's possible but note that the software is available and if you have a full node, you too can do it or hire someone to do it. |
|
|
|
Coinb.in Features Include .001 BTC being taken when ever the algorithm or software writer feels like grabbing some coin.
AND Expensive transfer fees .0011 minimum. Which gets U a minimum 72 hours of waiting time after u have broadcast your coin.
Paying a higher transfer fee does NOT move the coin any faster.
I WILL NOT BE USING THIS JUNK WALLET ANY LONGER. I THOUGHT OTHERS SHOULD BE WARNED TO AVOID IT AS WELL
It may have started as a good idea, but it no longer is a good idea. It is a good way to lose your investment to poor timing and mismanaged coin disbursements
You're saying Coinb.in calculated a fee for you? AFAIK, it just leaves whatever you don't send on as a fee. |
|
|
|
While not terribly useful, this scatter plot of # of blocks to confirm
I think thats exactly the opposite... fee rate vs time is not very useful: Time just adds in the noise of a possion process with no influence by fees. If you have a good estimator based on block count you can simply multiply it's predictions by the exponential distribution of interblock intervals and get a good estimator of time... but to take data that has been smeared by random block times and construct good estimates is hard due to all the injected noise. In effect, your time data is heavily biased by random correlations with higher and lower fee intervals with luckier or less lucky block finding. This remains true so long as people aren't turning hashrate on and off based on fees-- and so far as I know it, no one is today. An interesting chart is a grid over n-blocks-wait and fee-rate, then for each cell set a value of what percentage of transactions paying at least that fee rate were confirmed in at that number or fewer blocks. How does your data handle transaction replacement? How do you compute feerates for CPFP transactions? One possibility is to only consider transactions which are not dependent on unconfirmed transactions and which have no children; and similarly do not consider replacement or replaced transactions. I understand blocks to confirm is more useful but just looking at that graph, I could see key information wasn't visible in 2d black and white. That's what I meant by that graph not being terribly useful. I like the grid chart idea. A question that comes to mind with blocks is, has anyone done analysis to detect patterns in luck or transaction inclusion week by week? I suppose not many people are turning miners on and off due to weather, variable energy pricing over the day but I'd be interested to look into it. The data doesn't take into account CPFP or dependencies within unconfirmed transactions at this point but it was a thought I had. I've only started collecting some of this data and want to see what people throw on the wall in terms of analysis, then iterate on the data that's being collected to learn more. I feel like diversity in fee estimation strategies is important to defend against some entity trying to game those strategies. |
|
|
|
Thank you for explaining this. But I can't understand that: As coinjoins are done, coins move from one mixing depth to the next higher one. Therefore, assuming you add coins at mixing depth 0, outputs at depth 4 will have gone through 4 coinjoins.
When I sending my coins ,I just specify : mixing depth (where from my coins will be sent from) , my electrum bitcoin address (where bitcoins will be sent to). How will bitcoins migrate from lower mixing depth to higher ? Maybe I must to made 4 sendcoin operations, every time using bitcoin addres from my coin join wallet 1 level higher mixing depth to reach 4th level ? P.S. thx for Vagrant , it is rather difficult to install JM first time. I should clarify lower vs higher. I was saying lower = 0 and higher = toward 4-5. Your coins migrate mixing depths if you use the tumbler script or a yield generator. I'm not sure if there are others, maybe sendpayment or patientsendpayment does the same. Effectively every coinjoin adds a mixing depth so depending on whether your send includes doing a coinjoin on the way, it may increase the overall mixing depth. |
|
|
|
Development and testing on many bitcoin-related software packages takes some considerable setup. To try and simplify this and help new developers and testers come up to speed more easily, I've created the Vagrant-based setup below. Vagrant is a toolkit for bringing up and configuring virtual machines and can connect to AWS or a local VirtualBox install among others to create the VM. The project, called devsetup, was designed to help me test Rein but as I'm getting into JoinMarket I added it to the setup process as well. If you've never developed any Bitcoin-related software or JoinMarket, I'd be interested to hear your thoughts. The setup is basically to install VirtualBox ( https://virtualbox.org) , Vagrant ( https://vagrantup.com), then clone this repo with: git clone https://github.com/ReinProject/devsetup.git and finally start up the box with The first time it runs, it'll download the Ubuntu 16.04 image this box is based on. When you're done you can and subsequent commands will be able to use that existing image. Provisioning takes about 5-10 minutes which is on par with the regtest of JM once it's running. |
|
|
|
Can smb to explain what the mixing depth is?
I'm trying to understand all features of joinmarket. But I can't find out nothing about mixing depth in wiki .
I'm understand, that there are wallets each in own mixing depth. I'm sending coins from mix depth 0 - 4, but I can't see no difference between. Is it only used only for wallet organizing?
Is any security difference between sending coins from mix depth 0 and mix depth 4 ?
My understanding is that mixing depths represent distinct identities within the software. As coinjoins are done, coins move from one mixing depth to the next higher one. Therefore, assuming you add coins at mixing depth 0, outputs at depth 4 will have gone through 4 coinjoins. This is harder to correlate than coins at mixing depth 3 or 2 or 1. One thing you should never do, and I think the wiki talks about this is to send coins from different depths to the same external wallet as that may allow some blockchain analysis to put together your different depths. Hope that helps. |
|
|
|
I was curious how much revenue is coming from fees from the transactions which miners include in only the next one or two blocks., One problem with using OP's data (confirmation_times.csv) for this is that it uses a timestamp, instead of block #. So there's no real way to know how many confirmations it took for a transaction to get mined. But using the average of 1 block = 10 minutes, I should be able to get kind of close. What information this provides us is that miners receive ~%75 of their revenue from transactions they include within the first two blocks (well, within the first 20 minutes, to be technically accurate).  Very cool! Note that the latest data file does have # of blocks to confirm for each transaction which may simplify your script. That file is at http://www.filedropper.com/conftimesI'll probably post another this weekend and will look to hook this up to http://bitcoinexchangerate.org/fees to generate the best fee estimates possible. |
|
|
|
Thought this might be useful to some of you... It's a recipe for an Ubuntu 16.04 Desktop VM that includes Bitcoin Core installed via PPA and configured for testnet, with pruning to 2gb, and to serve RPC requests with a randomly generated password. https://github.com/ReinProject/devsetupI created it to simplify dev onboarding for Rein so it also includes Rein's client and server configured to use said Core node. I would consider including other tools as well though since we all should really be making it easier to develop Bitcoin things. |
|
|
|
|
Show Posts
